[PATCH v5 05/46] pwm: introduce the pwm_args concept
From: Thierry Reding <hidden>
Date: 2016-04-12 13:15:13
Also in:
dri-devel, intel-gfx, linux-clk, linux-fbdev, linux-input, linux-leds, linux-pwm, linux-rockchip, linux-samsung-soc, lkml
On Tue, Apr 12, 2016 at 03:06:27PM +0200, Boris Brezillon wrote:
On Tue, 12 Apr 2016 13:39:12 +0200 Thierry Reding [off-list ref] wrote:quoted
On Wed, Mar 30, 2016 at 10:03:28PM +0200, Boris Brezillon wrote:quoted
Currently the PWM core mixes the current PWM state with the per-platform reference config (specified through the PWM lookup table, DT definition or directly hardcoded in PWM drivers). Create a pwm_args struct to store this reference config, so that PWM users can differentiate the current config from the reference one. Patch all places where pwm->args should be initialized. We keep the pwm_set_polarity/period() calls until all PWM users are patched to use pwm_args instead of pwm_get_period/polarity().Perhaps a helper would be useful? Something like: static inline void pwm_apply_args(struct pwm_device *pwm, const struct pwm_args *args) { pwm_set_duty_cycle(pwm, args->duty_cycle); pwm_set_period(pwm, args->period); } ? That would make it slightly easier to get rid of it again after all clients have been converted. With the exception of pwm-clps711x all of these args are set at of_xlate time (for DT) or from the lookup table in pwm_get() (for non-DT), so it might even be possible to move this call to the core, so that removal of it will be a one-liner.Okay, I think I misunderstood your suggestion. I thought you wanted this helper to set the reference config, but you actually want to apply a new state based on the PWM reference values. Except that pwm_args does not contain all the required information to apply a full config (args->duty_cycle and args->enable do not exist). This being said, in my v6 I moved the content of pwm_regulator_adjust_pwm_config() (patch 27) into a generic helper (pwm_adjust_config()). This helper is doing pretty much what you're suggesting here (but again, I'm not sure I correctly understood your suggestion :-/).
I'm not suggesting that pwm_apply_args() apply any state. I think we both agreed earlier that the initial state (represented by pwm_args) was never to be automatically applied. What I was suggesting is that we move all the calls to pwm_set_period() and pwm_set_duty_cycle() into a central location to make it easier to remove them later in the series. This is really only temporary, so I don't mind if we leave the calls sprinkled all over the place. At least that way I hope we'll avoid confusion about what we're talking about =) Thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160412/dc4900ae/attachment.sig>