From: Georgi Djakov <georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> To: Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, evgreen-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Subject: Re: [PATCH] drm/msm/a6xx: Add support for an interconnect path Date: Tue, 12 Feb 2019 16:07:35 +0200 [thread overview] Message-ID: <99ab72bf-9e06-bcaf-85ec-33d4037a54cd@linaro.org> (raw) In-Reply-To: <20190212101624.GA20915-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> Hi Greg, On 2/12/19 12:16, Greg KH wrote: > On Tue, Feb 12, 2019 at 11:52:38AM +0200, Georgi Djakov wrote: >> From: Jordan Crouse <jcrouse@codeaurora.org> >> >> Try to get the interconnect path for the GPU and vote for the maximum >> bandwidth to support all frequencies. This is needed for performance. >> Later we will want to scale the bandwidth based on the frequency to >> also optimize for power but that will require some device tree >> infrastructure that does not yet exist. >> >> v6: use icc_set_bw() instead of icc_set() >> v5: Remove hardcoded interconnect name and just use the default >> v4: Don't use a port string at all to skip the need for names in the DT >> v3: Use macros and change port string per Georgi Djakov >> >> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> >> Acked-by: Rob Clark <robdclark@gmail.com> >> Reviewed-by: Evan Green <evgreen@chromium.org> >> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> >> --- >> >> Hi Greg, >> >> If not too late, could you please take this patch into char-misc-next. >> It is adding the first consumer of the interconnect API. We are just >> getting the code in place, without making it functional yet, as some >> DT bits are still needed to actually enable it. We have Rob's Ack to >> merge this together with the interconnect code. This patch has already >> spent some time in linux-next without any issues. > > I have a question about the interconnect code. Last week I saw a > presentation about the resctrl/RDT code from ARM that is coming (MPAM), > and it really looks like the same functionality as this interconnect > code. In fact, this code looks like the existing resctrl stuff, right? Thanks for the question! It's nice that MPAM is moving forward. When i looked into the MPAM draft spec an year ago, it was an optional extension mentioning mostly use-cases with VMs on server systems. But anyway, MPAM is only available for ARMv8.2+ cores as an optional extension and aarch32 is not supported. In contrast to that, the interconnect code is generic and does not put any limitations on the platform/architecture that can use it - just the platform specific implementation would be different. We have discussed in that past that it can be used even on x86 platforms to provide hints to firmware. > So why shouldn't we just drop the interconnect code and use resctrl > instead as it's already merged? I haven't seen any MPAM code so far, but i assume that we can have an interconnect provider that implements this MPAM extension for systems that support it (and want to use it). Currently there are people working on various interconnect platform drivers from 5 different SoC vendors and we have agreed to use a common DT bindings (and API). I doubt that even a single one of these platforms is based on v8.2+. Probably such SoCs would be coming in the future and then i expect people making use of MPAM in some interconnect provider driver. Thanks, Georgi _______________________________________________ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
WARNING: multiple messages have this Message-ID (diff)
From: Georgi Djakov <georgi.djakov@linaro.org> To: Greg KH <gregkh@linuxfoundation.org> Cc: jcrouse@codeaurora.org, robdclark@gmail.com, evgreen@chromium.org, freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/msm/a6xx: Add support for an interconnect path Date: Tue, 12 Feb 2019 16:07:35 +0200 [thread overview] Message-ID: <99ab72bf-9e06-bcaf-85ec-33d4037a54cd@linaro.org> (raw) In-Reply-To: <20190212101624.GA20915@kroah.com> Hi Greg, On 2/12/19 12:16, Greg KH wrote: > On Tue, Feb 12, 2019 at 11:52:38AM +0200, Georgi Djakov wrote: >> From: Jordan Crouse <jcrouse@codeaurora.org> >> >> Try to get the interconnect path for the GPU and vote for the maximum >> bandwidth to support all frequencies. This is needed for performance. >> Later we will want to scale the bandwidth based on the frequency to >> also optimize for power but that will require some device tree >> infrastructure that does not yet exist. >> >> v6: use icc_set_bw() instead of icc_set() >> v5: Remove hardcoded interconnect name and just use the default >> v4: Don't use a port string at all to skip the need for names in the DT >> v3: Use macros and change port string per Georgi Djakov >> >> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> >> Acked-by: Rob Clark <robdclark@gmail.com> >> Reviewed-by: Evan Green <evgreen@chromium.org> >> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> >> --- >> >> Hi Greg, >> >> If not too late, could you please take this patch into char-misc-next. >> It is adding the first consumer of the interconnect API. We are just >> getting the code in place, without making it functional yet, as some >> DT bits are still needed to actually enable it. We have Rob's Ack to >> merge this together with the interconnect code. This patch has already >> spent some time in linux-next without any issues. > > I have a question about the interconnect code. Last week I saw a > presentation about the resctrl/RDT code from ARM that is coming (MPAM), > and it really looks like the same functionality as this interconnect > code. In fact, this code looks like the existing resctrl stuff, right? Thanks for the question! It's nice that MPAM is moving forward. When i looked into the MPAM draft spec an year ago, it was an optional extension mentioning mostly use-cases with VMs on server systems. But anyway, MPAM is only available for ARMv8.2+ cores as an optional extension and aarch32 is not supported. In contrast to that, the interconnect code is generic and does not put any limitations on the platform/architecture that can use it - just the platform specific implementation would be different. We have discussed in that past that it can be used even on x86 platforms to provide hints to firmware. > So why shouldn't we just drop the interconnect code and use resctrl > instead as it's already merged? I haven't seen any MPAM code so far, but i assume that we can have an interconnect provider that implements this MPAM extension for systems that support it (and want to use it). Currently there are people working on various interconnect platform drivers from 5 different SoC vendors and we have agreed to use a common DT bindings (and API). I doubt that even a single one of these platforms is based on v8.2+. Probably such SoCs would be coming in the future and then i expect people making use of MPAM in some interconnect provider driver. Thanks, Georgi
next prev parent reply other threads:[~2019-02-12 14:07 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-12 9:52 [PATCH] drm/msm/a6xx: Add support for an interconnect path Georgi Djakov 2019-02-12 10:16 ` Greg KH [not found] ` <20190212101624.GA20915-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 2019-02-12 14:07 ` Georgi Djakov [this message] 2019-02-12 14:07 ` Georgi Djakov 2019-02-12 14:35 ` Greg KH [not found] ` <20190212143525.GA15405-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 2019-02-13 12:51 ` Georgi Djakov 2019-02-13 12:51 ` Georgi Djakov -- strict thread matches above, loose matches on Subject: below -- 2018-12-07 17:06 Jordan Crouse 2018-12-07 17:06 ` Jordan Crouse 2018-12-07 17:06 ` Jordan Crouse [not found] ` <20181207170656.13208-1-jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2018-12-07 18:07 ` Jordan Crouse [not found] ` <20181207180712.GC20602-9PYrDHPZ2Orvke4nUoYGnHL1okKdlPRT@public.gmane.org> 2018-12-07 19:35 ` Rob Clark
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=99ab72bf-9e06-bcaf-85ec-33d4037a54cd@linaro.org \ --to=georgi.djakov-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \ --cc=evgreen-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \ --cc=freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \ --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \ --cc=jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \ --cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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.