f051c466cf
Many PWM controllers provide access to more than a single PWM output and may even share some resource among them. Allowing a PWM chip to provide multiple PWM devices enables better sharing of those resources. As a side-effect this change allows easy integration with the device tree where a given PWM can be looked up based on the PWM chip's phandle and a corresponding index. This commit modifies the PWM core to support multiple PWMs per struct pwm_chip. It achieves this in a similar way to how gpiolib works, by allowing PWM ranges to be requested dynamically (pwm_chip.base == -1) or starting at a given offset (pwm_chip.base >= 0). A chip specifies how many PWMs it controls using the npwm member. Each of the functions in the pwm_ops structure gets an additional argument that specified the PWM number (it can be converted to a per-chip index by subtracting the chip's base). The total maximum number of PWM devices is currently fixed to 1024 while the data is actually stored in a radix tree, thus saving resources if not all of them are used. Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> [eric@eukrea.com: fix error handling in pwmchip_add] Signed-off-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
58 lines
2.3 KiB
Plaintext
58 lines
2.3 KiB
Plaintext
Pulse Width Modulation (PWM) interface
|
|
|
|
This provides an overview about the Linux PWM interface
|
|
|
|
PWMs are commonly used for controlling LEDs, fans or vibrators in
|
|
cell phones. PWMs with a fixed purpose have no need implementing
|
|
the Linux PWM API (although they could). However, PWMs are often
|
|
found as discrete devices on SoCs which have no fixed purpose. It's
|
|
up to the board designer to connect them to LEDs or fans. To provide
|
|
this kind of flexibility the generic PWM API exists.
|
|
|
|
Identifying PWMs
|
|
----------------
|
|
|
|
Users of the legacy PWM API use unique IDs to refer to PWM devices. One
|
|
goal of the new PWM framework is to get rid of this global namespace.
|
|
|
|
Using PWMs
|
|
----------
|
|
|
|
A PWM can be requested using pwm_request() and freed after usage with
|
|
pwm_free(). After being requested a PWM has to be configured using
|
|
|
|
int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
|
|
|
|
To start/stop toggling the PWM output use pwm_enable()/pwm_disable().
|
|
|
|
Implementing a PWM driver
|
|
-------------------------
|
|
|
|
Currently there are two ways to implement pwm drivers. Traditionally
|
|
there only has been the barebone API meaning that each driver has
|
|
to implement the pwm_*() functions itself. This means that it's impossible
|
|
to have multiple PWM drivers in the system. For this reason it's mandatory
|
|
for new drivers to use the generic PWM framework.
|
|
|
|
A new PWM controller/chip can be added using pwmchip_add() and removed
|
|
again with pwmchip_remove(). pwmchip_add() takes a filled in struct
|
|
pwm_chip as argument which provides a description of the PWM chip, the
|
|
number of PWM devices provider by the chip and the chip-specific
|
|
implementation of the supported PWM operations to the framework.
|
|
|
|
Locking
|
|
-------
|
|
|
|
The PWM core list manipulations are protected by a mutex, so pwm_request()
|
|
and pwm_free() may not be called from an atomic context. Currently the
|
|
PWM core does not enforce any locking to pwm_enable(), pwm_disable() and
|
|
pwm_config(), so the calling context is currently driver specific. This
|
|
is an issue derived from the former barebone API and should be fixed soon.
|
|
|
|
Helpers
|
|
-------
|
|
|
|
Currently a PWM can only be configured with period_ns and duty_ns. For several
|
|
use cases freq_hz and duty_percent might be better. Instead of calculating
|
|
this in your driver please consider adding appropriate helpers to the framework.
|