lkml.org 
[lkml]   [2012]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)
Date
On Thursday, July 26, 2012, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> 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@lists.ozlabs.org]
> >>
> >> 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


\
 
 \ /
  Last update: 2012-07-26 23:41    [W:0.084 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site