| Message ID | 1429017137-20218-9-git-send-email-rnayak@codeaurora.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On 14 April 2015 at 15:12, Rajendra Nayak <rnayak@codeaurora.org> 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@codeaurora.org> > --- > 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!? 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. > reg = <0xfc400000 0x4000>; > }; > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi > index e265ec1..6184d32 100644 > --- a/arch/arm/boot/dts/qcom-msm8974.dtsi > +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi > @@ -179,6 +179,7 @@ > compatible = "qcom,gcc-msm8974"; > #clock-cells = <1>; > #reset-cells = <1>; > + #power-domain-cells = <1>; > reg = <0xfc400000 0x4000>; > }; > > @@ -186,6 +187,7 @@ > compatible = "qcom,mmcc-msm8974"; > #clock-cells = <1>; > #reset-cells = <1>; > + #power-domain-cells = <1>; > reg = <0xfd8c0000 0x6000>; > }; > Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/24/2015 03:15 PM, Ulf Hansson wrote: > On 14 April 2015 at 15:12, Rajendra Nayak <rnayak@codeaurora.org> 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@codeaurora.org> >> --- >> 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 > >> reg = <0xfc400000 0x4000>; >> }; >> >> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi >> index e265ec1..6184d32 100644 >> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi >> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi >> @@ -179,6 +179,7 @@ >> compatible = "qcom,gcc-msm8974"; >> #clock-cells = <1>; >> #reset-cells = <1>; >> + #power-domain-cells = <1>; >> reg = <0xfc400000 0x4000>; >> }; >> >> @@ -186,6 +187,7 @@ >> compatible = "qcom,mmcc-msm8974"; >> #clock-cells = <1>; >> #reset-cells = <1>; >> + #power-domain-cells = <1>; >> reg = <0xfd8c0000 0x6000>; >> }; >> > > Kind regards > Uffe >
On 04/24/2015 04:25 PM, Rajendra Nayak wrote: > On 04/24/2015 03:15 PM, Ulf Hansson wrote: >> On 14 April 2015 at 15:12, Rajendra Nayak <rnayak@codeaurora.org> 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@codeaurora.org> >>> --- >>> 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. correction. and other clock controllers too, like MMCC. -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 24 April 2015 at 12:55, Rajendra Nayak <rnayak@codeaurora.org> wrote: > On 04/24/2015 03:15 PM, Ulf Hansson wrote: >> >> On 14 April 2015 at 15:12, Rajendra Nayak <rnayak@codeaurora.org> 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@codeaurora.org> >>> --- >>> 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. 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? Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/24/2015 09:13 PM, Ulf Hansson wrote: > On 24 April 2015 at 12:55, Rajendra Nayak <rnayak@codeaurora.org> wrote: >> On 04/24/2015 03:15 PM, Ulf Hansson wrote: >>> >>> On 14 April 2015 at 15:12, Rajendra Nayak <rnayak@codeaurora.org> 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@codeaurora.org> >>>> --- >>>> 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. > > 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? > > Kind regards > Uffe >
On 27 April 2015 at 04:32, Rajendra Nayak <rnayak@codeaurora.org> wrote: > On 04/24/2015 09:13 PM, Ulf Hansson wrote: >> >> On 24 April 2015 at 12:55, Rajendra Nayak <rnayak@codeaurora.org> wrote: >>> >>> On 04/24/2015 03:15 PM, Ulf Hansson wrote: >>>> >>>> >>>> On 14 April 2015 at 15:12, Rajendra Nayak <rnayak@codeaurora.org> 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@codeaurora.org> >>>>> --- >>>>> 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-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/27/2015 01:22 PM, Ulf Hansson wrote: > On 27 April 2015 at 04:32, Rajendra Nayak <rnayak@codeaurora.org> wrote: >> On 04/24/2015 09:13 PM, Ulf Hansson wrote: >>> >>> On 24 April 2015 at 12:55, Rajendra Nayak <rnayak@codeaurora.org> wrote: >>>> >>>> On 04/24/2015 03:15 PM, Ulf Hansson wrote: >>>>> >>>>> >>>>> On 14 April 2015 at 15:12, Rajendra Nayak <rnayak@codeaurora.org> 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@codeaurora.org> >>>>>> --- >>>>>> 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? The clocks need to be turned off explicitly. So for a device to be functional the driver would turn the power switch on, and then enable the needed clocks and the other way around when the device is no longer needed and can be turned off. > > Kind regards > Uffe > -- > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
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>; reg = <0xfc400000 0x4000>; }; diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi index e265ec1..6184d32 100644 --- a/arch/arm/boot/dts/qcom-msm8974.dtsi +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi @@ -179,6 +179,7 @@ compatible = "qcom,gcc-msm8974"; #clock-cells = <1>; #reset-cells = <1>; + #power-domain-cells = <1>; reg = <0xfc400000 0x4000>; }; @@ -186,6 +187,7 @@ compatible = "qcom,mmcc-msm8974"; #clock-cells = <1>; #reset-cells = <1>; + #power-domain-cells = <1>; reg = <0xfd8c0000 0x6000>; };
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@codeaurora.org> --- arch/arm/boot/dts/qcom-apq8084.dtsi | 1 + arch/arm/boot/dts/qcom-msm8974.dtsi | 2 ++ 2 files changed, 3 insertions(+)