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? > base_unit values > (base_unit_range / 256), or iow base_unit values using > the 8 most significant bits, cause loss of resolution of the duty-cycle. > E.g. assuming a base_unit_range of 65536 steps, then a base_unit value of > 768 (256 * 3), limits the duty-cycle resolution to 65536 / 768 = 85 steps. > Clamp the max base_unit value to base_unit_range / 32 to ensure a > duty-cycle resolution of at least 32 steps. This limits the maximum > output frequency to 600 KHz / 780 KHz depending on the base clock. This part I don't understand. Why we limiting base unit? I seems like a deliberate regression. -- With Best Regards, Andy Shevchenko _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
