[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

Mark Brown broonie at kernel.org
Wed Oct 1 04:31:49 PDT 2014


On Wed, Oct 01, 2014 at 09:41:40AM +0200, Thierry Reding wrote:
> On Tue, Sep 30, 2014 at 06:39:28PM +0100, Mark Brown wrote:

> > No, you don't.  It's only if you start describing the regulators in the
> > PMIC in DT that you run into problems.  Unconfigured regulators won't be
> > touched.

> Okay, that's what I meant. It seems rather odd to add a PMIC DT node but
> omit the description of the regulators that it exposes. Unless the
> regulators are truly unused, as in not connected to any peripherals.

Well, if one does decide to add a description of a regulator which is in
use but which hasn't yet been hooked up to users for some reason then it
needs to be marked as always on.

> > > So unless firmware is updated at the same time, regulators will get
> > > disabled because they are unused.

> > That won't happen unless the regulators are explicitly described, if
> > they are described as unused then this will of course happen.

> With described as unused you mean they have a node in DT, so constraints
> are applied and all that, but no driver actually uses them?

Yes.

> The fundamental issue is that if we start describing simplefb nodes with
> an incomplete set of resources then we're bound to run into problems
> where it'll break once these new resources are described in the DTS. If
> the simplefb node was described in the DTS then this would be less of a
> problem because the resources could be added to the simplefb node at the
> same time.

I'm not sure I follow this.  If we add descriptions of new resources
then it shouldn't be hard to also add information about their use (or
that their description is incomplete) at the same time.

> However given that simplefb is supposed to be generated by firmware this
> is no longer possible. It will inevitably break unless you upgrade the
> DTB and the firmware at the same time. And it was already decided long
> ago that upgrading the firmware should never be a requirement for
> keeping things working.

> I don't see any way to prevent that other than ignoring the resources in
> simplefb completely.

One of the approaches that was being talked about was having a
placeholder in DT that the firmware fills in rather than having to
create the node from whole cloth each time, that makes life a lot
easier.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141001/a63435f7/attachment.sig>


More information about the linux-arm-kernel mailing list