diff mbox series

[1/4] pwm: core: Support new usage_power setting in PWM state

Message ID 20210507131845.37605-1-clemens.gruber@pqgruber.com
State Accepted
Headers show
Series [1/4] pwm: core: Support new usage_power setting in PWM state | expand

Commit Message

Clemens Gruber May 7, 2021, 1:18 p.m. UTC
If usage_power is set, the PWM driver is only required to maintain
the power output but has more freedom regarding signal form.

If supported, the signal can be optimized, for example to
improve EMI by phase shifting individual channels.

Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
---
 Documentation/driver-api/pwm.rst | 4 ++++
 drivers/pwm/core.c               | 6 +++++-
 include/linux/pwm.h              | 7 +++++++
 3 files changed, 16 insertions(+), 1 deletion(-)

Comments

Uwe Kleine-König May 7, 2021, 3:03 p.m. UTC | #1
Hello,

On Fri, May 07, 2021 at 03:18:42PM +0200, Clemens Gruber wrote:
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> index 5bb90af4997e..5a73251d28e3 100644
> --- a/include/linux/pwm.h
> +++ b/include/linux/pwm.h
> @@ -54,12 +54,17 @@ enum {
>   * @duty_cycle: PWM duty cycle (in nanoseconds)
>   * @polarity: PWM polarity
>   * @enabled: PWM enabled status
> + * @usage_power: If set, the PWM driver is only required to maintain the power
> + *               output but has more freedom regarding signal form.
> + *               If supported, the signal can be optimized, for example to
> + *               improve EMI by phase shifting individual channels.
>   */
>  struct pwm_state {
>  	u64 period;
>  	u64 duty_cycle;
>  	enum pwm_polarity polarity;
>  	bool enabled;
> +	bool usage_power;
>  };
>  
>  /**

If we really want to support this usecase, I would prefer to not have it
in pwm_state because this concept is not a property of the wave form. So
for a driver it doesn't really make sense to set this flag in
.get_state().

Maybe it makes more sense to put this in a separate argument for a
variant of pwm_apply_state? something like:

	int pwm_apply_state_transition(struct pwm_device *pwm, const struct pwm_state *state, const struct pwm_state_transition *transition);

and pwm_state_transition can then contain something like this usage
power concept and maybe also a sync flag that requests that the call
should only return when the new setting is active and maybe also a
complete_period flag that requests that the currently running period
must be completed before the requested setting is implemented.

OTOH the information "I only care about the relative duty cycle" is
relevant longer than during the transition to a new setting. (So if
there are two consumers and one specified to be only interested in the
relative duty cycle, the other might be allowed to change the common
period.)

Having said that, I don't like the proposed names. Neither "usage_power"
nor "pwm_apply_state_transition".

In a non-representative survey among two hardware engineers and one
software engineer who already contributed to PWM (!= me) I found out
that these three have an intuitive right understanding of
"allow-phase-shift" but have no idea what "usage-power" could mean.

On a side note: The hardware guys noted that it might make sense to
align the shifted phases. i.e. instead of shifting channel i by i *
period/16, it might be better to let the 2nd channel get active when the
first gets inactive. (i.e. try to keep the count of active channels
constant).

And as already mentioned earlier I still think we should define the
concept of "usage power" better. It should be clearly defined for a
driver author which setting they should pick for a given request. This
removes surprises for consumers and guessing for lowlevel driver
authors. Also a uniform policy brings conflicts better to light.
(Something like driver A does the right thing for consumer C and driver
B makes it right for D. But once D tries to use A things break. (And
then maybe A is changed to fit D, and C doesn't object because they
don't read the pwm list resulting in a breakage for C later.))

So in sum: I think this concept is too inchoate and we shouldn't apply
these patches. I would prefer to go for allow-phase-shift (if at all)
for now. There the concept is clear what is allowed (for a lowlevel
driver) resp. can be expected (for a consumer).

Best regards
Uwe
Clemens Gruber May 7, 2021, 3:47 p.m. UTC | #2
Hi Uwe,

On Fri, May 07, 2021 at 05:03:17PM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> On Fri, May 07, 2021 at 03:18:42PM +0200, Clemens Gruber wrote:
> > diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> > index 5bb90af4997e..5a73251d28e3 100644
> > --- a/include/linux/pwm.h
> > +++ b/include/linux/pwm.h
> > @@ -54,12 +54,17 @@ enum {
> >   * @duty_cycle: PWM duty cycle (in nanoseconds)
> >   * @polarity: PWM polarity
> >   * @enabled: PWM enabled status
> > + * @usage_power: If set, the PWM driver is only required to maintain the power
> > + *               output but has more freedom regarding signal form.
> > + *               If supported, the signal can be optimized, for example to
> > + *               improve EMI by phase shifting individual channels.
> >   */
> >  struct pwm_state {
> >  	u64 period;
> >  	u64 duty_cycle;
> >  	enum pwm_polarity polarity;
> >  	bool enabled;
> > +	bool usage_power;
> >  };
> >  
> >  /**
> 
> If we really want to support this usecase, I would prefer to not have it
> in pwm_state because this concept is not a property of the wave form. So
> for a driver it doesn't really make sense to set this flag in
> .get_state().

It is related to the wave form in so far as it allows the driver to
change the wave form as long as the power output remains the same.

> Maybe it makes more sense to put this in a separate argument for a
> variant of pwm_apply_state? something like:
> 
> 	int pwm_apply_state_transition(struct pwm_device *pwm, const struct pwm_state *state, const struct pwm_state_transition *transition);
> 
> and pwm_state_transition can then contain something like this usage
> power concept and maybe also a sync flag that requests that the call
> should only return when the new setting is active and maybe also a
> complete_period flag that requests that the currently running period
> must be completed before the requested setting is implemented.
> 
> OTOH the information "I only care about the relative duty cycle" is
> relevant longer than during the transition to a new setting. (So if
> there are two consumers and one specified to be only interested in the
> relative duty cycle, the other might be allowed to change the common
> period.)

As you said, usage_power does not only apply to one state transition.


> Having said that, I don't like the proposed names. Neither "usage_power"
> nor "pwm_apply_state_transition".
> 
> In a non-representative survey among two hardware engineers and one
> software engineer who already contributed to PWM (!= me) I found out
> that these three have an intuitive right understanding of
> "allow-phase-shift" but have no idea what "usage-power" could mean.

One advantage of usage_power is that it is not limited to phase
shifting. Drivers could do other optimizations as long as the power
output remains the same.


> On a side note: The hardware guys noted that it might make sense to
> align the shifted phases. i.e. instead of shifting channel i by i *
> period/16, it might be better to let the 2nd channel get active when the
> first gets inactive. (i.e. try to keep the count of active channels
> constant).

I am not sure what you mean exactly, because the duty cycles of the
16 outputs are not necessarily the same and can all be active at the
same time. The idea is to spread the edges out as evenly as possible.
Shifting them by period/16 is the best way to smoothen the current
spikes in my opinion and the implementation is also very simple.


> And as already mentioned earlier I still think we should define the
> concept of "usage power" better. It should be clearly defined for a
> driver author which setting they should pick for a given request. This
> removes surprises for consumers and guessing for lowlevel driver
> authors. Also a uniform policy brings conflicts better to light.
> (Something like driver A does the right thing for consumer C and driver
> B makes it right for D. But once D tries to use A things break. (And
> then maybe A is changed to fit D, and C doesn't object because they
> don't read the pwm list resulting in a breakage for C later.))

I added documentation and comments to the header file as a first step
but we can always improve them.

Thanks,
Clemens
Uwe Kleine-König May 7, 2021, 11:18 p.m. UTC | #3
Hello Clemens,

On Fri, May 07, 2021 at 05:47:58PM +0200, Clemens Gruber wrote:
> On Fri, May 07, 2021 at 05:03:17PM +0200, Uwe Kleine-König wrote:
> > On Fri, May 07, 2021 at 03:18:42PM +0200, Clemens Gruber wrote:
> > > diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> > > index 5bb90af4997e..5a73251d28e3 100644
> > > --- a/include/linux/pwm.h
> > > +++ b/include/linux/pwm.h
> > > @@ -54,12 +54,17 @@ enum {
> > >   * @duty_cycle: PWM duty cycle (in nanoseconds)
> > >   * @polarity: PWM polarity
> > >   * @enabled: PWM enabled status
> > > + * @usage_power: If set, the PWM driver is only required to maintain the power
> > > + *               output but has more freedom regarding signal form.
> > > + *               If supported, the signal can be optimized, for example to
> > > + *               improve EMI by phase shifting individual channels.
> > >   */
> > >  struct pwm_state {
> > >  	u64 period;
> > >  	u64 duty_cycle;
> > >  	enum pwm_polarity polarity;
> > >  	bool enabled;
> > > +	bool usage_power;
> > >  };
> > >  
> > >  /**
> > 
> > If we really want to support this usecase, I would prefer to not have it
> > in pwm_state because this concept is not a property of the wave form. So
> > for a driver it doesn't really make sense to set this flag in
> > .get_state().
> 
> It is related to the wave form in so far as it allows the driver to
> change the wave form as long as the power output remains the same.

Yes, the thing I wanted to express is: usage_power is a software thing.
Just from reading the hardware registers you can never know if
usage_power is set or not. So it is conceptually slightly different than
the other members of pwm_state which all are represented 1:1 in
hardware.

> > Maybe it makes more sense to put this in a separate argument for a
> > variant of pwm_apply_state? something like:
> > 
> > 	int pwm_apply_state_transition(struct pwm_device *pwm, const struct pwm_state *state, const struct pwm_state_transition *transition);
> > 
> > and pwm_state_transition can then contain something like this usage
> > power concept and maybe also a sync flag that requests that the call
> > should only return when the new setting is active and maybe also a
> > complete_period flag that requests that the currently running period
> > must be completed before the requested setting is implemented.
> > 
> > OTOH the information "I only care about the relative duty cycle" is
> > relevant longer than during the transition to a new setting. (So if
> > there are two consumers and one specified to be only interested in the
> > relative duty cycle, the other might be allowed to change the common
> > period.)
> 
> As you said, usage_power does not only apply to one state transition.
> 
> > Having said that, I don't like the proposed names. Neither "usage_power"
> > nor "pwm_apply_state_transition".
> > 
> > In a non-representative survey among two hardware engineers and one
> > software engineer who already contributed to PWM (!= me) I found out
> > that these three have an intuitive right understanding of
> > "allow-phase-shift" but have no idea what "usage-power" could mean.
> 
> One advantage of usage_power is that it is not limited to phase
> shifting. Drivers could do other optimizations as long as the power
> output remains the same.

Freedom you give to the lowlevel driver might be a burden to the
consumer. I think it makes sense to split the concept into:

	PWM_ALLOW_PHASE_SHIFT		1
	PWM_SET_RELATIVE_DUTY		2
	PWM_SET_POWER			(PWM_ALLOW_PHASE_SHIFT | PWM_SET_RELATIVE_DUTY)

This way a consumer (e.g. a clock driver) who doesn't care about the
phase shift but wants a fixed period can specify that, and if a consumer
really only cares about the emitted power that's possible, too.

And given that your driver actually only implements a phase shift I
suggest not to generalize more than necessary here; also because the
semantic of usage-power isn't well defined. So this is something where I
agree to Thierry: Let's not solve a problem we don't have. (Though he
comes to a different conclusion here.)

> > On a side note: The hardware guys noted that it might make sense to
> > align the shifted phases. i.e. instead of shifting channel i by i *
> > period/16, it might be better to let the 2nd channel get active when the
> > first gets inactive. (i.e. try to keep the count of active channels
> > constant).
> 
> I am not sure what you mean exactly, because the duty cycles of the
> 16 outputs are not necessarily the same and can all be active at the
> same time. The idea is to spread the edges out as evenly as possible.
> Shifting them by period/16 is the best way to smoothen the current
> spikes in my opinion and the implementation is also very simple.

Yes, the algorithm needed to satisfy this wish is more complicated. And
maybe it even isn't possible to implement it in a sane way, I didn't
think about it much. I just believed them that if you have two channels
that run at 50% it's better to have a phase shift of 50% between them
than 6.25%. Maybe it makes sense to align the start of channel #i+1 (if
allowed) to the end of channel #i to already get a better behaviour on
average than the fixed offset depending on the channel number.

> > And as already mentioned earlier I still think we should define the
> > concept of "usage power" better. It should be clearly defined for a
> > driver author which setting they should pick for a given request. This
> > removes surprises for consumers and guessing for lowlevel driver
> > authors. Also a uniform policy brings conflicts better to light.
> > (Something like driver A does the right thing for consumer C and driver
> > B makes it right for D. But once D tries to use A things break. (And
> > then maybe A is changed to fit D, and C doesn't object because they
> > don't read the pwm list resulting in a breakage for C later.))
> 
> I added documentation and comments to the header file as a first step
> but we can always improve them.

In my book the documentation is inadequate because it doesn't define how
a driver should behave and so doesn't define what the consumer can
expect. With your description all settings I suggested in
https://lore.kernel.org/r/20210413175631.pwbynvwmnn7oog4m@pengutronix.de
are allowed. I don't think this is a good idea.

And given that all people I talked to about "usage-power" were unable to
correctly guess its semantic, I'm convinced that we need a better name.
This is something you cannot outweigh with documentation -- most people
won't read it anyway.

Best regards
Uwe
Clemens Gruber May 31, 2021, 4:12 p.m. UTC | #4
On Sat, May 08, 2021 at 01:18:31AM +0200, Uwe Kleine-König wrote:
> Hello Clemens,
> 
> On Fri, May 07, 2021 at 05:47:58PM +0200, Clemens Gruber wrote:
> > On Fri, May 07, 2021 at 05:03:17PM +0200, Uwe Kleine-König wrote:
> > > On Fri, May 07, 2021 at 03:18:42PM +0200, Clemens Gruber wrote:
> > > > diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> > > > index 5bb90af4997e..5a73251d28e3 100644
> > > > --- a/include/linux/pwm.h
> > > > +++ b/include/linux/pwm.h
> > > > @@ -54,12 +54,17 @@ enum {
> > > >   * @duty_cycle: PWM duty cycle (in nanoseconds)
> > > >   * @polarity: PWM polarity
> > > >   * @enabled: PWM enabled status
> > > > + * @usage_power: If set, the PWM driver is only required to maintain the power
> > > > + *               output but has more freedom regarding signal form.
> > > > + *               If supported, the signal can be optimized, for example to
> > > > + *               improve EMI by phase shifting individual channels.
> > > >   */
> > > >  struct pwm_state {
> > > >  	u64 period;
> > > >  	u64 duty_cycle;
> > > >  	enum pwm_polarity polarity;
> > > >  	bool enabled;
> > > > +	bool usage_power;
> > > >  };
> > > >  
> > > >  /**
> > > 
> > > If we really want to support this usecase, I would prefer to not have it
> > > in pwm_state because this concept is not a property of the wave form. So
> > > for a driver it doesn't really make sense to set this flag in
> > > .get_state().
> > 
> > It is related to the wave form in so far as it allows the driver to
> > change the wave form as long as the power output remains the same.
> 
> Yes, the thing I wanted to express is: usage_power is a software thing.
> Just from reading the hardware registers you can never know if
> usage_power is set or not. So it is conceptually slightly different than
> the other members of pwm_state which all are represented 1:1 in
> hardware.
> 
> > > Maybe it makes more sense to put this in a separate argument for a
> > > variant of pwm_apply_state? something like:
> > > 
> > > 	int pwm_apply_state_transition(struct pwm_device *pwm, const struct pwm_state *state, const struct pwm_state_transition *transition);
> > > 
> > > and pwm_state_transition can then contain something like this usage
> > > power concept and maybe also a sync flag that requests that the call
> > > should only return when the new setting is active and maybe also a
> > > complete_period flag that requests that the currently running period
> > > must be completed before the requested setting is implemented.
> > > 
> > > OTOH the information "I only care about the relative duty cycle" is
> > > relevant longer than during the transition to a new setting. (So if
> > > there are two consumers and one specified to be only interested in the
> > > relative duty cycle, the other might be allowed to change the common
> > > period.)
> > 
> > As you said, usage_power does not only apply to one state transition.
> > 
> > > Having said that, I don't like the proposed names. Neither "usage_power"
> > > nor "pwm_apply_state_transition".
> > > 
> > > In a non-representative survey among two hardware engineers and one
> > > software engineer who already contributed to PWM (!= me) I found out
> > > that these three have an intuitive right understanding of
> > > "allow-phase-shift" but have no idea what "usage-power" could mean.
> > 
> > One advantage of usage_power is that it is not limited to phase
> > shifting. Drivers could do other optimizations as long as the power
> > output remains the same.
> 
> Freedom you give to the lowlevel driver might be a burden to the
> consumer. I think it makes sense to split the concept into:
> 
> 	PWM_ALLOW_PHASE_SHIFT		1
> 	PWM_SET_RELATIVE_DUTY		2
> 	PWM_SET_POWER			(PWM_ALLOW_PHASE_SHIFT | PWM_SET_RELATIVE_DUTY)
> 
> This way a consumer (e.g. a clock driver) who doesn't care about the
> phase shift but wants a fixed period can specify that, and if a consumer
> really only cares about the emitted power that's possible, too.
> 
> And given that your driver actually only implements a phase shift I
> suggest not to generalize more than necessary here; also because the
> semantic of usage-power isn't well defined. So this is something where I
> agree to Thierry: Let's not solve a problem we don't have. (Though he
> comes to a different conclusion here.)
> 
> > > On a side note: The hardware guys noted that it might make sense to
> > > align the shifted phases. i.e. instead of shifting channel i by i *
> > > period/16, it might be better to let the 2nd channel get active when the
> > > first gets inactive. (i.e. try to keep the count of active channels
> > > constant).
> > 
> > I am not sure what you mean exactly, because the duty cycles of the
> > 16 outputs are not necessarily the same and can all be active at the
> > same time. The idea is to spread the edges out as evenly as possible.
> > Shifting them by period/16 is the best way to smoothen the current
> > spikes in my opinion and the implementation is also very simple.
> 
> Yes, the algorithm needed to satisfy this wish is more complicated. And
> maybe it even isn't possible to implement it in a sane way, I didn't
> think about it much. I just believed them that if you have two channels
> that run at 50% it's better to have a phase shift of 50% between them
> than 6.25%. Maybe it makes sense to align the start of channel #i+1 (if
> allowed) to the end of channel #i to already get a better behaviour on
> average than the fixed offset depending on the channel number.
> 
> > > And as already mentioned earlier I still think we should define the
> > > concept of "usage power" better. It should be clearly defined for a
> > > driver author which setting they should pick for a given request. This
> > > removes surprises for consumers and guessing for lowlevel driver
> > > authors. Also a uniform policy brings conflicts better to light.
> > > (Something like driver A does the right thing for consumer C and driver
> > > B makes it right for D. But once D tries to use A things break. (And
> > > then maybe A is changed to fit D, and C doesn't object because they
> > > don't read the pwm list resulting in a breakage for C later.))
> > 
> > I added documentation and comments to the header file as a first step
> > but we can always improve them.
> 
> In my book the documentation is inadequate because it doesn't define how
> a driver should behave and so doesn't define what the consumer can
> expect. With your description all settings I suggested in
> https://lore.kernel.org/r/20210413175631.pwbynvwmnn7oog4m@pengutronix.de
> are allowed. I don't think this is a good idea.
> 
> And given that all people I talked to about "usage-power" were unable to
> correctly guess its semantic, I'm convinced that we need a better name.
> This is something you cannot outweigh with documentation -- most people
> won't read it anyway.

Thierry: Would be great to get your input on this.

Thanks,
Clemens
Thierry Reding June 4, 2021, 9:44 a.m. UTC | #5
On Fri, 7 May 2021 15:18:42 +0200, Clemens Gruber wrote:
> If usage_power is set, the PWM driver is only required to maintain
> the power output but has more freedom regarding signal form.
> 
> If supported, the signal can be optimized, for example to
> improve EMI by phase shifting individual channels.

Applied, thanks!

[1/4] pwm: core: Support new usage_power setting in PWM state
      commit: 9e40ee18a1dc1623a5368d6232aaed52fd29dada
[2/4] pwm: pca9685: Support new usage_power setting in PWM state
      commit: ae16db1fd3a1b8d1713ba6af5cf27be32918d2b8
[3/4] pwm: pca9685: Restrict period change for enabled PWMs
      commit: 6d6e7050276d40b5de97aa950d5d71057f2e2a25
[4/4] pwm: pca9685: Add error messages for failed regmap calls
      commit: 79dd354fe1769ebec695dacfee007eafb1538d0c

Best regards,
Thierry Reding June 4, 2021, 9:49 a.m. UTC | #6
On Mon, May 31, 2021 at 06:12:32PM +0200, Clemens Gruber wrote:
> On Sat, May 08, 2021 at 01:18:31AM +0200, Uwe Kleine-König wrote:
> > Hello Clemens,
> > 
> > On Fri, May 07, 2021 at 05:47:58PM +0200, Clemens Gruber wrote:
> > > On Fri, May 07, 2021 at 05:03:17PM +0200, Uwe Kleine-König wrote:
> > > > On Fri, May 07, 2021 at 03:18:42PM +0200, Clemens Gruber wrote:
> > > > > diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> > > > > index 5bb90af4997e..5a73251d28e3 100644
> > > > > --- a/include/linux/pwm.h
> > > > > +++ b/include/linux/pwm.h
> > > > > @@ -54,12 +54,17 @@ enum {
> > > > >   * @duty_cycle: PWM duty cycle (in nanoseconds)
> > > > >   * @polarity: PWM polarity
> > > > >   * @enabled: PWM enabled status
> > > > > + * @usage_power: If set, the PWM driver is only required to maintain the power
> > > > > + *               output but has more freedom regarding signal form.
> > > > > + *               If supported, the signal can be optimized, for example to
> > > > > + *               improve EMI by phase shifting individual channels.
> > > > >   */
> > > > >  struct pwm_state {
> > > > >  	u64 period;
> > > > >  	u64 duty_cycle;
> > > > >  	enum pwm_polarity polarity;
> > > > >  	bool enabled;
> > > > > +	bool usage_power;
> > > > >  };
> > > > >  
> > > > >  /**
> > > > 
> > > > If we really want to support this usecase, I would prefer to not have it
> > > > in pwm_state because this concept is not a property of the wave form. So
> > > > for a driver it doesn't really make sense to set this flag in
> > > > .get_state().
> > > 
> > > It is related to the wave form in so far as it allows the driver to
> > > change the wave form as long as the power output remains the same.
> > 
> > Yes, the thing I wanted to express is: usage_power is a software thing.
> > Just from reading the hardware registers you can never know if
> > usage_power is set or not. So it is conceptually slightly different than
> > the other members of pwm_state which all are represented 1:1 in
> > hardware.
> > 
> > > > Maybe it makes more sense to put this in a separate argument for a
> > > > variant of pwm_apply_state? something like:
> > > > 
> > > > 	int pwm_apply_state_transition(struct pwm_device *pwm, const struct pwm_state *state, const struct pwm_state_transition *transition);
> > > > 
> > > > and pwm_state_transition can then contain something like this usage
> > > > power concept and maybe also a sync flag that requests that the call
> > > > should only return when the new setting is active and maybe also a
> > > > complete_period flag that requests that the currently running period
> > > > must be completed before the requested setting is implemented.
> > > > 
> > > > OTOH the information "I only care about the relative duty cycle" is
> > > > relevant longer than during the transition to a new setting. (So if
> > > > there are two consumers and one specified to be only interested in the
> > > > relative duty cycle, the other might be allowed to change the common
> > > > period.)
> > > 
> > > As you said, usage_power does not only apply to one state transition.
> > > 
> > > > Having said that, I don't like the proposed names. Neither "usage_power"
> > > > nor "pwm_apply_state_transition".
> > > > 
> > > > In a non-representative survey among two hardware engineers and one
> > > > software engineer who already contributed to PWM (!= me) I found out
> > > > that these three have an intuitive right understanding of
> > > > "allow-phase-shift" but have no idea what "usage-power" could mean.
> > > 
> > > One advantage of usage_power is that it is not limited to phase
> > > shifting. Drivers could do other optimizations as long as the power
> > > output remains the same.
> > 
> > Freedom you give to the lowlevel driver might be a burden to the
> > consumer. I think it makes sense to split the concept into:
> > 
> > 	PWM_ALLOW_PHASE_SHIFT		1
> > 	PWM_SET_RELATIVE_DUTY		2
> > 	PWM_SET_POWER			(PWM_ALLOW_PHASE_SHIFT | PWM_SET_RELATIVE_DUTY)
> > 
> > This way a consumer (e.g. a clock driver) who doesn't care about the
> > phase shift but wants a fixed period can specify that, and if a consumer
> > really only cares about the emitted power that's possible, too.
> > 
> > And given that your driver actually only implements a phase shift I
> > suggest not to generalize more than necessary here; also because the
> > semantic of usage-power isn't well defined. So this is something where I
> > agree to Thierry: Let's not solve a problem we don't have. (Though he
> > comes to a different conclusion here.)
> > 
> > > > On a side note: The hardware guys noted that it might make sense to
> > > > align the shifted phases. i.e. instead of shifting channel i by i *
> > > > period/16, it might be better to let the 2nd channel get active when the
> > > > first gets inactive. (i.e. try to keep the count of active channels
> > > > constant).
> > > 
> > > I am not sure what you mean exactly, because the duty cycles of the
> > > 16 outputs are not necessarily the same and can all be active at the
> > > same time. The idea is to spread the edges out as evenly as possible.
> > > Shifting them by period/16 is the best way to smoothen the current
> > > spikes in my opinion and the implementation is also very simple.
> > 
> > Yes, the algorithm needed to satisfy this wish is more complicated. And
> > maybe it even isn't possible to implement it in a sane way, I didn't
> > think about it much. I just believed them that if you have two channels
> > that run at 50% it's better to have a phase shift of 50% between them
> > than 6.25%. Maybe it makes sense to align the start of channel #i+1 (if
> > allowed) to the end of channel #i to already get a better behaviour on
> > average than the fixed offset depending on the channel number.
> > 
> > > > And as already mentioned earlier I still think we should define the
> > > > concept of "usage power" better. It should be clearly defined for a
> > > > driver author which setting they should pick for a given request. This
> > > > removes surprises for consumers and guessing for lowlevel driver
> > > > authors. Also a uniform policy brings conflicts better to light.
> > > > (Something like driver A does the right thing for consumer C and driver
> > > > B makes it right for D. But once D tries to use A things break. (And
> > > > then maybe A is changed to fit D, and C doesn't object because they
> > > > don't read the pwm list resulting in a breakage for C later.))
> > > 
> > > I added documentation and comments to the header file as a first step
> > > but we can always improve them.
> > 
> > In my book the documentation is inadequate because it doesn't define how
> > a driver should behave and so doesn't define what the consumer can
> > expect. With your description all settings I suggested in
> > https://lore.kernel.org/r/20210413175631.pwbynvwmnn7oog4m@pengutronix.de
> > are allowed. I don't think this is a good idea.
> > 
> > And given that all people I talked to about "usage-power" were unable to
> > correctly guess its semantic, I'm convinced that we need a better name.
> > This is something you cannot outweigh with documentation -- most people
> > won't read it anyway.
> 
> Thierry: Would be great to get your input on this.

In the interest of making forward progress, I've applied this series.
The good thing is that with the current proposal none of this leaks into
ABI, so nothing is set in stone. If ever somebody comes up with better
names we can change them.

Thierry
Uwe Kleine-König June 7, 2021, 6:08 a.m. UTC | #7
Hello Thierry,

On Fri, Jun 04, 2021 at 11:49:37AM +0200, Thierry Reding wrote:
> In the interest of making forward progress, I've applied this series.

I proposed a different approach that in contrast to usage_power:

 - is well defined
   (so driver authors and consumers know what to provide or expect resp.);
 - has good name people understand without reading documentation;
 - fully covers the problem Clemens want to address;
 - fully covers what the only implementing lowlevel driver does; and
 - is easy to implement based on the patches in this series

This is not what I call "forward progress". I take it personal that
after I pointed out technical shortcomings with this patch set and even
suggested a better concept, you didn't even made the effort to argue
but instead simply went on applying the patches.

Can you please point out what I'm missing?

Best regards
Uwe
Thierry Reding June 7, 2021, 2:40 p.m. UTC | #8
On Mon, Jun 07, 2021 at 08:08:27AM +0200, Uwe Kleine-König wrote:
> Hello Thierry,
> 
> On Fri, Jun 04, 2021 at 11:49:37AM +0200, Thierry Reding wrote:
> > In the interest of making forward progress, I've applied this series.
> 
> I proposed a different approach that in contrast to usage_power:
> 
>  - is well defined
>    (so driver authors and consumers know what to provide or expect resp.);
>  - has good name people understand without reading documentation;
>  - fully covers the problem Clemens want to address;
>  - fully covers what the only implementing lowlevel driver does; and
>  - is easy to implement based on the patches in this series
> 
> This is not what I call "forward progress". I take it personal that
> after I pointed out technical shortcomings with this patch set and even
> suggested a better concept, you didn't even made the effort to argue
> but instead simply went on applying the patches.

Forward progress doesn't always mean that everybody gets their way. And
this is nothing personal, so please don't take it that way.

I don't see where you pointed out technical shortcomings with this
patch, you merely pointed out that you don't like this solution and that
there might be a better way to implement it by expanding on the concepts
introduced in this patch series.

As I said, this is now no longer impacting ABI, so we can improve on
this further down the road if we choose to. However, I didn't see any
reason to postpone this any further. This is something that Clemens has
been working on for more than half a year and we've changed our minds
often enough. In my opinion this proposal is good enough.

Thierry
Uwe Kleine-König June 7, 2021, 6:51 p.m. UTC | #9
Hello Thierry,

On Mon, Jun 07, 2021 at 04:40:14PM +0200, Thierry Reding wrote:
> On Mon, Jun 07, 2021 at 08:08:27AM +0200, Uwe Kleine-König wrote:
> > Hello Thierry,
> > 
> > On Fri, Jun 04, 2021 at 11:49:37AM +0200, Thierry Reding wrote:
> > > In the interest of making forward progress, I've applied this series.
> > 
> > I proposed a different approach that in contrast to usage_power:
> > 
> >  - is well defined
> >    (so driver authors and consumers know what to provide or expect resp.);
> >  - has good name people understand without reading documentation;
> >  - fully covers the problem Clemens want to address;
> >  - fully covers what the only implementing lowlevel driver does; and
> >  - is easy to implement based on the patches in this series
> > 
> > This is not what I call "forward progress". I take it personal that
> > after I pointed out technical shortcomings with this patch set and even
> > suggested a better concept, you didn't even made the effort to argue
> > but instead simply went on applying the patches.
> 
> Forward progress doesn't always mean that everybody gets their way.

Do you agree that the usage power flag introduced here isn't well
defined? If you think it is, tell me, what is the maximal and minimal
period a consumer has to expect when .period = 10000 ns is requested.
Assume you have a driver (think pwm-gpio) where a longer period means
more power savings. What is "the reasonable" period that the driver
should configure?

Do you agree that in contrast to usage-power allow-phase-shift is well
defined?

Did you ask people in your bubble what they expect from a usage power
flag for a PWM without first explaining what it does? Did you try to ask
an internet search engine what it suggests when searching for "PWM usage
power"?

Do you agree that allow-phase-shift is good enough to solve Clemens'
problem?

Either you give completely other answers than I do or you don't consider
it bad that consumers don't know what they can expect and that names are
unintuitive.

My problem is not that in the end a solution is picked that wasn't my
favourite. My problem is that I have the impression my arguments were
not considered but simply ignored.

> And this is nothing personal, so please don't take it that way.

If this isn't personal (which is great) then it's a decision that is (at
least for me) obviously wrong and ignoring the good arguments against
this choice without any relevant advantages compared to my suggested
solution. I have problems to not take this personal.

> I don't see where you pointed out technical shortcomings with this
> patch, you merely pointed out that you don't like this solution and that
> there might be a better way to implement it by expanding on the concepts
> introduced in this patch series.

Either you didn't read my mail at all, or you have a different idea
about what you consider a relevant argument. (Well, or you don't care
that your choice is bad. I hope this is only a theoretical possibility.)
Being well defined and having an intuitive name belong into this
"relevant" category in my book.
 
Best regards
Uwe
Uwe Kleine-König June 9, 2021, 8:41 p.m. UTC | #10
Hello Thierry,

On Mon, Jun 07, 2021 at 08:51:58PM +0200, Uwe Kleine-König wrote:
> My problem is not that in the end a solution is picked that wasn't my
> favourite. My problem is that I have the impression my arguments were
> not considered but simply ignored.

Another thing that annoys me is that there are currently ~20 open
patches by me in patchwork, most of them are easy to understand cleanups
and fixes, most of them are older than Clemens' series and most of them
are uncommented by you. And in this situation you apply the only
controversial series.

Uwe
Thierry Reding June 10, 2021, 1:11 p.m. UTC | #11
On Wed, Jun 09, 2021 at 10:41:44PM +0200, Uwe Kleine-König wrote:
> Hello Thierry,
> 
> On Mon, Jun 07, 2021 at 08:51:58PM +0200, Uwe Kleine-König wrote:
> > My problem is not that in the end a solution is picked that wasn't my
> > favourite. My problem is that I have the impression my arguments were
> > not considered but simply ignored.
> 
> Another thing that annoys me is that there are currently ~20 open
> patches by me in patchwork, most of them are easy to understand cleanups
> and fixes, most of them are older than Clemens' series and most of them
> are uncommented by you. And in this situation you apply the only
> controversial series.

Clemens' series is actually older than those cleanups because it's been
in the works for many months now. And the reason why I'm prioritizing
Clemens' series is because it has broader impact and I want to make sure
it gets maximum soaking time in linux-next. Small fixes and cleanups are
less likely to break things, so I'm going to apply them after.

Thierry
diff mbox series

Patch

diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst
index a7ca4f58305a..750734a7f874 100644
--- a/Documentation/driver-api/pwm.rst
+++ b/Documentation/driver-api/pwm.rst
@@ -48,6 +48,10 @@  After being requested, a PWM has to be configured using::
 
 This API controls both the PWM period/duty_cycle config and the
 enable/disable state.
+There is also a usage_power setting: If set, the PWM driver is only required to
+maintain the power output but has more freedom regarding signal form.
+If supported by the driver, the signal can be optimized, for example to improve
+EMI by phase shifting the individual channels of a chip.
 
 The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers
 around pwm_apply_state() and should not be used if the user wants to change
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index c4d5c0667137..4aa5a24cc6c5 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -554,7 +554,8 @@  int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
 	if (state->period == pwm->state.period &&
 	    state->duty_cycle == pwm->state.duty_cycle &&
 	    state->polarity == pwm->state.polarity &&
-	    state->enabled == pwm->state.enabled)
+	    state->enabled == pwm->state.enabled &&
+	    state->usage_power == pwm->state.usage_power)
 		return 0;
 
 	if (chip->ops->apply) {
@@ -1259,6 +1260,9 @@  static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
 		seq_printf(s, " polarity: %s",
 			   state.polarity ? "inverse" : "normal");
 
+		if (state.usage_power)
+			seq_puts(s, " usage_power");
+
 		seq_puts(s, "\n");
 	}
 }
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 5bb90af4997e..5a73251d28e3 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -54,12 +54,17 @@  enum {
  * @duty_cycle: PWM duty cycle (in nanoseconds)
  * @polarity: PWM polarity
  * @enabled: PWM enabled status
+ * @usage_power: If set, the PWM driver is only required to maintain the power
+ *               output but has more freedom regarding signal form.
+ *               If supported, the signal can be optimized, for example to
+ *               improve EMI by phase shifting individual channels.
  */
 struct pwm_state {
 	u64 period;
 	u64 duty_cycle;
 	enum pwm_polarity polarity;
 	bool enabled;
+	bool usage_power;
 };
 
 /**
@@ -188,6 +193,7 @@  static inline void pwm_init_state(const struct pwm_device *pwm,
 	state->period = args.period;
 	state->polarity = args.polarity;
 	state->duty_cycle = 0;
+	state->usage_power = false;
 }
 
 /**
@@ -558,6 +564,7 @@  static inline void pwm_apply_args(struct pwm_device *pwm)
 	state.enabled = false;
 	state.polarity = pwm->args.polarity;
 	state.period = pwm->args.period;
+	state.usage_power = false;
 
 	pwm_apply_state(pwm, &state);
 }