[RFC,RESEND,0/7] Add driver for dvfsrc and add support for active state of scpsys on mt8183
mbox series

Message ID 1546438198-1677-1-git-send-email-henryc.chen@mediatek.com
Headers show
Series
  • Add driver for dvfsrc and add support for active state of scpsys on mt8183
Related show

Message

Henry Chen Jan. 2, 2019, 2:09 p.m. UTC
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
2. Active state management of power domains[1]: to handle the operating
   voltage opp requirement from different power domains

[1] https://lwn.net/Articles/744047/

Henry Chen (7):
  dt-bindings: soc: Add DVFSRC driver bindings
  dt-bindings: soc: Add opp table on scpsys bindings
  soc: mediatek: add support for the performance state
  arm64: dts: mt8183: add performance state support of scpsys
  soc: mediatek: add header for mediatek SIP interface
  soc: mediatek: add MT8183 dvfsrc support
  arm64: dts: mt8183: add dvfsrc related nodes

 Documentation/devicetree/bindings/opp/mtk-opp.txt  |  24 ++
 .../devicetree/bindings/soc/mediatek/dvfsrc.txt    |  26 ++
 .../devicetree/bindings/soc/mediatek/scpsys.txt    |  42 ++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi           |  29 ++
 drivers/soc/mediatek/Kconfig                       |  15 +
 drivers/soc/mediatek/Makefile                      |   1 +
 drivers/soc/mediatek/mtk-dvfsrc.c                  | 473 +++++++++++++++++++++
 drivers/soc/mediatek/mtk-scpsys.c                  |  60 +++
 drivers/soc/mediatek/mtk-scpsys.h                  |  22 +
 include/dt-bindings/soc/mtk,dvfsrc.h               |  18 +
 include/soc/mediatek/mtk_sip.h                     |  17 +
 11 files changed, 727 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/opp/mtk-opp.txt
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/dvfsrc.txt
 create mode 100644 drivers/soc/mediatek/mtk-dvfsrc.c
 create mode 100644 drivers/soc/mediatek/mtk-scpsys.h
 create mode 100644 include/dt-bindings/soc/mtk,dvfsrc.h
 create mode 100644 include/soc/mediatek/mtk_sip.h

Comments

Viresh Kumar Jan. 3, 2019, 4:48 a.m. UTC | #1
On 02-01-19, 22:09, Henry Chen wrote:
> 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
> 2. Active state management of power domains[1]: to handle the operating
>    voltage opp requirement from different power domains

Honestly speaking I wasn't sure if anyone apart from Qcom will ever use this
feature when I wrote it first and I am quite surprised and happy to see your
patches.

They are mostly very neat and clean patches and I don't have complaints with
most of them. Lets see what comments others provide on them.

Thanks.
Henry Chen Jan. 3, 2019, 2:31 p.m. UTC | #2
On Thu, 2019-01-03 at 10:18 +0530, Viresh Kumar wrote:
> On 02-01-19, 22:09, Henry Chen wrote:
> > 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
> > 2. Active state management of power domains[1]: to handle the operating
> >    voltage opp requirement from different power domains
> 
> Honestly speaking I wasn't sure if anyone apart from Qcom will ever use this
> feature when I wrote it first and I am quite surprised and happy to see your
> patches.
> 
> They are mostly very neat and clean patches and I don't have complaints with
> most of them. Lets see what comments others provide on them.
> 
> Thanks.
> 

Thanks for your review and the comments.
Henry
Stephen Boyd Jan. 3, 2019, 10:53 p.m. UTC | #3
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.

> 2. Active state management of power domains[1]: to handle the operating
>    voltage opp requirement from different power domains

Do you have any devices that aren't "OPP-ish" in how they use
frequencies and voltages? What I mean is devices such as i2c, SPI, UART
controllers that don't use the OPP library to set a frequency but want
to affect some voltage of their power domain when clk frequencies
change. The existing code works well for devices that naturally use the
OPP rate changing API, typically multimedia devices that churn through
data like a CPU and don't care about the frequency of their main clk
because it doesn't match physical link bit rates, etc. I haven't seen
any good solution for devices that don't fit well with the OPP API
though so I'm curious if Mediatek needs to solve that problem.
Henry Chen Jan. 7, 2019, 11:04 a.m. UTC | #4
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


> > 2. Active state management of power domains[1]: to handle the operating
> >    voltage opp requirement from different power domains
> 
> Do you have any devices that aren't "OPP-ish" in how they use
> frequencies and voltages? What I mean is devices such as i2c, SPI, UART
> controllers that don't use the OPP library to set a frequency but want
> to affect some voltage of their power domain when clk frequencies
> change. The existing code works well for devices that naturally use the
> OPP rate changing API, typically multimedia devices that churn through
> data like a CPU and don't care about the frequency of their main clk
> because it doesn't match physical link bit rates, etc. I haven't seen
> any good solution for devices that don't fit well with the OPP API
> though so I'm curious if Mediatek needs to solve that problem. 

As I know, we don't have such device that need change clk and voltage
together without used OPP API.We suppose that user driver will call opp
library and performance state of power domain is combined into opp
table.

Thanks.
Henry
Georgi Djakov Jan. 7, 2019, 4:34 p.m. UTC | #5
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
Henry Chen Jan. 9, 2019, 3:08 a.m. UTC | #6
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.

Do you have a patch that show how consumer driver used interconnect to
update their requirement.

Thanks,
Henry
Georgi Djakov Jan. 10, 2019, 9:39 a.m. UTC | #7
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