From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: linux-fbdev@vger.kernel.org
Subject: Re: [PATCH] omapfb: Fix regulator API abuse in dss.c and hdmi4.c
Date: Thu, 31 Mar 2016 06:30:11 +0000 [thread overview]
Message-ID: <56FCC3F3.7060907@ti.com> (raw)
In-Reply-To: <1459355376-28507-1-git-send-email-broonie@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 2042 bytes --]
Hi Mark,
On 30/03/16 19:29, Mark Brown wrote:
> The voltage changing code in this driver is broken and should be
> removed. The driver sets a single, exact voltage on probe. Unless
> there is a very good reason for this (which should be documented in
> comments) constraints like this need to be set via the machine
> constraints, voltage setting in a driver is expected to be used in cases
> where the voltage varies at runtime.
>
> In addition client drivers should almost never be calling
> regulator_can_set_voltage(), if the device needs to set a voltage it
> needs to set the voltage and the regulator core will handle the case
> where the regulator is fixed voltage. If the driver can skip setting
> the voltage it should just never set the voltage.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 9 ---------
> drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 9 ---------
> 2 files changed, 18 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> index 0eec073b3919..cfd0e3d5f36a 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> @@ -1180,15 +1180,6 @@ static int dsi_regulator_init(struct platform_device *dsidev)
> return PTR_ERR(vdds_dsi);
> }
>
> - if (regulator_can_change_voltage(vdds_dsi)) {
> - r = regulator_set_voltage(vdds_dsi, 1800000, 1800000);
> - if (r) {
> - devm_regulator_put(vdds_dsi);
> - DSSERR("can't set the DSI regulator voltage\n");
> - return r;
> - }
> - }
> -
This code did fix an issue, see 02b7a32083b9930543663720758de249b4f6a2a3.
Now, even at the time when I wrote that fix, it did feel a bit odd to
me. I have to say I don't remember the discussion that led to the patch,
perhaps it was something along "yes, the driver should not need to do
that, but for the time being do it".
So where are these "machine constraints" defined?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-03-31 6:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-30 16:29 [PATCH] omapfb: Fix regulator API abuse in dss.c and hdmi4.c Mark Brown
2016-03-31 6:30 ` Tomi Valkeinen [this message]
2016-03-31 16:49 ` Mark Brown
2016-03-31 17:11 ` Tomi Valkeinen
2016-03-31 17:39 ` Mark Brown
2016-04-26 16:22 ` Tony Lindgren
2016-04-26 16:37 ` Tomi Valkeinen
2016-04-26 16:42 ` Tony Lindgren
2016-04-26 16:45 ` Tomi Valkeinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56FCC3F3.7060907@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=linux-fbdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).