| 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 |
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
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
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
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
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,
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
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
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
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
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
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
Hello Thierry, On Thu, Jun 10, 2021 at 03:11:40PM +0200, Thierry Reding wrote: > On Wed, Jun 09, 2021 at 10:41:44PM +0200, Uwe Kleine-König wrote: > > 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. Hmm, I would have done that differently, but I don't expect that you expected agreement from my side. > Small fixes and cleanups are less likely to break things, so I'm going > to apply them after. I wonder what's the ideal delay for fixes and cleanups in your book. We're two weeks after merging that high-impact patch series and Linus just released -rc7. Best regards Uwe
Hello Thierry, On Mon, Jun 21, 2021 at 08:47:45AM +0200, Uwe Kleine-König wrote: > On Thu, Jun 10, 2021 at 03:11:40PM +0200, Thierry Reding wrote: > > Small fixes and cleanups are less likely to break things, so I'm going > > to apply them after. > > I wonder what's the ideal delay for fixes and cleanups in your book. > We're two weeks after merging that high-impact patch series and Linus > just released -rc7. I don't know Linus' release plan but after reading his -rc7 announcement from last weekend and looking what happend in his tree since then, I wouldn't be surprised if he cuts v5.13 this weekend. Even for small fixes and cleanups I'd prefer to have them in next before the merge window opens. Also if you find an issue for a patch, it's quite demotivating to get feedback when the merge window is already about to open because it's too late then to discuss and rework. The devm_pwmchip_add patch is about to miss its second merge window already ... :-\ Best regards Uwe
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); }
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(-)