Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Rafael J. Wysocki]

On Thursday, July 26, 2012, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@xxxxxxx> writes:
> 
> > On Wednesday, July 25, 2012, Arnd Bergmann wrote:
> >> On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
> >> > On Tuesday, July 24, 2012, Arnd Bergmann wrote:
> >> > > On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
> >> > > > On Tuesday, July 24, 2012, Arnd Bergmann wrote:
> >> > > > > On Saturday 21 July 2012, Rafael J. Wysocki wrote:
> >> > > 
> >> > > > > 
> >> > > > > Sorry for taking so long to reply. I am really not that familiar with the
> >> > > > > power domain requirements, but I do have two comments on your approach:
> >> > > > > 
> >> > > > > * I think when we want to add a generic concept to the device tree such
> >> > > > >   as power domains, we should always make it specified in a generic way.
> >> > > > 
> >> > > > Do we really want that?  I'm a bit skeptical, because apparently nobody
> >> > > > cares, as the (zero) response to this patchset evidently indicates and
> >> > > > since nobody cares, it's probably better not to add such "generic" things
> >> > > > just yet.
> 
> Sorry to jump in late, but it's been another busy dev cycle and I
> haven't had the time to look at this series in detail.  But just so you
> know that somebody cares, we're also interested in bindings that will be
> useful on other SoCs for PM domains.
> 
> However, since OMAP powerdomain support pre-dates generic powerdomains ,
> the "generic" power domains aren't quite generic enough get for OMAP,
> and I haven't had the time to extend the generic code, we haven't yet
> moved to generic powerdomains.
> 
> >> > > 
> >> > > Well, the trouble with bindings is that they are much harder to change
> >> > > later, at least in incompatible ways. 
> >> > 
> >> > Hmm, so I think you wanted to say that it might be burdensome to retain the
> >> > code handling the old binding once we had started to use a new generic one.
> >> > 
> >> > I can agree with that, but that's quite similar to user space interfaces.
> >> > Once we've exposed a user space interface of some kind and someone starts
> >> > to use it, we'll have to maintain it going forward for the user in question.
> >> > However, there is a way to deprecate old user space interfaces and it has
> >> > happened.
> >> > 
> >> > In this particular case the burden would be on Renesas, but I don't think it
> >> > would affect anybody else.
> >> 
> >> [adding devicetree-discuss@xxxxxxxxxxxxxxxx]
> >> 
> >> In case of user space interfaces, we also try very hard to avoid cases
> >> where we know that we will have to change things later.
> >
> > [Cough, cough]  Yeah, sure.  Except that that's rather difficult to anticipate
> > usually.
> >
> >> I don't think it's that hard to define a generic binding here, we just
> >> need to make sure it's extensible.
> >> 
> >> One thing I would like to avoid is having to add to every single
> >> device binding two separate optional properties defined like
> >> 
> >> diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
> >> index 2b584ca..353152e 100644
> >> --- a/Documentation/devicetree/bindings/mmc/mmci.txt
> >> +++ b/Documentation/devicetree/bindings/mmc/mmci.txt
> >> @@ -13,3 +13,9 @@ Required properties:
> >>  Optional properties:
> >>  - mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable
> >>  - mmc-cap-sd-highspeed   : indicates whether SD is high speed capable
> >> +- pm-domain		 : a phandle pointing to the power domain
> >> +			   controlling this device
> >> +			   See ../pm-domain/generic.txt
> >> +- renesas,pm-domain	 : a string with the name of the power domain
> >> +			   controlling this device.
> >> +			   See ../pm-domain/renesas.txt
> >> 
> >> Even if you say that the burden is only on Renesas to maintain all those
> >> changes to every binding they use, there is also a burden on people trying
> >> to understand the binding and deciding which one to use.
> >
> > What about (tongue in cheek) "renesas,hwmod", then?  That won't be confused
> > with the generic "pm-domain" in any way, will it?  And since TI did that, we
> > surely should be allowed to do it as well, no?
> >
> > Seriously, I'm not fundamentally opposed to using phandles for that in analogy
> > with regulators, but I'm afraid we won't get it right from the start and it
> > will turn out that we need to change the definition of the binding somehow
> > and _that_ is going to be painful.  Pretty much like changing generic user
> > space interfaces is (as opposed to changing interfaces of limited scope).
> >
> > However, if that route is taken, I'll expect you to require TI to change their
> > hwmod binding in the analogous way.
> 
> FWIW, we're already working on making ti,hwmods disappear.  That was a
> temporary step to allow us to easily migrate to DT using our existing,
> in-tree description of device IP blocks (hwmods.)

I see.  Obviously I didn't know that. :-)

> That being said, I'm not sure why ti,hwmods is being used as an example
> for powerdomains.  hwmods describe the integration of SoC IP blocks
> (base addr, IRQ, DMA channel etc., which are being moved to DT) as well
> as a bunch of SoC specific PM register descriptions.  This stuff is
> SoC-specific PM register layout, so being very SoC specific, it has the
> 'ti' prefix in the DT binding.
> 
> Anyways, I hope to have a closer look this week, and I know Benoit
> Cousson (CC'd) has some ideas for DT bindings for power domains as well.
> Unfortunately, he's out until next week.

No stress, I won't have the time to look into this again any time soon,
perhaps not even before San Diego.

Thanks,
Rafael
--
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/