From: Rob Herring <robh@kernel.org> To: Viresh Kumar <viresh.kumar@linaro.org> Cc: Rafael Wysocki <rjw@rjwysocki.net>, Ulf Hansson <ulf.hansson@linaro.org>, Kevin Hilman <khilman@linaro.org>, Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>, Stephen Boyd <sboyd@codeaurora.org>, "linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>, "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Vincent Guittot <vincent.guittot@linaro.org>, Lina Iyer <lina.iyer@linaro.org>, Rajendra Nayak <rnayak@codeaurora.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org> Subject: Re: [PATCH V3 2/7] PM / OPP: Introduce "domain-performance-state" binding to OPP nodes Date: Tue, 28 Feb 2017 08:10:01 -0600 [thread overview] Message-ID: <CAL_JsqLx6Y=JgaVtJPFwERQ_=5qwqp5EY1+B=cdfBJO55Vct4w@mail.gmail.com> (raw) In-Reply-To: <20170228065711.GD19417@vireshk-i7> On Tue, Feb 28, 2017 at 12:57 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > On 27-02-17, 18:39, Rob Herring wrote: >> On Fri, Feb 24, 2017 at 02:36:34PM +0530, Viresh Kumar wrote: >> > If the consumers don't need the capability of switching to different >> > domain performance states at runtime, then they can simply define their >> > required domain performance state in their nodes directly. >> > >> > But if the device needs the capability of switching to different domain >> > performance states, as they may need to support different clock rates, >> > then the per OPP node can be used to contain that information. >> > >> > This patch introduces the domain-performance-state (already defined by >> > Power Domain bindings) to the per OPP node. >> > >> >> We already have OPP voltages, why are those not sufficient? > > Those are for the regulator that ONLY controls the device, and > domain-performance-state belongs to the parent domain which controls many > devices. > >> > +Example 7: domain-Performance-state: >> > +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require state 2) >> > + >> > +/ { >> > + cpu0_opp_table: opp_table0 { >> > + compatible = "operating-points-v2"; >> > + opp-shared; >> > + >> > + opp@1000000000 { >> > + opp-hz = /bits/ 64 <1000000000>; >> >> Thinking about this some more, there's a problem here that you have no >> link to foo_domain. I guess that resides in the cpu's node? > > Right, the "cpus" node below demonstrates that. > >> > + cpus { >> > + #address-cells = <1>; >> > + #size-cells = <0>; >> > + >> > + cpu@0 { >> > + compatible = "arm,cortex-a9"; >> > + reg = <0>; >> > + clocks = <&clk_controller 0>; >> > + clock-names = "cpu"; >> > + operating-points-v2 = <&cpu0_opp_table>; >> > + power-domains = <&foo_domain>; >> > + }; >> > + }; >> > +}; > >> > + domain-performance-state = <1>; > >> Perhaps instead of a number, this should be a phandle to pstate@1. Then >> you just get the parent if you need to know the domain. > > That's what I did in V2, but then I turned it down considering the parent/child > relationships we may have. > > There are multiple cases we can have: > > A.) DeviceX ---> Parent-domain-1 (Contains Perfomance states) > > B.) DeviceX ---> Parent-domain-1 ---> Parent domain-2 (Contains Perfomance states) > > ---> Parent domain-2 (Contains Perfomance states) > | > | > C.) DeviceX ---> Parent-domain-1 | > | > | > ---> Parent domain-3 (Contains Perfomance states) I'm a bit confused. How does a domain have 2 parent domains? You have the same problem either way. If I have performance state 2 for the device, that corresponds to domain 2 or 3? > The case A.) represents a simple case where the parent domain of the device > contains the performance states. The phandle can work pretty well in this case. > But the other cases B.) and C.) are a bit complicated as the direct parent > domain doesn't allow changing the performance states, but its parents. And so I > went ahead with numbers instead of phandles. Yes, we will still be able to get > to the performance state node with the help of phandles, but will that be the > right thing to do ? > > -- > viresh
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Cc: Rafael Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Kevin Hilman <khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Viresh Kumar <vireshk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>, Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>, "linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org" <linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>, "linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Vincent Guittot <vincent.guittot-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Lina Iyer <lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Rajendra Nayak <rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [PATCH V3 2/7] PM / OPP: Introduce "domain-performance-state" binding to OPP nodes Date: Tue, 28 Feb 2017 08:10:01 -0600 [thread overview] Message-ID: <CAL_JsqLx6Y=JgaVtJPFwERQ_=5qwqp5EY1+B=cdfBJO55Vct4w@mail.gmail.com> (raw) In-Reply-To: <20170228065711.GD19417@vireshk-i7> On Tue, Feb 28, 2017 at 12:57 AM, Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > On 27-02-17, 18:39, Rob Herring wrote: >> On Fri, Feb 24, 2017 at 02:36:34PM +0530, Viresh Kumar wrote: >> > If the consumers don't need the capability of switching to different >> > domain performance states at runtime, then they can simply define their >> > required domain performance state in their nodes directly. >> > >> > But if the device needs the capability of switching to different domain >> > performance states, as they may need to support different clock rates, >> > then the per OPP node can be used to contain that information. >> > >> > This patch introduces the domain-performance-state (already defined by >> > Power Domain bindings) to the per OPP node. >> > >> >> We already have OPP voltages, why are those not sufficient? > > Those are for the regulator that ONLY controls the device, and > domain-performance-state belongs to the parent domain which controls many > devices. > >> > +Example 7: domain-Performance-state: >> > +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require state 2) >> > + >> > +/ { >> > + cpu0_opp_table: opp_table0 { >> > + compatible = "operating-points-v2"; >> > + opp-shared; >> > + >> > + opp@1000000000 { >> > + opp-hz = /bits/ 64 <1000000000>; >> >> Thinking about this some more, there's a problem here that you have no >> link to foo_domain. I guess that resides in the cpu's node? > > Right, the "cpus" node below demonstrates that. > >> > + cpus { >> > + #address-cells = <1>; >> > + #size-cells = <0>; >> > + >> > + cpu@0 { >> > + compatible = "arm,cortex-a9"; >> > + reg = <0>; >> > + clocks = <&clk_controller 0>; >> > + clock-names = "cpu"; >> > + operating-points-v2 = <&cpu0_opp_table>; >> > + power-domains = <&foo_domain>; >> > + }; >> > + }; >> > +}; > >> > + domain-performance-state = <1>; > >> Perhaps instead of a number, this should be a phandle to pstate@1. Then >> you just get the parent if you need to know the domain. > > That's what I did in V2, but then I turned it down considering the parent/child > relationships we may have. > > There are multiple cases we can have: > > A.) DeviceX ---> Parent-domain-1 (Contains Perfomance states) > > B.) DeviceX ---> Parent-domain-1 ---> Parent domain-2 (Contains Perfomance states) > > ---> Parent domain-2 (Contains Perfomance states) > | > | > C.) DeviceX ---> Parent-domain-1 | > | > | > ---> Parent domain-3 (Contains Perfomance states) I'm a bit confused. How does a domain have 2 parent domains? You have the same problem either way. If I have performance state 2 for the device, that corresponds to domain 2 or 3? > The case A.) represents a simple case where the parent domain of the device > contains the performance states. The phandle can work pretty well in this case. > But the other cases B.) and C.) are a bit complicated as the direct parent > domain doesn't allow changing the performance states, but its parents. And so I > went ahead with numbers instead of phandles. Yes, we will still be able to get > to the performance state node with the help of phandles, but will that be the > right thing to do ? > > -- > viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-02-28 14:10 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-02-24 9:06 [PATCH V3 0/7] PM / Domains: Implement domain performance states Viresh Kumar 2017-02-24 9:06 ` [PATCH V3 1/7] PM / Domains: Introduce "performance-states" binding Viresh Kumar 2017-02-24 9:06 ` Viresh Kumar 2017-02-28 0:31 ` Rob Herring 2017-02-28 0:31 ` Rob Herring 2017-02-28 5:36 ` Viresh Kumar 2017-02-28 5:36 ` Viresh Kumar 2017-02-24 9:06 ` [PATCH V3 2/7] PM / OPP: Introduce "domain-performance-state" binding to OPP nodes Viresh Kumar 2017-02-24 9:06 ` Viresh Kumar 2017-02-28 0:39 ` Rob Herring 2017-02-28 0:39 ` Rob Herring 2017-02-28 6:57 ` Viresh Kumar 2017-02-28 6:57 ` Viresh Kumar 2017-02-28 14:10 ` Rob Herring [this message] 2017-02-28 14:10 ` Rob Herring 2017-02-28 15:14 ` Ulf Hansson 2017-02-28 15:14 ` Ulf Hansson 2017-02-28 15:52 ` Rob Herring 2017-02-28 15:52 ` Rob Herring 2017-02-28 19:13 ` Geert Uytterhoeven 2017-03-01 6:14 ` Viresh Kumar 2017-03-01 8:45 ` Geert Uytterhoeven 2017-03-01 8:54 ` Viresh Kumar 2017-03-01 6:27 ` Rajendra Nayak 2017-03-01 23:13 ` Rob Herring 2017-03-02 3:30 ` Rajendra Nayak 2017-03-01 6:12 ` Viresh Kumar 2017-02-24 9:06 ` [PATCH V3 3/7] PM / QOS: Keep common notifier list for genpd constraints Viresh Kumar 2017-02-24 9:06 ` [PATCH V3 4/7] PM / QOS: Add DEV_PM_QOS_PERFORMANCE request Viresh Kumar 2017-02-24 9:06 ` [PATCH V3 5/7] PM / domain: Register for PM QOS performance notifier Viresh Kumar 2017-02-24 9:06 ` [PATCH V3 6/7] PM / Domains: Allow domain performance states to be read from DT Viresh Kumar 2017-02-24 9:06 ` [PATCH V3 7/7] PM / OPP: Add support to parse domain-performance-state Viresh Kumar 2017-03-10 20:38 ` [PATCH V3 0/7] PM / Domains: Implement domain performance states Kevin Hilman 2017-03-13 10:39 ` Viresh Kumar 2017-03-15 10:49 ` Viresh Kumar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAL_JsqLx6Y=JgaVtJPFwERQ_=5qwqp5EY1+B=cdfBJO55Vct4w@mail.gmail.com' \ --to=robh@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=khilman@linaro.org \ --cc=lina.iyer@linaro.org \ --cc=linaro-kernel@lists.linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=nm@ti.com \ --cc=rjw@rjwysocki.net \ --cc=rnayak@codeaurora.org \ --cc=sboyd@codeaurora.org \ --cc=ulf.hansson@linaro.org \ --cc=vincent.guittot@linaro.org \ --cc=viresh.kumar@linaro.org \ --cc=vireshk@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.