[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-omap
Subject:    Re: [PATCH] omapfb: Fix regulator API abuse in dss.c and hdmi4.c
From:       Mark Brown <broonie () kernel ! org>
Date:       2016-03-31 17:39:42
Message-ID: 20160331173941.GN2350 () sirena ! org ! uk
[Download RAW message or body]

On Thu, Mar 31, 2016 at 08:11:08PM +0300, Tomi Valkeinen wrote:
> 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.

That's not been the case since 2012 but your change was written in
2014...

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

Yes, if no range is specified the regulator API won't touch the set
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...

Will anyone notice?

["signature.asc" (application/pgp-signature)]
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[prev in list] [next in list] [prev in thread] [next in thread]