On Mon, Jun 08, 2020 at 01:07:12PM +0200, Hans de Goede wrote: > Hi, > > On 6/8/20 5:50 AM, Andy Shevchenko wrote: > > On Sun, Jun 07, 2020 at 08:18:28PM +0200, Hans de Goede wrote: > > > When the user requests a high enough period ns value, then the > > > calculations in pwm_lpss_prepare() might result in a base_unit value of 0. > > > > > > But according to the data-sheet the way the PWM controller works is that > > > each input clock-cycle the base_unit gets added to a N bit counter and > > > that counter overflowing determines the PWM output frequency. Adding 0 > > > to the counter is a no-op. The data-sheet even explicitly states that > > > writing 0 to the base_unit bits will result in the PWM outputting a > > > continuous 0 signal. > > > > So, and why it's a problem? > > Lets sya the user requests a PWM output frequency of 100Hz on Cherry Trail > which has a 19200000 Hz clock this will result in 100 * 65536 / 19200000 = > 0.3 -> 0 as base-unit value. So instead of getting 100 Hz the user will > now get a pin which is always outputting low. I didn't follow the complete discussion but note that the general rule is: round period down to the next possible implementable period round duty_cycle down to the next possible implementable duty_cycle so if a small enough period (and so a small duty_cycle) is requested it is expected that duty_cycle will be zero. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
