| Message ID | 20190816093748.11769-1-uwe@kleine-koenig.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [1/3] pwm: atmel: Add link to reference manual | expand |
On 16/08/2019 11:37:48+0200, Uwe Kleine-König wrote: > Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> > --- > drivers/pwm/pwm-atmel.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c > index 42fe7bc043a8..1ddb93db9627 100644 > --- a/drivers/pwm/pwm-atmel.c > +++ b/drivers/pwm/pwm-atmel.c > @@ -7,6 +7,16 @@ > * > * Reference manual for "atmel,at91sam9rl-pwm": > * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf > + * > + * Limitations: > + * - Periods start with the inactive level. > + * - Hardware has to be stopped in general to update settings. > + * > + * Software bugs/possible improvements: > + * - When atmel_pwm_apply() is called with state->enabled=false a change in > + * state->polarity isn't honored. > + * - Instead of sleeping to wait for a completed period, the interrupt > + * functionality could be used. This is definitively not trivial to do right. The main reason it is not done so is that reading PWM_ISR will clear all the bits so it is necessary to be very careful to avoid race conditions. I'm not sure it is worth the effort.
Hello Alexandre, On 8/16/19 10:43 PM, Alexandre Belloni wrote: > On 16/08/2019 11:37:48+0200, Uwe Kleine-König wrote: >> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> >> --- >> drivers/pwm/pwm-atmel.c | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c >> index 42fe7bc043a8..1ddb93db9627 100644 >> --- a/drivers/pwm/pwm-atmel.c >> +++ b/drivers/pwm/pwm-atmel.c >> @@ -7,6 +7,16 @@ >> * >> * Reference manual for "atmel,at91sam9rl-pwm": >> * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf >> + * >> + * Limitations: >> + * - Periods start with the inactive level. >> + * - Hardware has to be stopped in general to update settings. >> + * >> + * Software bugs/possible improvements: >> + * - When atmel_pwm_apply() is called with state->enabled=false a change in >> + * state->polarity isn't honored. >> + * - Instead of sleeping to wait for a completed period, the interrupt >> + * functionality could be used. > > This is definitively not trivial to do right. The main reason it is not > done so is that reading PWM_ISR will clear all the bits so it is > necessary to be very careful to avoid race conditions. I'm not sure it > is worth the effort. I didn't intend to claim it is easy or even that it should be implemented. This was just what I noticed while reading through driver and manual. I thought it was a good idea to document that in case someone finds time and motivation to work on this driver. The first issue pointed out should however be easy to fix and IMHO is a real bug. (Though it's a corner case that hardly ever triggers.) Best regards Uwe
On 16.08.2019 12:37, Uwe Kleine-König wrote: > External E-Mail > > > Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> > --- > drivers/pwm/pwm-atmel.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c > index 42fe7bc043a8..1ddb93db9627 100644 > --- a/drivers/pwm/pwm-atmel.c > +++ b/drivers/pwm/pwm-atmel.c > @@ -7,6 +7,16 @@ > * > * Reference manual for "atmel,at91sam9rl-pwm": > * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf > + * > + * Limitations: > + * - Periods start with the inactive level. Are you talking here about the normal polarity (from documentation: By definition, normal polarity characterizes a signal starts high for the duration of the duty cycle and goes low for the remainder of the period.) If yes, this should be solved by playing with CPOL bit of CMR. > + * - Hardware has to be stopped in general to update settings. Sama5d2 has duty cycle that could be updated on the fly. > + * > + * Software bugs/possible improvements: > + * - When atmel_pwm_apply() is called with state->enabled=false a change in > + * state->polarity isn't honored. I know that when configuring a PWM one should get the current state of the PWM, change it, then pass it to the driver via pwm_apply_state(). In case one would call the pwm_apply_state() with state->enabled = false the state would be stored in PWM specific object (of type struct pwm_device). On the next apply, with enabled = true, all the PWM parameters would be actually applied to hardware. So, until enable=true the PWM state would only be cached by PWM core specific objects (in pwm_apply_state()). > + * - Instead of sleeping to wait for a completed period, the interrupt > + * functionality could be used. > */ > > #include <linux/clk.h> >
On Mon, Aug 19, 2019 at 09:26:04AM +0000, Claudiu.Beznea@microchip.com wrote: > > > On 16.08.2019 12:37, Uwe Kleine-König wrote: > > External E-Mail > > > > > > Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> > > --- > > drivers/pwm/pwm-atmel.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c > > index 42fe7bc043a8..1ddb93db9627 100644 > > --- a/drivers/pwm/pwm-atmel.c > > +++ b/drivers/pwm/pwm-atmel.c > > @@ -7,6 +7,16 @@ > > * > > * Reference manual for "atmel,at91sam9rl-pwm": > > * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf > > + * > > + * Limitations: > > + * - Periods start with the inactive level. > > Are you talking here about the normal polarity (from documentation: By > definition, normal polarity characterizes a signal starts high for the > duration of the duty cycle and goes low for the remainder of the period.) When .polarity = PWM_POLARITY_NORMAL is passed to atmel_pwm_apply() the drivers sets PWM_CMR_CPOL=0 which according to the datasheet (linked above) means: "The output waveform starts at a low level." So maybe just the logic has to be inverted there, but then maybe the output gets active instead of inactive when the PWM is disabled. (Which in my book is ok, but it's Thierry's opinion that counts here.) > If yes, this should be solved by playing with CPOL bit of CMR. > > > + * - Hardware has to be stopped in general to update settings. > > Sama5d2 has duty cycle that could be updated on the fly. There is some functionality in the 9G25, too. I didn't understand it completely but maybe it only helps updating one of period or duty cycle. > > + * > > + * Software bugs/possible improvements: > > + * - When atmel_pwm_apply() is called with state->enabled=false a change in > > + * state->polarity isn't honored. > > I know that when configuring a PWM one should get the current state of the > PWM, change it, then pass it to the driver via pwm_apply_state(). That seems to be a common pattern at least. IMHO letting the consumer just configure the state that should be used should be fine, too. > In case one would call the pwm_apply_state() with state->enabled = > false the state would be stored in PWM specific object (of type struct > pwm_device). On the next apply, with enabled = true, all the PWM > parameters would be actually applied to hardware. So, until > enable=true the PWM state would only be cached by PWM core specific > objects (in pwm_apply_state()). I fail to follow what you mean here. If a PWM runs with (say) normal polarity and you call pwm_apply_state(mypwm, { .polarity = PWM_POLARITY_INVERSED, .enabled = false, }); the apply callback of the lowlevel driver is called and supposed to configure the output to yield a constant high. > > + * - Instead of sleeping to wait for a completed period, the interrupt > > + * functionality could be used. > > */ > > > > #include <linux/clk.h> > > Best regards Uwe
On 19.08.2019 13:46, Uwe Kleine-König wrote: > External E-Mail > > > On Mon, Aug 19, 2019 at 09:26:04AM +0000, Claudiu.Beznea@microchip.com wrote: >> >> >> On 16.08.2019 12:37, Uwe Kleine-König wrote: >>> External E-Mail >>> >>> >>> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> >>> --- >>> drivers/pwm/pwm-atmel.c | 10 ++++++++++ >>> 1 file changed, 10 insertions(+) >>> >>> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c >>> index 42fe7bc043a8..1ddb93db9627 100644 >>> --- a/drivers/pwm/pwm-atmel.c >>> +++ b/drivers/pwm/pwm-atmel.c >>> @@ -7,6 +7,16 @@ >>> * >>> * Reference manual for "atmel,at91sam9rl-pwm": >>> * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf >>> + * >>> + * Limitations: >>> + * - Periods start with the inactive level. >> >> Are you talking here about the normal polarity (from documentation: By >> definition, normal polarity characterizes a signal starts high for the >> duration of the duty cycle and goes low for the remainder of the period.) > > When .polarity = PWM_POLARITY_NORMAL is passed to atmel_pwm_apply() the > drivers sets PWM_CMR_CPOL=0 which according to the datasheet (linked > above) means: "The output waveform starts at a low level." > > So maybe just the logic has to be inverted there, Agree. > but then maybe the > output gets active instead of inactive when the PWM is disabled. Yes, this would happen. Playing again with CPOL when disabling may be a solution. > (Which in my book is ok, but it's Thierry's opinion that counts here.) > >> If yes, this should be solved by playing with CPOL bit of CMR. >> >>> + * - Hardware has to be stopped in general to update settings. >> >> Sama5d2 has duty cycle that could be updated on the fly. > > There is some functionality in the 9G25, too. I didn't understand it > completely but maybe it only helps updating one of period or duty cycle. > >>> + * >>> + * Software bugs/possible improvements: >>> + * - When atmel_pwm_apply() is called with state->enabled=false a change in >>> + * state->polarity isn't honored. >> >> I know that when configuring a PWM one should get the current state of the >> PWM, change it, then pass it to the driver via pwm_apply_state(). > > That seems to be a common pattern at least. IMHO letting the consumer > just configure the state that should be used should be fine, too.> >> In case one would call the pwm_apply_state() with state->enabled = >> false the state would be stored in PWM specific object (of type struct >> pwm_device). On the next apply, with enabled = true, all the PWM >> parameters would be actually applied to hardware. So, until >> enable=true the PWM state would only be cached by PWM core specific >> objects (in pwm_apply_state()). > > I fail to follow what you mean here. If a PWM runs with (say) normal > polarity and you call pwm_apply_state(mypwm, { .polarity = > PWM_POLARITY_INVERSED, .enabled = false, }); the apply callback of the > lowlevel driver is called and supposed to configure the output to yield > a constant high. Ok, I see it now. I'll put it on my queue. Thank you, Claudiu Beznea > >>> + * - Instead of sleeping to wait for a completed period, the interrupt >>> + * functionality could be used. >>> */ >>> >>> #include <linux/clk.h> >>> > > Best regards > Uwe >
Hello Claudiu, On Mon, Aug 19, 2019 at 12:28:59PM +0000, Claudiu.Beznea@microchip.com wrote: > On 19.08.2019 13:46, Uwe Kleine-König wrote: > > On Mon, Aug 19, 2019 at 09:26:04AM +0000, Claudiu.Beznea@microchip.com wrote: > >> On 16.08.2019 12:37, Uwe Kleine-König wrote: > >>> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> > >>> --- > >>> drivers/pwm/pwm-atmel.c | 10 ++++++++++ > >>> 1 file changed, 10 insertions(+) > >>> > >>> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c > >>> index 42fe7bc043a8..1ddb93db9627 100644 > >>> --- a/drivers/pwm/pwm-atmel.c > >>> +++ b/drivers/pwm/pwm-atmel.c > >>> @@ -7,6 +7,16 @@ > >>> * > >>> * Reference manual for "atmel,at91sam9rl-pwm": > >>> * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf > >>> + * > >>> + * Limitations: > >>> + * - Periods start with the inactive level. > >> > >> Are you talking here about the normal polarity (from documentation: By > >> definition, normal polarity characterizes a signal starts high for the > >> duration of the duty cycle and goes low for the remainder of the period.) > > > > When .polarity = PWM_POLARITY_NORMAL is passed to atmel_pwm_apply() the > > drivers sets PWM_CMR_CPOL=0 which according to the datasheet (linked > > above) means: "The output waveform starts at a low level." > > > > So maybe just the logic has to be inverted there, > > Agree. > > > but then maybe the > > output gets active instead of inactive when the PWM is disabled. > > Yes, this would happen. Playing again with CPOL when disabling may be a > solution. Alternatively you could argue that it would be more sensible to drop the requirement for a certain output level on disable. You would have my support here. > > (Which in my book is ok, but it's Thierry's opinion that counts here.) > > > >> If yes, this should be solved by playing with CPOL bit of CMR. > >> > >>> + * - Hardware has to be stopped in general to update settings. > >> > >> Sama5d2 has duty cycle that could be updated on the fly. > > > > There is some functionality in the 9G25, too. I didn't understand it > > completely but maybe it only helps updating one of period or duty cycle. > > > >>> + * > >>> + * Software bugs/possible improvements: > >>> + * - When atmel_pwm_apply() is called with state->enabled=false a change in > >>> + * state->polarity isn't honored. > >> > >> I know that when configuring a PWM one should get the current state of the > >> PWM, change it, then pass it to the driver via pwm_apply_state(). > > > > That seems to be a common pattern at least. IMHO letting the consumer > > just configure the state that should be used should be fine, too.> > >> In case one would call the pwm_apply_state() with state->enabled = > >> false the state would be stored in PWM specific object (of type struct > >> pwm_device). On the next apply, with enabled = true, all the PWM > >> parameters would be actually applied to hardware. So, until > >> enable=true the PWM state would only be cached by PWM core specific > >> objects (in pwm_apply_state()). > > > > I fail to follow what you mean here. If a PWM runs with (say) normal > > polarity and you call pwm_apply_state(mypwm, { .polarity = > > PWM_POLARITY_INVERSED, .enabled = false, }); the apply callback of the > > lowlevel driver is called and supposed to configure the output to yield > > a constant high. > > Ok, I see it now. I'll put it on my queue. See above. The atmel driver is just part of my quest to get a general picture what the common PWM implementation does. Thierry argued that it is natural that a PWM drives the inactive level on disable. I'd say that it would be more natural to not demand a certain level because a) IMHO there are enough implementations that differ here and b) consumers could just configure for duty_cycle=0 if they care. In the case of the imx driver we could just put aside the discussions about how we atomically switch the output to a GPIO to provide the needed level. In case of the atmel driver you'd just invert polarity and be done. Best regards Uwe
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c index 42fe7bc043a8..1ddb93db9627 100644 --- a/drivers/pwm/pwm-atmel.c +++ b/drivers/pwm/pwm-atmel.c @@ -7,6 +7,16 @@ * * Reference manual for "atmel,at91sam9rl-pwm": * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf + * + * Limitations: + * - Periods start with the inactive level. + * - Hardware has to be stopped in general to update settings. + * + * Software bugs/possible improvements: + * - When atmel_pwm_apply() is called with state->enabled=false a change in + * state->polarity isn't honored. + * - Instead of sleeping to wait for a completed period, the interrupt + * functionality could be used. */ #include <linux/clk.h>
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> --- drivers/pwm/pwm-atmel.c | 10 ++++++++++ 1 file changed, 10 insertions(+)