On Thu 17 Jun 11:54 CDT 2021, Uwe Kleine-K?nig wrote:
Hello Bjorn,
On Thu, Jun 17, 2021 at 11:38:26AM -0500, Bjorn Andersson wrote:
On Thu 17 Jun 01:24 CDT 2021, Uwe Kleine-K?nig wrote:
On Wed, Jun 16, 2021 at 10:22:17PM -0500, Bjorn Andersson wrote:
+static int ti_sn_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
const struct pwm_state *state)+{
- struct ti_sn65dsi86 *pdata = pwm_chip_to_ti_sn_bridge(chip);
- unsigned int pwm_en_inv;
- unsigned int backlight;
- unsigned int pre_div;
- unsigned int scale;
- int ret;
- if (!pdata->pwm_enabled) {
ret = pm_runtime_get_sync(pdata->dev);if (ret < 0)return ret;ret = regmap_update_bits(pdata->regmap, SN_GPIO_CTRL_REG,SN_GPIO_MUX_MASK << (2 * SN_PWM_GPIO_IDX),SN_GPIO_MUX_SPECIAL << (2 * SN_PWM_GPIO_IDX));if (ret) {dev_err(pdata->dev, "failed to mux in PWM function\n");goto out;}Do you need to do this even if state->enabled is false?
I presume I should be able to explicitly mux in the GPIO function and configure that to output low. But I am not able to find anything in the data sheet that would indicate this to be preferred.
My question targetted a different case. If the PWM is off (!pdata->pwm_enabled) and should remain off (state->enabled is false) you can shortcut here, can you not?
Right, if we're going off->off then we don't need to touch the hardware.
But am I expected to -EINVAL improper period and duty cycle even though enabled is false?
And also, what is the supposed behavior of enabled = false? Is it supposedly equivalent of asking for a duty_cycle of 0?
In my book enabled = false is just syntactic sugar to say: "duty_cycle=0, period=something small". So to answer your questions: if enabled = false, the consumer doesn't really care about period and duty_cycle. Some care that the output becomes inactive, some others don't, so from my POV just emit the inactive level on the output and ignore period and duty_cycle.
Giving this some further thought.
In order to have a known state of the PWM signal we need the sn65dsi86 to be powered. The documentation describes a "suspend mode", but this is currently not implemented in the driver, so there's a large power cost coming from just keeping the pin low when disabled.
As such in the current implementation I use state->enabled to also control if the device should be kept powered, which means that this follows the backlight power status of the pwm-backlight. Which is sufficient as the backlight won't be powered when !state->enabled.
For the typical use case the pwm-backlight has some independent control over gpio and power to toggle the actual backlight. But in the even that this wouldn't be available I think we need to extend the driver to implement the suspend mode.
In which case muxing in the PWM function should probably happen at the time the PWM channel is requested.
This does come at an additional power cost (not as high as keeping the chip awake though), so (in addition to the effort) I think it's reasonable to document this as a limitation for now and implement this as the need arise.
Thanks, Bjorn
Does this already modify the output pin?
Yes, coming out of reset this pin is configured as input, so switching the mux here will effectively start driving the pin.
So please document this in the format the recently added drivers do, too. See e.g. drivers/pwm/pwm-sifive.c. (The idea is to start that with " * Limitations:" to make it easy to grep it.)
Okay, will do. Although I believe that for this driver it makes sense to place such comment close to this function, rather than at the top of the driver.
Yes, agreed.
Best regards Uwe
-- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |