On Mon, Jan 20, 2014 at 05:32:53PM +0000, Tomasz Figa wrote: > Hi Lorenzo, > > On 16.01.2014 17:34, Lorenzo Pieralisi wrote: > > Hi Tomasz, > > > > thank you for posting this series. I would like to use the DT bindings > > for power domains in the bindings for C-states on ARM: > > > > http://comments.gmane.org/gmane.linux.power-management.general/41012 > > > > and in particular link a given C-state to a given power domain so that the > > kernel will have a way to actually check what devices are lost upon C-state > > entry (and for devices I also mean CPU peripheral like PMUs, GIC CPU IF, > > caches and possibly cpus, all of them already represented with DT nodes). > > > > I have a remark: > > > > - Can we group device nodes under a single power-domain-parent so that > > all devices defined under that parent won't have to re-define a > > power-domain property (a property like interrupt-parent, so to speak) > > > > What do you think ? > > Hmm, I can see potential benefits of such construct on platforms with > clear hierarchy of devices, but to make sure I'm getting it correctly, > is the following what you have in mind? > > soc-domain-x@12340000 { > compatible = "..."; > reg = <...>; > power-domain-parent = <&power_domains DOMAIN_X>; > > device@1000 { > compatible = "..."; > // inherits power-domain = <&power_domains DOMAIN_X> > }; > > device@2000 { > compatible = "..."; > // inherits power-domain = <&power_domains DOMAIN_X> > }; > }; Yes, exactly, it could avoid duplicated data. I still have an issue with nodes that are per-cpu but define just one node (eg PMU), since a CPU might belong in a power-domain on its own (ie one power domain per-CPU) and basically this means that arch-timers, PMU & company should link to multiple power domains, ie one per CPU or we find a way to define a power domain as "banked". I need to think about this a bit more, thanks for your feedback. Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |