On Thursday, July 26, 2012, Kevin Hilman wrote: > "Rafael J. Wysocki" <r...@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-disc...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/