On Sat, Aug 24, 2019 at 05:37:01PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> this series eventually changes the prototype of pwm_apply_state to take
> a const struct pwm_state *, see the last patch for a rationale.
>
> Changes since v2 apart from rebasing and so covering a few more drivers
> is mainly addressing the concern that after state was rounded and
> applied at least pwm_get_state should return the rounded values. See
> patch 2.
I thought a bit on this series and there is a question about it.
Depending on what is considered the right answer for it, this series
might have to change.
The key question is:
- Is pwm_get_state() supposed to return
a) the last requested configuration; or
b) the last actually implemented configuration?
(If the difference is unclear: consider a PWM that can only implement
the following periods:
1 ms, 2 ms, 3 ms, 4 ms, 5 ms, 6 ms, ...
and a consumer requested 4.2 ms. Should pwm_get_state() return .period = 4
ms (assuming this was picked) or 4.2 ms?)
As of v5.3-rc5 it depends on the backend driver. For most of them 4.2 ms
is returned. My series tries to push it to return 4 ms instead. (But
this only works for backends that implement the .get_state() callback.
And it gets more complicated as the drivers are not free of surprises.)
Maybe we need functions for both answers?
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
