On Mon, Apr 12, 2021 at 06:27:23PM +0200, Uwe Kleine-König wrote: > On Mon, Apr 12, 2021 at 03:27:41PM +0200, Clemens Gruber wrote: > > Add the flag and corresponding documentation for PWM_USAGE_POWER. > > My concern here in the previous round was that PWM_USAGE_POWER isn't a > name that intuitively suggests its semantic. Do you disagree? I suggested PWM_USAGE_POWER because I think it accurately captures what we want here. > > Cc: Rob Herring <robh+dt@xxxxxxxxxx> > > Signed-off-by: Clemens Gruber <clemens.gruber@xxxxxxxxxxxx> > > --- > > Documentation/devicetree/bindings/pwm/pwm.txt | 3 +++ > > include/dt-bindings/pwm/pwm.h | 1 + > > 2 files changed, 4 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt b/Documentation/devicetree/bindings/pwm/pwm.txt > > index 084886bd721e..fe3a28f887c0 100644 > > --- a/Documentation/devicetree/bindings/pwm/pwm.txt > > +++ b/Documentation/devicetree/bindings/pwm/pwm.txt > > @@ -46,6 +46,9 @@ period in nanoseconds. > > Optionally, the pwm-specifier can encode a number of flags (defined in > > <dt-bindings/pwm/pwm.h>) in a third cell: > > - PWM_POLARITY_INVERTED: invert the PWM signal polarity > > +- PWM_USAGE_POWER: Only care about the power output of the signal. This > > + allows drivers (if supported) to optimize the signals, for example to > > + improve EMI and reduce current spikes. > > IMHO there are too many open questions about which freedom this gives to > the lowlevel driver. If the consumer requests .duty_cycle = 25ns + > .period = 100ns, can the driver provide .duty_cycle = 25s + .period = > 100s which nominally has the same power output? Let's not introduce more > ambiguity than there already is. The freedom given to the driver should be to adjust the signal within reasonable bounds. Changing the time unit by a factor of 1000000000 is not within reason, and I doubt anyone would interpret it that way, even if we didn't document this at all. To be frank I think that quest of yours to try and rid the PWM API of all ambiguity is futile. I've been trying to be lenient because you seem motivated, but I think you're taking this too far. There are always going to be cases that aren't completely clear-cut and where drivers need the flexibility to cheat in order to be useful at all. If we get to a point where everything needs to be 100% accurate, the majority of the PWM controllers won't be usable at all. Don't let perfect be the enemy of good. Thierry
Attachment:
signature.asc
Description: PGP signature
