[PATCH] sunxi: a10-lime: add regulator nodes

[Maxime Ripard]

On Mon, Apr 13, 2015 at 12:44:28PM +0100, Mark Brown wrote:
> On Mon, Apr 13, 2015 at 10:15:18AM +0200, Maxime Ripard wrote:
> > On Wed, Apr 08, 2015 at 01:35:06PM +0100, Mark Brown wrote:
> > > On Tue, Apr 07, 2015 at 12:17:57PM +0200, Maxime Ripard wrote:
> > > > On Sat, Apr 04, 2015 at 07:47:16PM +0100, Mark Brown wrote:
> 
> > > > > Or the regulator is used by some passive component on the board that
> > > > > doesn't appear in DT (or some driver that doesn't yet have DT support
> > > > > doesn't claim the regulator) and it gets switched off.  Or we power it
> > > > > off and then later discover that we've been placing physical stress on
> > > > > the system.
> 
> > > > Isn't that what the regulator-always-on property is here for?
> 
> > > Only if it's actually added by someone after having looked at the
> > > system...
> 
> > True, but that can also be said for pretty much any DT patch. If you
> > do something wrong in your DT and haven't looked carefuly at your
> > datasheet/schematics, here be dragons.
> 
> There's a difference between actively choosing to do something and
> having it done by default - the goal here is to make sure that if
> someone didn't even look at something we're as safe as possible.

I don't think that discussion is getting anywhere.

I do understand your point, but I also am under the impression that in
order to allow people to get the regulators wrong, we place the
maintainance burden on those who get it right...

> > > > > Providing .dtsis for reference designs can make sense, if there's a
> > > > > widely cloned board with lots of common design elements then reusing
> > > > > that .dtsi is fine but clearly that .dtsi isn't going to enable the full
> > > > > flexibility of the regulators since there will be constraints from that
> > > > > reference design.
> 
> > > > That PMIC is used with various SoCs, so that's not really an
> > > > option. And especially when it comes to regulators, I don't think
> > > > there's really a pattern that emerged yet...
> 
> > > I'm not sure you saw the "reference design" part of the above?
> 
> > I saw that, I was just saying that this doesn't really work for us
> > unfortunately.
> 
> I really don't understand how your explanation follows at all, sorry.
> How does the ability to use the same PMIC with multiple SoCs influence
> reference designs?

Maybe we don't have the same definition for a reference design then,
but to me, it's a board that is used as a starting point for other
vendors to create their boards.

If so, the central piece of this board is actually the SoC. Having
multiple SoCs will prevent any sharing of the DTSI, won't it?

And like I already said, we're not in such a case anyway. Pretty much
all boards we've seen so far wire the regulators differently.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150414/5e6c2651/attachment-0001.sig>