Re: [PATCH v5 08/11] arm: dts: qcom: Add #power-domain-cells property

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 27 April 2015 at 04:32, Rajendra Nayak <rnayak@xxxxxxxxxxxxxx> wrote:
> On 04/24/2015 09:13 PM, Ulf Hansson wrote:
>>
>> On 24 April 2015 at 12:55, Rajendra Nayak <rnayak@xxxxxxxxxxxxxx> wrote:
>>>
>>> On 04/24/2015 03:15 PM, Ulf Hansson wrote:
>>>>
>>>>
>>>> On 14 April 2015 at 15:12, Rajendra Nayak <rnayak@xxxxxxxxxxxxxx> wrote:
>>>>>
>>>>>
>>>>> msm8974 has gcc and mmcc nodes, and apq8084 has a gcc node which
>>>>> implement gdsc powerdomains. Add the #power-domain-cells property
>>>>> to them.
>>>>>
>>>>> Signed-off-by: Rajendra Nayak <rnayak@xxxxxxxxxxxxxx>
>>>>> ---
>>>>>    arch/arm/boot/dts/qcom-apq8084.dtsi | 1 +
>>>>>    arch/arm/boot/dts/qcom-msm8974.dtsi | 2 ++
>>>>>    2 files changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
>>>>> b/arch/arm/boot/dts/qcom-apq8084.dtsi
>>>>> index 1f130bc..55c281c 100644
>>>>> --- a/arch/arm/boot/dts/qcom-apq8084.dtsi
>>>>> +++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
>>>>> @@ -183,6 +183,7 @@
>>>>>                           compatible = "qcom,gcc-apq8084";
>>>>>                           #clock-cells = <1>;
>>>>>                           #reset-cells = <1>;
>>>>> +                       #power-domain-cells = <1>;
>>>>
>>>>
>>>>
>>>> So the PM domain will be apart of the clock-controller. That's a bit
>>>> odd, but I guess the hardware is like that!?
>>>
>>>
>>>
>>> Yes, the gdscs are all part of GCC controller.
>>>
>>>>
>>>> Anyway, what I fail to understand from this patchset is who will be
>>>> the actual consumer of the PM domain? In other words, what devices
>>>> will hold the below property in its DT node?
>>>>
>>>> power_domains = <phandle index>;
>>>>
>>>> This is needed for genpd to have the device at probe time, attached to
>>>> its PM domain.
>>>
>>>
>>>
>>> Any device which belongs to the collapsible power domain (gdsc)
>>> Examples are graphics, camera, video encode/decode block (venus) etc
>>
>>
>> Then I expect those drivers to deploy runtime PM (if not already) and
>> thus gdsc's PM domain will come into play.
>
>
> Most of these drivers aren;t upstream yet. And one of the reasons I am
> trying to get gdsc support upstream is so these drivers can then be
> pushed upstream, with runtime support.

That's great news! I am happy to help reviewing, if you like.

>
>>
>> But how will that relate to the GCC controller?
>>
>> For example when the gdsc's PM domain is about to be powered off,
>> since all the devices within it has be runtime PM suspended. What
>> happens with the GCC controller then?
>
>
> I don;t seem to completely understand what you are asking. Are you
> asking if the GCC controller itself is part of a collapsible power
> domain?

Yes. Sorry for being a bit vague...

If the gdsc's PM domain is powered off, what happens with the GCC's clocks?

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux