Re: [PATCH] efikamx: reintroduce Genesi Efika MX Smarttop via devicetree

[Mark Brown]

On Thu, Aug 09, 2012 at 08:40:36AM -0500, Matt Sealey wrote:

> The reason they're set like that is legacy - that's how they're set up
> in a kernel
> (pre-DT) that we know works. Most of those ranges are directly from the Babbage
> reference and stay like that in the Babbage DT too - so there's another broken
> one nobody noticed. I know what those voltages should be, but we're
> leaving that for another patch that restricts the range of voltages
> (it works right
> now, since there are no consumers, nothing CHANGES the voltages as
> configured at U-Boot time, and anything not boot-on is just not listed
> in the DT anyway, but some of them really need to stay on)

Oh dear.  Well, no reason to propagate the breakage - if nothing else it
might well explode if we start doing more aggressive power saving with
the regulators (like having an option for dropping down to the lower end
of the voltage ranges in late init which I keep contemplating, it'd
explode with the boards doing this).

> There are few consumers because the primary ones out there are the display
> controllers and USB hubs and some other things. MMC should be a consumer
> but since on one board we share two MMC slots with one regulator we don't
> want anyone to change the voltage (it breaks spec anyway, since we can't
> provide more than 3.15V with FSL's PMIC and it should be 3.3V by default)
> and since you can't coordinate between MMC hosts on what the lowest voltage
> both cards can support actually is.. having someone change it would be
> bad.

It's not a problem to have fixed voltages, the problem is the
combination of specifying voltage ranges in conjunction with not having
anything there that wants to change the voltage.  Especially with things
like the audio supply, it's clear what that's for and it'd normally get
upset with the voltage changing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/