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 17:11:08 +0000 [thread overview]
Message-ID: <56FD5A2C.7090608@ti.com> (raw)
In-Reply-To: <1459355376-28507-1-git-send-email-broonie@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 2195 bytes --]
On 31/03/16 19:49, Mark Brown wrote:
> On Thu, Mar 31, 2016 at 09:30:11AM +0300, Tomi Valkeinen wrote:
>
>> This code did fix an issue, see 02b7a32083b9930543663720758de249b4f6a2a3.
>
> That change isn't sensible, especially the _can_change_voltage() like I
> said in the commit log.
I may remember wrong, but I think regulator_set_voltage() failed if
regulator_can_change_voltage() returned false. So I ended up having the
'if' there. But I may remember wrong, or maybe it's been changed since.
>> 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".
>
> That wasn't a discusion I was involved in, a quick google suggests it
> might've been off-list.
That's possible. With quick googling, this may have longer history than
the patch I sent.
>> So where are these "machine constraints" defined?
>
> They're the DT. Your machine constraints just seem broken and need to
> be fixed, most likely whoever wrote the constraints for the platform
> completely failed to understand the purpose of constraints and filled in
> the maximum range of voltages that the regulator in use on the board can
> support.
Ok.
Tero, Tony, with a quick look, for example omap5-board-common.dtsi
defines ldo4_reg having range from 1.5 to 1.8. That should be changed to
1.8 only, right? ldo1_reg has a range too, I'm not familiar with that
LDO's use, but it's for camera so my guess is that it should be 1.8 too.
I can have a more thorough look tomorrow, and do a test run on omap5
uevm (with Mark's patch).
I wonder why we have the same code in hdmi4. Again with a quick look,
omap4 boards seem to use vdac for hdmi, and vdac doesn't have any
constraints in twl6030.dtsi, so I presume it's a fixed-voltage.
Anyway, I'm happy to apply this patch (and we need similar for hdmi5,
and also for omapdrm), we just need to do any necessary fixes to the
.dts first.
Although strictly speaking, I guess that's breaking backward
compatibility...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-03-31 17:11 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
2016-03-31 16:49 ` Mark Brown
2016-03-31 17:11 ` Tomi Valkeinen [this message]
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=56FD5A2C.7090608@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).