From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Figa Subject: Re: [PATCH v3 1/3] base: power: Add generic OF-based power domain look-up Date: Tue, 06 May 2014 19:15:21 +0200 Message-ID: <536918A9.6050502@gmail.com> References: <1398271618-28932-1-git-send-email-t.figa@samsung.com> <1398271618-28932-2-git-send-email-t.figa@samsung.com> <535E9163.3070305@wwwdotorg.org> <53690D21.8080807@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53690D21.8080807@wwwdotorg.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Stephen Warren , Ulf Hansson Cc: Mark Rutland , Philipp Zabel , Len Brown , Stephen Boyd , Tomasz Figa , Pavel Machek , Kukjin Kim , Marek Szyprowski , linux-samsung-soc , Russell King , Ian Campbell , Lorenzo Pieralisi , "devicetree@vger.kernel.org" , Kevin Hilman , Pawel Moll , "linux-pm@vger.kernel.org" , Rob Herring , "linux-arm-kernel@lists.infradead.org" , Greg Kroah-Hartman , "Rafael J. Wysocki" , linux-kernel@vg List-Id: devicetree@vger.kernel.org On 06.05.2014 18:26, Stephen Warren wrote: > On 05/06/2014 02:22 AM, Ulf Hansson wrote: >> On 28 April 2014 19:35, Stephen Warren wrote: >>> On 04/23/2014 10:46 AM, Tomasz Figa wrote: >>>> This patch introduces generic code to perform power domain look-up using >>>> device tree and automatically bind devices to their power domains. >>>> Generic device tree binding is introduced to specify power domains of >>>> devices in their device tree nodes. >>>> >>>> Backwards compatibility with legacy Samsung-specific power domain >>>> bindings is provided, but for now the new code is not compiled when >>>> CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This >>>> will change as soon as Exynos power domain code gets converted to use >>>> the generic framework in further patch. >>> >>>> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt >>> >>>> +==Power domain consumers== >>>> + >>>> +Required properties: >>>> + - power-domain : A phandle and power domain specifier as defined by bindings >>>> + of power controller specified by phandle. >>> >>> It seems quite likely that a single logical device could have components >>> in multiple power domains. Consider an HDMI controller with different >>> power domains for the HDMI core, CEC communication, DDC/I2C >>> communication, and the I/O pads, with no clear separation between those >>> two components of the module (no separate register spaces, but the >>> bits/registers are interleaved all together). >>> >>> As such, I think that rather than a "power-domain" property, we need a >>> pair of "power-domains", and "power-domain-names" properties, and >>> preferably with mandatory usage of name-based lookups, rather than >>> allowing a random mix of name-based and index-based lookups like we have >>> with some existing resource bindings. >> >> Each struct device have only one dev_pm_domain pointer, thus a device >> are not able to reside in more than one power domain. >> >> Therefore I doubt this will be very useful, unless I missed your point. :-) > > A struct device is a Linux-internal concept. DT is supposed to represent > the HW in an OS-agnostic fashion, not according to the limitations of > any one OS's driver model. > > It's certainly true that a single logical HW module (represented by a > single DT node) can have parts in multiple power domains. > AFAIK a single DT node is supposed to represent a single _physical_ HW module. It all depends on description granularity, though. A physical chip (or IP block) might be further divided into multiple blocks, so I can imagine some of them being in different power domains than another. Still, based on the fact that in Linux we never needed to specify multiple power domains for a device, is this really a real use case? Anyway, the binding is defined in a way that lets you simply turn the single phandle+specifier into a list of them, if such need ever shows up. Best regards, Tomasz