On Thu, 15 Aug 2019 at 20:25, Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > On Thu, Aug 15, 2019 at 07:05:53PM +0800, Baolin Wang wrote: > > On Thu, 15 Aug 2019 at 18:11, Uwe Kleine-König > > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > > > > > Hello, > > > > > > On Thu, Aug 15, 2019 at 05:34:02PM +0800, Baolin Wang wrote: > > > > On Thu, 15 Aug 2019 at 16:54, Uwe Kleine-König > > > > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > > > > On Thu, Aug 15, 2019 at 04:16:32PM +0800, Baolin Wang wrote: > > > > > > On Thu, 15 Aug 2019 at 14:15, Uwe Kleine-König > > > > > > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > > > > > > On Thu, Aug 15, 2019 at 11:34:27AM +0800, Baolin Wang wrote: > > > > > > > > On Wed, 14 Aug 2019 at 23:03, Uwe Kleine-König > > > > > > > > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > > > > > > > > On Wed, Aug 14, 2019 at 08:46:11PM +0800, Baolin Wang wrote: > > > > > > > > > > + * To keep the maths simple we're always using MOD = SPRD_PWM_MOD_MAX. > > > > > > > > > > > > > > > > > > Did you spend some thoughts about how wrong your period can get because > > > > > > > > > of that "lazyness"? > > > > > > > > > > > > > > > > > > Let's assume a clk rate of 100/3 MHz. Then the available period lengths > > > > > > > > > are: > > > > > > > > > > > > > > > > > > PRESCALE = 0 -> period = 7.65 µs > > > > > > > > > PRESCALE = 1 -> period = 15.30 µs > > > > > > > > > ... > > > > > > > > > PRESCALE = 17 -> period = 137.70 µs > > > > > > > > > PRESCALE = 18 -> period = 145.35 µs > > > > > > > > > > > > > > > > > > So the error can be up to (nearly) 7.65 µs (or in general > > > > > > > > > > > > > > > > Yes, but for our use case (pwm backlight), the precision can meet our > > > > > > > > requirement. Moreover, we usually do not change the period, just > > > > > > > > adjust the duty to change the back light. > > > > > > > > > > > > > > Is this a license requirement for you SoC to only drive a backlight with > > > > > > > the PWM? The idea of having a PWM driver on your platform is that it can > > > > > > > also be used to control a step motor or a laser. > > > > > > > > > > > > Not a license requirement. Until now we have not got any higher > > > > > > precision requirements, and we've run this driver for many years in > > > > > > our downstream kernel. > > > > > > > > > > I understood that you're not ambitious to do something better than "it > > > > > worked for years". > > > > > > > > How do you know that? > > > > > > I showed you how you could match the requested PWM output better and > > > you refused telling it worked for years and the added precision isn't > > > necessary for a backlight. > > > > Please I said the reason, it is not that I do not want a better > > precision. The problem is we do not know how much precision to be > > asked by users if no use case > > I don't understand the problem here. If you are asked for period = > 145340 ns and configure the hardware to yield 137700 ns in reply to that > but you could provide 144780 ns I don't understand why you need a use > case as 144780 ns is objectively better than 137700 ns. A better match You are wrong, we will provide 145350 ns with DIV_ROUND_CLOSEST_ULL()., which is better than your 144780. > has only upsides, it doesn't hurt people how don't care about a few > micro seconds in the one or the other direction. OK, your CPU needs a > few more cycles to find the better configuration but that's a poor > argument. With only a backlight as use case you could even hardcode > PRESCALE = 0 without any problems and have the needed calculations a bit > cheaper. > > > > > What I mean is use DIV_ROUND_CLOSEST_ULL we can get a nearer value to > > > > the requested like above example. > > > > > > But given that it's unclear if 137700 ns or 145350 ns is better when > > > 145340 ns was requested this is not a strong argument to use > > > DIV_ROUND_CLOSEST_ULL. With the global picture for the pwm framework in > > > mind it is sensible to request the same rounding from all drivers to get > > > a consistent behaviour. And I believe the maths with rounding down is > > > easier than when rounding up or nearest. That's why I argue in this > > > direction. > > > > Let's wait for Thierry's suggestion to get a consensus firstly. > > OK. I'm not sure you want to wait until Thierry and I agree on a > solution here though :-) > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | http://www.pengutronix.de/ | -- Baolin Wang Best Regards
