Thread (68 messages) 68 messages, 6 authors, 2015-07-20

Re: [RFC PATCH 05/15] pwm: introduce default period and polarity concepts

From: Thierry Reding <hidden>
Date: 2015-07-20 08:22:42
Also in: linux-arm-kernel, linux-leds, linux-pwm, linux-tegra

On Mon, Jul 20, 2015 at 10:14:43AM +0200, Boris Brezillon wrote:
Hi Thierry,

On Mon, 20 Jul 2015 10:03:14 +0200
Thierry Reding [off-list ref] wrote:
quoted
On Thu, Jul 02, 2015 at 09:49:55AM +0200, Boris Brezillon wrote:
quoted
On Thu, 2 Jul 2015 08:44:45 +0200
Uwe Kleine-König [off-list ref] wrote:
quoted
On Wed, Jul 01, 2015 at 10:21:51AM +0200, Boris Brezillon wrote:
quoted
When requested by a user, the PWM is assigned a default period and polarity
extracted from the DT, the platform data or statically set by the driver.
Those default values are currently stored in the period and polarity
fields of the pwm_device struct, but they will be stored somewhere else
once we have introduced the architecture allowing for hardware state
retrieval.

The pwm_set_default_polarity and pwm_set_default_period should only be
used by PWM drivers or the PWM core infrastructure to specify the
default period and polarity values.
Would it make sense to put the prototypes of
pwm_set_default_p{olarity,eriod} into (say) drivers/pwm/pwm-private.h
then?
Yes, definitely. I was thinking about moving those functions/prototypes
into include/linux/pwm-provider.h, but I'm fine with
drivers/pwm/pwm-private.h too.

Thierry, any opinion ?
I'm not sure I see the need for this. If they are the default values and
drivers have no need to change them, then storing them in the regular
period and polarity fields seems just fine (they'll be propagated into
new state objects as they get created).

And if the driver has a need to change them, then why would it ever care
about the default values?
Because the period is often directly extracted from the DT, and this
extracted period may not match the one configured by the bootloader.

If the driver wants to display the current status without changing the
PWM state, then the driver will use the current state. ITOH, if it
has to apply a new config, the driver will use the default period
value (extracted from the DT) and change the duty-cycle depending on its
needs.
This is the case we have with the pwm-regulator driver: we want to
display the initial voltage value without changing the PWM config, and
when someone decides to change the voltage, we want to use the default
period instead of keeping the one configured by the bootloader.
Wouldn't it make more sense to postpone this until the introduction of
the default state, then? That way we'd be getting a more consistent way
of dealing with default vs. initial by looking only at state objects.

Ideally initial state should be the same as the default state. Except
maybe for the duty-cycle, which won't be encoded in the default state
anyway.

Thierry

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help