From: Sudeep Holla <sudeep.holla@arm.com> To: Saravana Kannan <skannan@codeaurora.org> Cc: Georgi Djakov <georgi.djakov@linaro.org>, Rob Herring <robh@kernel.org>, linux-pm@vger.kernel.org, gregkh@linuxfoundation.org, rjw@rjwysocki.net, mturquette@baylibre.com, khilman@baylibre.com, vincent.guittot@linaro.org, bjorn.andersson@linaro.org, amit.kucheria@linaro.org, seansw@qti.qualcomm.com, daidavid1@codeaurora.org, evgreen@chromium.org, mark.rutland@arm.com, lorenzo.pieralisi@arm.com, abailon@baylibre.com, maxime.ripard@bootlin.com, arnd@arndb.de, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, Sudeep Holla <sudeep.holla@arm.com> Subject: Re: [PATCH v9 2/8] dt-bindings: Introduce interconnect binding Date: Wed, 10 Oct 2018 16:02:24 +0100 [thread overview] Message-ID: <20181010150224.GA3583@e107155-lin> (raw) In-Reply-To: <0a276103-15fb-807c-5379-1a35de789290@codeaurora.org> On Wed, Oct 03, 2018 at 11:06:45AM -0700, Saravana Kannan wrote: > > > On 10/03/2018 02:33 AM, Sudeep Holla wrote: > > On Tue, Oct 02, 2018 at 11:56:56AM -0700, Saravana Kannan wrote: > > > On 10/02/2018 04:17 AM, Sudeep Holla wrote: > > [...] > > > > > > Yes, I do understand I have made the same point multiple time and it's > > > > intentional. We need to get the fragmented f/w support story fixed. > > > > Different ARM vendors are doing different things in f/w and ARM sees the > > > > same fragmentation story as before. We have come up with new specification > > > > and my annoying multiple emails are just to constantly remind the same. > > > > > > > > I do understand we have existing implementations to consider, but fixing > > > > the functionality in arbitrary way is not a good design and it better > > > > to get them fixed for future. > > > I believe the fragmentation you are referring to is in the > > > interface/communication protocol. I see the benefit of standardizing that as > > > long as the standard actually turns out to be good. But that's completely > > > separate from what the FW can/can't do. Asking to standardize what the FW > > > can/can't do doesn't seem realistic as each chip vendor will have different > > > priorities - power, performance, cost, chip area, etc. It's the conflation > > > of these separate topics that doesn't help IMHO. > > I agree on interface/communication protocol fragmentation and firmware > > can implement whatever the vendor wish. What I was also referring was > > the mix-n-match approach which should be avoided. > > > > e.g. Device A and B's PM is managed completely by firmware using OSPM hints > > Suppose Device X's PM is dependent on Device A and B, in which case it's > > simpler and cleaner to leave Device X PM to firmware. Reading the state > > of A and B and using that as hint for X is just overhead which firmware > > can manage better. That was my main concern here: A=CPU and B=some other > > device and X is inter-connect to which A and B are connected. > > > > If CPU OPPs are obtained from f/w and this inter-connect from DT, mapping > > then is a mess and that's what I was concerned. I am sorry if that's not > > the scenario here, I may have mistaken then. > > > What you are asking would be an ideal case, but this is not an ideal world. Agreed. > There are tons of constraints for each chip vendor. Saying you can't mix and > match makes perfect the enemy of the good. We can have endless debate on that. > Adding FW support for A and B might make them optimal. OK... > But adding support for X might not be possible for > multiple real world constraints (chip area, cost, time to market, etc). but is not a good design though. If f/w blindly changes DVFS for X based on OS request, then there's possibility for clkscrew kind of exploits still though moving A/B to f/w was to avoid it. The chances are low but not zero. > Saying "either do it all or do nothing" is going to hold back a lot progress > that can come in increments. Heck, we do the same thing in the kernel. We'll > add basic simple features first and then improve on them. Why is it suddenly > frowned up if a FW/HW follows the same approach? I'll just have to agree to > disagree with you on this view point. > I agree on adding basic and then improve on that policy. But it's not fair to compare this mix-'n'-match approach to that. Sorry but I disagree with the comparison here. -- Regards, Sudeep
WARNING: multiple messages have this Message-ID (diff)
From: sudeep.holla@arm.com (Sudeep Holla) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v9 2/8] dt-bindings: Introduce interconnect binding Date: Wed, 10 Oct 2018 16:02:24 +0100 [thread overview] Message-ID: <20181010150224.GA3583@e107155-lin> (raw) In-Reply-To: <0a276103-15fb-807c-5379-1a35de789290@codeaurora.org> On Wed, Oct 03, 2018 at 11:06:45AM -0700, Saravana Kannan wrote: > > > On 10/03/2018 02:33 AM, Sudeep Holla wrote: > > On Tue, Oct 02, 2018 at 11:56:56AM -0700, Saravana Kannan wrote: > > > On 10/02/2018 04:17 AM, Sudeep Holla wrote: > > [...] > > > > > > Yes, I do understand I have made the same point multiple time and it's > > > > intentional. We need to get the fragmented f/w support story fixed. > > > > Different ARM vendors are doing different things in f/w and ARM sees the > > > > same fragmentation story as before. We have come up with new specification > > > > and my annoying multiple emails are just to constantly remind the same. > > > > > > > > I do understand we have existing implementations to consider, but fixing > > > > the functionality in arbitrary way is not a good design and it better > > > > to get them fixed for future. > > > I believe the fragmentation you are referring to is? in the > > > interface/communication protocol. I see the benefit of standardizing that as > > > long as the standard actually turns out to be good. But that's completely > > > separate from what the FW can/can't do. Asking to standardize what the FW > > > can/can't do doesn't seem realistic as each chip vendor will have different > > > priorities - power, performance, cost, chip area, etc. It's the conflation > > > of these separate topics that doesn't help IMHO. > > I agree on interface/communication protocol fragmentation and firmware > > can implement whatever the vendor wish. What I was also referring was > > the mix-n-match approach which should be avoided. > > > > e.g. Device A and B's PM is managed completely by firmware using OSPM hints > > Suppose Device X's PM is dependent on Device A and B, in which case it's > > simpler and cleaner to leave Device X PM to firmware. Reading the state > > of A and B and using that as hint for X is just overhead which firmware > > can manage better. That was my main concern here: A=CPU and B=some other > > device and X is inter-connect to which A and B are connected. > > > > If CPU OPPs are obtained from f/w and this inter-connect from DT, mapping > > then is a mess and that's what I was concerned. I am sorry if that's not > > the scenario here, I may have mistaken then. > > > What you are asking would be an ideal case, but this is not an ideal world. Agreed. > There are tons of constraints for each chip vendor. Saying you can't mix and > match makes perfect the enemy of the good. We can have endless debate on that. > Adding FW support for A and B might make them optimal. OK... > But adding support for X might not be possible for > multiple real world constraints (chip area, cost, time to market, etc). but is not a good design though. If f/w blindly changes DVFS for X based on OS request, then there's possibility for clkscrew kind of exploits still though moving A/B to f/w was to avoid it. The chances are low but not zero. > Saying "either do it all or do nothing" is going to hold back a lot progress > that can come in increments. Heck, we do the same thing in the kernel. We'll > add basic simple features first and then improve on them. Why is it suddenly > frowned up if a FW/HW follows the same approach? I'll just have to agree to > disagree with you on this view point. > I agree on adding basic and then improve on that policy. But it's not fair to compare this mix-'n'-match approach to that. Sorry but I disagree with the comparison here. -- Regards, Sudeep
next prev parent reply other threads:[~2018-10-10 15:02 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-31 14:01 [PATCH v9 0/8] Introduce on-chip interconnect API Georgi Djakov 2018-08-31 14:01 ` Georgi Djakov 2018-08-31 14:01 ` [PATCH v9 1/8] interconnect: Add generic " Georgi Djakov 2018-08-31 14:01 ` Georgi Djakov 2018-08-31 14:01 ` [PATCH v9 2/8] dt-bindings: Introduce interconnect binding Georgi Djakov 2018-08-31 14:01 ` Georgi Djakov 2018-09-25 18:02 ` Rob Herring 2018-09-25 18:02 ` Rob Herring 2018-09-26 14:34 ` Jordan Crouse 2018-09-26 14:34 ` Jordan Crouse 2018-10-01 20:56 ` Saravana Kannan 2018-10-01 20:56 ` Saravana Kannan 2018-10-01 21:26 ` Jordan Crouse 2018-10-01 21:26 ` Jordan Crouse 2018-10-01 21:51 ` Saravana Kannan 2018-10-01 21:51 ` Saravana Kannan 2018-09-26 14:42 ` Georgi Djakov 2018-09-26 14:42 ` Georgi Djakov 2018-09-26 14:48 ` Sudeep Holla 2018-09-26 14:48 ` Sudeep Holla 2018-09-26 15:03 ` Georgi Djakov 2018-09-26 15:03 ` Georgi Djakov 2018-10-01 23:49 ` Saravana Kannan 2018-10-01 23:49 ` Saravana Kannan 2018-10-02 11:17 ` Sudeep Holla 2018-10-02 11:17 ` Sudeep Holla 2018-10-02 18:56 ` Saravana Kannan 2018-10-02 18:56 ` Saravana Kannan 2018-10-03 9:33 ` Sudeep Holla 2018-10-03 9:33 ` Sudeep Holla 2018-10-03 18:06 ` Saravana Kannan 2018-10-03 18:06 ` Saravana Kannan 2018-10-10 15:02 ` Sudeep Holla [this message] 2018-10-10 15:02 ` Sudeep Holla 2018-11-27 18:05 ` Georgi Djakov 2018-11-27 18:05 ` Georgi Djakov 2018-08-31 14:01 ` [PATCH v9 3/8] interconnect: Allow endpoints translation via DT Georgi Djakov 2018-08-31 14:01 ` Georgi Djakov 2018-08-31 14:01 ` [PATCH v9 4/8] interconnect: Add debugfs support Georgi Djakov 2018-08-31 14:01 ` Georgi Djakov 2018-08-31 14:01 ` [PATCH v9 5/8] interconnect: qcom: Add RPM communication Georgi Djakov 2018-08-31 14:01 ` Georgi Djakov 2018-09-25 18:17 ` Rob Herring 2018-09-25 18:17 ` Rob Herring 2018-10-02 11:02 ` Georgi Djakov 2018-10-02 11:02 ` Georgi Djakov 2018-08-31 14:01 ` [PATCH v9 6/8] dt-bindings: interconnect: Document qcom,msm8916 NoC bindings Georgi Djakov 2018-08-31 14:01 ` [PATCH v9 6/8] dt-bindings: interconnect: Document qcom, msm8916 " Georgi Djakov 2018-09-25 18:22 ` [PATCH v9 6/8] dt-bindings: interconnect: Document qcom,msm8916 " Rob Herring 2018-09-25 18:22 ` Rob Herring 2018-10-02 11:02 ` Georgi Djakov 2018-10-02 11:02 ` Georgi Djakov 2018-08-31 14:01 ` [PATCH v9 7/8] interconnect: qcom: Add msm8916 interconnect provider driver Georgi Djakov 2018-08-31 14:01 ` Georgi Djakov 2018-08-31 14:01 ` [PATCH v9 8/8] MAINTAINERS: add a maintainer for the interconnect API Georgi Djakov 2018-08-31 14:01 ` Georgi Djakov 2018-09-04 10:24 ` [PATCH v9 0/8] Introduce on-chip " Amit Kucheria 2018-09-04 10:24 ` Amit Kucheria 2018-09-04 10:24 ` Amit Kucheria 2018-09-04 23:36 ` Stephen Rothwell 2018-09-04 23:36 ` Stephen Rothwell 2018-09-04 23:36 ` Stephen Rothwell 2018-09-05 14:50 ` Georgi Djakov 2018-09-05 14:50 ` Georgi Djakov 2018-09-05 14:50 ` Georgi Djakov 2018-09-05 15:05 ` Stephen Rothwell 2018-09-05 15:05 ` Stephen Rothwell 2018-09-05 15:05 ` Stephen Rothwell
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=20181010150224.GA3583@e107155-lin \ --to=sudeep.holla@arm.com \ --cc=abailon@baylibre.com \ --cc=amit.kucheria@linaro.org \ --cc=arnd@arndb.de \ --cc=bjorn.andersson@linaro.org \ --cc=daidavid1@codeaurora.org \ --cc=devicetree@vger.kernel.org \ --cc=evgreen@chromium.org \ --cc=georgi.djakov@linaro.org \ --cc=gregkh@linuxfoundation.org \ --cc=khilman@baylibre.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=lorenzo.pieralisi@arm.com \ --cc=mark.rutland@arm.com \ --cc=maxime.ripard@bootlin.com \ --cc=mturquette@baylibre.com \ --cc=rjw@rjwysocki.net \ --cc=robh@kernel.org \ --cc=seansw@qti.qualcomm.com \ --cc=skannan@codeaurora.org \ --cc=vincent.guittot@linaro.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.