From: Georgi Djakov <georgi.djakov@linaro.org> To: Henry Chen <henryc.chen@mediatek.com> Cc: Stephen Boyd <swboyd@chromium.org>, Matthias Brugger <matthias.bgg@gmail.com>, Rob Herring <robh+dt@kernel.org>, Ulf Hansson <ulf.hansson@linaro.org>, Viresh Kumar <vireshk@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Fan Chen <fan.chen@mediatek.com>, Weiyi Lu <weiyi.lu@mediatek.com>, James Liao <jamesjj.liao@mediatek.com>, Kees Cook <keescook@chromium.org>, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC RESEND PATCH 0/7] Add driver for dvfsrc and add support for active state of scpsys on mt8183 Date: Thu, 10 Jan 2019 11:39:03 +0200 [thread overview] Message-ID: <d03ec933-5fe6-d076-d658-9b966cee9c0f@linaro.org> (raw) In-Reply-To: <1547003324.6818.156.camel@mtksdaap41> Hi, On 1/9/19 05:08, Henry Chen wrote: > On Mon, 2019-01-07 at 18:34 +0200, Georgi Djakov wrote: >> Hi Henry, >> >> On 1/7/19 13:04, Henry Chen wrote: >>> On Thu, 2019-01-03 at 14:53 -0800, Stephen Boyd wrote: >>>> Quoting Henry Chen (2019-01-02 06:09:51) >>>>> The patchsets add support for MediaTek hardware module named DVFSRC >>>>> (dynamic voltage and frequency scaling resource collector). The DVFSRC is >>>>> a HW module which is used to collect all the requests from both software >>>>> and hardware and turn into the decision of minimum operating voltage and >>>>> minimum DRAM frequency to fulfill those requests. >>>>> >>>>> So, This series is to implement the dvfsrc driver to collect all the >>>>> requests of operating voltage or DRAM bandwidth from other device drivers >>>>> likes GPU/Camera through 2 frameworks basically: >>>>> >>>>> 1. PM_QOS_MEMORY_BANDWIDTH from PM QOS: to aggregate the bandwidth >>>>> requirements from different clients >>>> >>>> Have you looked at using the interconnect framework for this instead of >>>> using PM_QOS_MEMORY_BANDWIDTH? Qcom is pushing an interconnect framework >>>> to do DRAM bandwidth requirement aggregation. >>> >>> Sorry, I haven't heard that before. Do you mean is following series >>> patch? >>> https://patchwork.kernel.org/project/linux-arm-msm/list/?series=53775 >>> >> >> Yes, this one. The idea is that consumer drivers like GPU, camera, video >> encoder etc. report their bandwidth needs by using the interconnect API. >> The framework does the aggregation and configures the hardware. In order >> to use it you need to implement a platform-specific dvfsrc interconnect >> provider driver that understands the SoC topology and knows how to >> configure the hardware. I am not familiar with DVFSRC, but it seems to >> me that it can fit as interconnect provider. >> Does this HW module support any QoS priority/latency configuration or is >> it only bandwidth and voltage? >> >> Thanks, >> Georgi > > Hi Georgi, > > Yes, the design is only to support bandwidth and voltage. The one of the > function is to collect the memory bandwidth requirement from consumer > and select the minimum DRAM frequency to fulfill system performance.It > just get the total bandwidth then set it to HW, not involves complex SoC > topology. So we choose to use PM QOS to model that DVFSRC driver can > receive the bandwidth information from consumer driver via > PM_QOS_MEMORY_BANDWIDTH. Ok, good. The current patchset supports bandwidth, but there was a discussion about adding support for latency and priority in the future. Thanks for the information! > Do you have a patch that show how consumer driver used interconnect to > update their requirement. Here are some examples: https://lkml.org/lkml/2018/12/7/584 https://lkml.org/lkml/2018/10/11/499 https://lkml.org/lkml/2018/9/20/986 https://lkml.org/lkml/2018/11/22/772 Thanks, Georgi
WARNING: multiple messages have this Message-ID (diff)
From: Georgi Djakov <georgi.djakov@linaro.org> To: Henry Chen <henryc.chen@mediatek.com> Cc: Mark Rutland <mark.rutland@arm.com>, James Liao <jamesjj.liao@mediatek.com>, Ulf Hansson <ulf.hansson@linaro.org>, Kees Cook <keescook@chromium.org>, Weiyi Lu <weiyi.lu@mediatek.com>, linux-pm@vger.kernel.org, Viresh Kumar <vireshk@kernel.org>, linux-kernel@vger.kernel.org, Stephen Boyd <swboyd@chromium.org>, Fan Chen <fan.chen@mediatek.com>, devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>, linux-mediatek@lists.infradead.org, Matthias Brugger <matthias.bgg@gmail.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC RESEND PATCH 0/7] Add driver for dvfsrc and add support for active state of scpsys on mt8183 Date: Thu, 10 Jan 2019 11:39:03 +0200 [thread overview] Message-ID: <d03ec933-5fe6-d076-d658-9b966cee9c0f@linaro.org> (raw) In-Reply-To: <1547003324.6818.156.camel@mtksdaap41> Hi, On 1/9/19 05:08, Henry Chen wrote: > On Mon, 2019-01-07 at 18:34 +0200, Georgi Djakov wrote: >> Hi Henry, >> >> On 1/7/19 13:04, Henry Chen wrote: >>> On Thu, 2019-01-03 at 14:53 -0800, Stephen Boyd wrote: >>>> Quoting Henry Chen (2019-01-02 06:09:51) >>>>> The patchsets add support for MediaTek hardware module named DVFSRC >>>>> (dynamic voltage and frequency scaling resource collector). The DVFSRC is >>>>> a HW module which is used to collect all the requests from both software >>>>> and hardware and turn into the decision of minimum operating voltage and >>>>> minimum DRAM frequency to fulfill those requests. >>>>> >>>>> So, This series is to implement the dvfsrc driver to collect all the >>>>> requests of operating voltage or DRAM bandwidth from other device drivers >>>>> likes GPU/Camera through 2 frameworks basically: >>>>> >>>>> 1. PM_QOS_MEMORY_BANDWIDTH from PM QOS: to aggregate the bandwidth >>>>> requirements from different clients >>>> >>>> Have you looked at using the interconnect framework for this instead of >>>> using PM_QOS_MEMORY_BANDWIDTH? Qcom is pushing an interconnect framework >>>> to do DRAM bandwidth requirement aggregation. >>> >>> Sorry, I haven't heard that before. Do you mean is following series >>> patch? >>> https://patchwork.kernel.org/project/linux-arm-msm/list/?series=53775 >>> >> >> Yes, this one. The idea is that consumer drivers like GPU, camera, video >> encoder etc. report their bandwidth needs by using the interconnect API. >> The framework does the aggregation and configures the hardware. In order >> to use it you need to implement a platform-specific dvfsrc interconnect >> provider driver that understands the SoC topology and knows how to >> configure the hardware. I am not familiar with DVFSRC, but it seems to >> me that it can fit as interconnect provider. >> Does this HW module support any QoS priority/latency configuration or is >> it only bandwidth and voltage? >> >> Thanks, >> Georgi > > Hi Georgi, > > Yes, the design is only to support bandwidth and voltage. The one of the > function is to collect the memory bandwidth requirement from consumer > and select the minimum DRAM frequency to fulfill system performance.It > just get the total bandwidth then set it to HW, not involves complex SoC > topology. So we choose to use PM QOS to model that DVFSRC driver can > receive the bandwidth information from consumer driver via > PM_QOS_MEMORY_BANDWIDTH. Ok, good. The current patchset supports bandwidth, but there was a discussion about adding support for latency and priority in the future. Thanks for the information! > Do you have a patch that show how consumer driver used interconnect to > update their requirement. Here are some examples: https://lkml.org/lkml/2018/12/7/584 https://lkml.org/lkml/2018/10/11/499 https://lkml.org/lkml/2018/9/20/986 https://lkml.org/lkml/2018/11/22/772 Thanks, Georgi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-01-10 9:39 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-02 14:09 [RFC RESEND PATCH 0/7] Add driver for dvfsrc and add support for active state of scpsys on mt8183 Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-02 14:09 ` [RFC RESEND PATCH 1/7] dt-bindings: soc: Add DVFSRC driver bindings Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-11 16:09 ` Rob Herring 2019-01-11 16:09 ` Rob Herring 2019-02-18 4:55 ` Henry Chen 2019-02-18 4:55 ` Henry Chen 2019-02-18 4:55 ` Henry Chen 2019-03-20 8:52 ` Nicolas Boichat 2019-03-20 8:52 ` Nicolas Boichat 2019-03-20 8:52 ` Nicolas Boichat 2019-01-02 14:09 ` [RFC RESEND PATCH 2/7] dt-bindings: soc: Add opp table on scpsys bindings Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-03 18:45 ` Rob Herring 2019-01-03 18:45 ` Rob Herring 2019-01-03 18:45 ` Rob Herring 2019-01-07 11:04 ` Henry Chen 2019-01-07 11:04 ` Henry Chen 2019-01-07 11:04 ` Henry Chen 2019-01-02 14:09 ` [RFC RESEND PATCH 3/7] soc: mediatek: add support for the performance state Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-03 22:57 ` Stephen Boyd 2019-01-03 22:57 ` Stephen Boyd 2019-01-03 22:57 ` Stephen Boyd 2019-01-07 11:06 ` Henry Chen 2019-01-07 11:06 ` Henry Chen 2019-01-07 11:06 ` Henry Chen 2019-01-02 14:09 ` [RFC RESEND PATCH 4/7] arm64: dts: mt8183: add performance state support of scpsys Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-03 4:47 ` Viresh Kumar 2019-01-03 4:47 ` Viresh Kumar 2019-01-03 4:47 ` Viresh Kumar 2019-01-03 14:16 ` Henry Chen 2019-01-03 14:16 ` Henry Chen 2019-01-03 14:16 ` Henry Chen 2019-01-02 14:09 ` [RFC RESEND PATCH 5/7] soc: mediatek: add header for mediatek SIP interface Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-02 14:09 ` [RFC RESEND PATCH 6/7] soc: mediatek: add MT8183 dvfsrc support Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-03 23:08 ` Stephen Boyd 2019-01-03 23:08 ` Stephen Boyd 2019-01-03 23:08 ` Stephen Boyd 2019-01-07 11:09 ` Henry Chen 2019-01-07 11:09 ` Henry Chen 2019-01-07 11:09 ` Henry Chen 2019-01-10 0:38 ` Stephen Boyd 2019-01-10 0:38 ` Stephen Boyd 2019-01-02 14:09 ` [RFC RESEND PATCH 7/7] arm64: dts: mt8183: add dvfsrc related nodes Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-02 14:09 ` Henry Chen 2019-01-03 4:48 ` [RFC RESEND PATCH 0/7] Add driver for dvfsrc and add support for active state of scpsys on mt8183 Viresh Kumar 2019-01-03 4:48 ` Viresh Kumar 2019-01-03 4:48 ` Viresh Kumar 2019-01-03 14:31 ` Henry Chen 2019-01-03 14:31 ` Henry Chen 2019-01-03 14:31 ` Henry Chen 2019-01-03 22:53 ` Stephen Boyd 2019-01-03 22:53 ` Stephen Boyd 2019-01-07 11:04 ` Henry Chen 2019-01-07 11:04 ` Henry Chen 2019-01-07 11:04 ` Henry Chen 2019-01-07 16:34 ` Georgi Djakov 2019-01-07 16:34 ` Georgi Djakov 2019-01-09 3:08 ` Henry Chen 2019-01-09 3:08 ` Henry Chen 2019-01-09 3:08 ` Henry Chen 2019-01-10 9:39 ` Georgi Djakov [this message] 2019-01-10 9:39 ` Georgi Djakov
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=d03ec933-5fe6-d076-d658-9b966cee9c0f@linaro.org \ --to=georgi.djakov@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=fan.chen@mediatek.com \ --cc=henryc.chen@mediatek.com \ --cc=jamesjj.liao@mediatek.com \ --cc=keescook@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mediatek@lists.infradead.org \ --cc=linux-pm@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=matthias.bgg@gmail.com \ --cc=robh+dt@kernel.org \ --cc=swboyd@chromium.org \ --cc=ulf.hansson@linaro.org \ --cc=vireshk@kernel.org \ --cc=weiyi.lu@mediatek.com \ /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.