linux-kernel - Re: [PATCH v2 2/2] drm/bridge: ti-sn65dsi86: Implement the pwm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210617062449.qwsjcpkyiwzdyfi3@pengutronix.de>
Date:   Thu, 17 Jun 2021 08:24:49 +0200
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     Andrzej Hajda <a.hajda@...sung.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        Robert Foss <robert.foss@...aro.org>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Jonas Karlman <jonas@...boo.se>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Thierry Reding <thierry.reding@...il.com>,
        Lee Jones <lee.jones@...aro.org>,
        Doug Anderson <dianders@...omium.org>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        linux-pwm@...r.kernel.org
Subject: Re: [PATCH v2 2/2] drm/bridge: ti-sn65dsi86: Implement the pwm_chip

Hello Bjorn,

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?

> > 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.)

> > Lets continue the above example with the fixed calculation. So we have:
> > 
> > 	pdata->pwm_refclk_freq = 3333334
> > 	state->period = 100000 [ns]
> > 	state->duty_cycle = 600
> > 	scale = 332
> > 
> > so the actually emitted period = 99899.98002000399 ns
> > 
> > Now you calculate:
> > 
> > 	backlight = 1
> > 
> > which yields an actual duty_cycle of 299.99994 ns, with backlight = 2
> > you would get an actual duty_cycle of 599.99988 ns, which is better. The
> > culprit here is that you divide by state->period but instead should
> > divide by the actual period.
> 
> What do I do about the case where the actual period is lower than the
> requested one and thereby the duty cycle becomes larger than the period?

The general principle is: Pick the biggest possible duty_cycle available
for the just picked period. So in your example you have to clamp it to
period (assuming you can, otherwise pick the next lower possible value).

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)