Hello Doug, On Tue, Apr 30, 2019 at 07:38:09AM -0700, Doug Anderson wrote: > On Tue, Apr 30, 2019 at 2:28 AM Uwe Kleine-König > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > > > > > Also it should be possible to know the result before actually > > > > configuring the hardware. Otherwise things might already go wrong > > > > because the driver implements a setting that is too far from the > > > > requested configuration. > > > > > > Later in this thread Thierry didn't like the "round rate" idea due to > > > races. One way to solve that could be to indicate to the PWM > > > framework which direction you'd like it to error in: a higher duty > > > cycle or a lower one. > > > > I don't think this would result in settings as optimal as with my > > suggestion. If you don't agree and want to convince me: Show how your > > suggestion would work with a PWM that can implement only multiples of 3 > > for duty_cycle and period and you want 20% duty cycle with period <= 1 > > ms (without making use of the knowledge about the limitation of the > > PWM in the algorithm). > > I guess I was assuming that somehow this would percolate down into an > API call that the PWM driver would implement, so you could make use of > the PWM knowledge in the algorithm. As there are so many different possibilities what could be "best" for a consumer use case, I believe that it would end in a maintenance mess if each lowlevel driver would need a callback to implement each rounding strategy. > ...but I don't have any real strong feelings about this API so I'll > leave it to you and Thierry to hash out what makes you both happy. I look forward to us two agreeing on a best approach ... :-) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | _______________________________________________ Linux-rockchip mailing list Linux-rockchip@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-rockchip
