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, 3 Oct 2018 10:33:46 +0100 [thread overview] Message-ID: <20181003093346.GA12570@e107155-lin> (raw) In-Reply-To: <c17450ce-fc25-e792-b91b-51106f032542@codeaurora.org> 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. -- 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, 3 Oct 2018 10:33:46 +0100 [thread overview] Message-ID: <20181003093346.GA12570@e107155-lin> (raw) In-Reply-To: <c17450ce-fc25-e792-b91b-51106f032542@codeaurora.org> 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. -- Regards, Sudeep
next prev parent reply other threads:[~2018-10-03 9:33 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 [this message] 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 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=20181003093346.GA12570@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.