mbox series

[v11,0/9] Add power domain driver for corners on msm8996/sdm845

Message ID 20190110040209.6028-1-rnayak@codeaurora.org (mailing list archive)
Headers show
Series Add power domain driver for corners on msm8996/sdm845 | expand

Message

Rajendra Nayak Jan. 10, 2019, 4:02 a.m. UTC
Changes in v11:
* Updated opp-level binding description based on feedback
from Viresh
* Other minor fixups in 'PATCH 2/9'

Changes in v10:
* Updated level bindings to include opp-level as an
optional property using operating-points-v2, no new
compatible for the OPP table
* Updated the dev_pm_opp_get_level() helper as per
suggestions from Viresh

Changes in v9:
* Updated qcom-opp bindings to be generic and usable across other SoCs 
with similar needs (Like MediaTek)
* Removed the simple_opp_to_performance_state() helper and added a
dev_pm_opp_of_get_level() helper instead
* Rebased on 5.0-rc1

Changes in v8:
* Patch 01/10: Bindings updated to mention opp-hz is optional
* Patch 02/10: Fixed #power-domain-cells
* All dependencies for 'Patch 10/10' are on their way to 4.21 via the pm tree

Changes in v7:
* Rebased on Andy's for-next, and used the updated cmd_db_read_aux_data()
* Other minor fixes, all in 'PATCH 06/10' as suggested by Stephen

Changes in v6:
* OPP binding updates for qcom,level reviewed by Rob
* DT bindings for rpmpd and rpmhpd updated to specify the
OPP tables as child nodes of the power-controller itself
* Removed some module specific remains from the drivers,
now that they can only be built-in
* Added a simple_opp_to_performance_state() helper

Changes in v5:
* First 6 patches are unchanged
* Patch 7/8 adds the DT node for rpmh power-controller on sdm845 and the
corresponding OPP tables for it to describe the performance states
* Patch 8/8 adds a parent/child relationship across mx/cx and mx_ao/cx_ao
as needed on sdm845 platform. This patch is dependent on the series from
Viresh [1] which adds support to propogate performance states across the
power domain hierarchy which is still being reviewed

Changes in v4:
* Included the patch to add qcom-opp bindings (dropped accidentally in v3)
* merged the patches to add bindings for rpm and rpmh, added consumer binding example
* Made the drivers built in, removed .remove
* Added better description in changelog for PATCH 6/6
* Updated rpmhpd_aggregate_corner() based on Davids feedback
* rpmhpd_set_performance_state() returns max corner, in cases where its called
with an INT_MAX
* Dropped the patch to max vote on all corners at init, the patch did not
work anyway, and it shouldn't be needed now

Changes in v3:
* Bindings split into seperate patches
* Bindings updated to remove duplicate OPP table phandles
* DT headers defining macros for Power domain indexes and OPP levels
* Optimisations to use rpmh_write_async() whereever applicable
* Fixed up handling of ACTIVE_ONLY/WAKE_ONLY/SLEEP voting for RPMh
* Fixed the vlvl to hlvl conversions in set_performance
* Other minor fixes based on review of v2
* TODO: This series does not handle the case where all VDD_MX votes
should be higher than VDD_CX from APPs, as pointed out
by David Collins in v2. This needs support at genpd to propogate performance
state up the parents, if we model these as Parent/Child to handle the
interdependency.

Changes in v2:
* added a power domain driver for sdm845 which supports communicating to RPMh
* dropped the changes to sdhc driver to move over to using OPP
as there is active discussion on using OPP as the interface vs
handling all of it in clock drivers
* Other minor binding updates based on review of v1

With performance state support for genpd/OPP merged, this is an effort
to model a power domain driver to communicate corner/level
values for qualcomm platforms to RPM (Remote Power Manager) and RPMh.

[1] https://lkml.org/lkml/2018/11/26/333

Rajendra Nayak (9):
  dt-bindings: opp: Introduce opp-level bindings
  OPP: Add support for parsing the 'opp-level' property
  dt-bindings: power: Add qcom rpm power domain driver bindings
  soc: qcom: rpmpd: Add a Power domain driver to model corners
  soc: qcom: rpmpd: Add support for get/set performance state
  arm64: dts: msm8996: Add rpmpd device node
  soc: qcom: rpmhpd: Add RPMh power domain driver
  arm64: dts: sdm845: Add rpmh powercontroller node
  soc: qcom: rpmhpd: Mark mx as a parent for cx

 Documentation/devicetree/bindings/opp/opp.txt |   3 +
 .../devicetree/bindings/power/qcom,rpmpd.txt  | 145 +++++++
 arch/arm64/boot/dts/qcom/msm8996.dtsi         |  34 ++
 arch/arm64/boot/dts/qcom/sdm845.dtsi          |  51 +++
 drivers/opp/core.c                            |  18 +
 drivers/opp/of.c                              |   2 +
 drivers/opp/opp.h                             |   2 +
 drivers/soc/qcom/Kconfig                      |  18 +
 drivers/soc/qcom/Makefile                     |   2 +
 drivers/soc/qcom/rpmhpd.c                     | 402 ++++++++++++++++++
 drivers/soc/qcom/rpmpd.c                      | 317 ++++++++++++++
 include/dt-bindings/power/qcom-rpmpd.h        |  39 ++
 include/linux/pm_opp.h                        |   7 +
 13 files changed, 1040 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt
 create mode 100644 drivers/soc/qcom/rpmhpd.c
 create mode 100644 drivers/soc/qcom/rpmpd.c
 create mode 100644 include/dt-bindings/power/qcom-rpmpd.h

Comments

Viresh Kumar Jan. 10, 2019, 6:33 a.m. UTC | #1
+Rafael

On 10-01-19, 09:32, Rajendra Nayak wrote:
> Changes in v11:
> * Updated opp-level binding description based on feedback
> from Viresh
> * Other minor fixups in 'PATCH 2/9'

>  Documentation/devicetree/bindings/opp/opp.txt |   3 +
>  .../devicetree/bindings/power/qcom,rpmpd.txt  | 145 +++++++
>  arch/arm64/boot/dts/qcom/msm8996.dtsi         |  34 ++
>  arch/arm64/boot/dts/qcom/sdm845.dtsi          |  51 +++
>  drivers/opp/core.c                            |  18 +
>  drivers/opp/of.c                              |   2 +
>  drivers/opp/opp.h                             |   2 +
>  drivers/soc/qcom/Kconfig                      |  18 +
>  drivers/soc/qcom/Makefile                     |   2 +
>  drivers/soc/qcom/rpmhpd.c                     | 402 ++++++++++++++++++
>  drivers/soc/qcom/rpmpd.c                      | 317 ++++++++++++++
>  include/dt-bindings/power/qcom-rpmpd.h        |  39 ++
>  include/linux/pm_opp.h                        |   7 +
>  13 files changed, 1040 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt
>  create mode 100644 drivers/soc/qcom/rpmhpd.c
>  create mode 100644 drivers/soc/qcom/rpmpd.c
>  create mode 100644 include/dt-bindings/power/qcom-rpmpd.h

Rafael/Ulf: Who should pick this series ? Should I take this via OPP
tree ?
Bjorn Andersson Jan. 16, 2019, 5:52 a.m. UTC | #2
On Wed 09 Jan 22:33 PST 2019, Viresh Kumar wrote:

> +Rafael
> 
> On 10-01-19, 09:32, Rajendra Nayak wrote:
> > Changes in v11:
> > * Updated opp-level binding description based on feedback
> > from Viresh
> > * Other minor fixups in 'PATCH 2/9'
> 
> >  Documentation/devicetree/bindings/opp/opp.txt |   3 +
> >  .../devicetree/bindings/power/qcom,rpmpd.txt  | 145 +++++++
> >  arch/arm64/boot/dts/qcom/msm8996.dtsi         |  34 ++
> >  arch/arm64/boot/dts/qcom/sdm845.dtsi          |  51 +++
> >  drivers/opp/core.c                            |  18 +
> >  drivers/opp/of.c                              |   2 +
> >  drivers/opp/opp.h                             |   2 +
> >  drivers/soc/qcom/Kconfig                      |  18 +
> >  drivers/soc/qcom/Makefile                     |   2 +
> >  drivers/soc/qcom/rpmhpd.c                     | 402 ++++++++++++++++++
> >  drivers/soc/qcom/rpmpd.c                      | 317 ++++++++++++++
> >  include/dt-bindings/power/qcom-rpmpd.h        |  39 ++
> >  include/linux/pm_opp.h                        |   7 +
> >  13 files changed, 1040 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt
> >  create mode 100644 drivers/soc/qcom/rpmhpd.c
> >  create mode 100644 drivers/soc/qcom/rpmpd.c
> >  create mode 100644 include/dt-bindings/power/qcom-rpmpd.h
> 
> Rafael/Ulf: Who should pick this series ? Should I take this via OPP
> tree ?
> 

Given that the weight of the patches lies in arm-soc area it could be
favourable to just take them that way, with the one opp-patch carrying
your (Rafael's?) ack.

If you prefer otherwise, I suggest that we take patch 6 and 8 (the two
dts patches) through arm-soc and you merge the rest in your tree.

Regards,
Bjorn
Ulf Hansson Jan. 16, 2019, 3:18 p.m. UTC | #3
On Wed, 16 Jan 2019 at 06:52, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Wed 09 Jan 22:33 PST 2019, Viresh Kumar wrote:
>
> > +Rafael
> >
> > On 10-01-19, 09:32, Rajendra Nayak wrote:
> > > Changes in v11:
> > > * Updated opp-level binding description based on feedback
> > > from Viresh
> > > * Other minor fixups in 'PATCH 2/9'
> >
> > >  Documentation/devicetree/bindings/opp/opp.txt |   3 +
> > >  .../devicetree/bindings/power/qcom,rpmpd.txt  | 145 +++++++
> > >  arch/arm64/boot/dts/qcom/msm8996.dtsi         |  34 ++
> > >  arch/arm64/boot/dts/qcom/sdm845.dtsi          |  51 +++
> > >  drivers/opp/core.c                            |  18 +
> > >  drivers/opp/of.c                              |   2 +
> > >  drivers/opp/opp.h                             |   2 +
> > >  drivers/soc/qcom/Kconfig                      |  18 +
> > >  drivers/soc/qcom/Makefile                     |   2 +
> > >  drivers/soc/qcom/rpmhpd.c                     | 402 ++++++++++++++++++
> > >  drivers/soc/qcom/rpmpd.c                      | 317 ++++++++++++++
> > >  include/dt-bindings/power/qcom-rpmpd.h        |  39 ++
> > >  include/linux/pm_opp.h                        |   7 +
> > >  13 files changed, 1040 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt
> > >  create mode 100644 drivers/soc/qcom/rpmhpd.c
> > >  create mode 100644 drivers/soc/qcom/rpmpd.c
> > >  create mode 100644 include/dt-bindings/power/qcom-rpmpd.h
> >
> > Rafael/Ulf: Who should pick this series ? Should I take this via OPP
> > tree ?
> >
>
> Given that the weight of the patches lies in arm-soc area it could be
> favourable to just take them that way, with the one opp-patch carrying
> your (Rafael's?) ack.
>
> If you prefer otherwise, I suggest that we take patch 6 and 8 (the two
> dts patches) through arm-soc and you merge the rest in your tree.

It sure sounds easiest to funnel this though the soc maintainer tree,
unless Viresh think there are lots of additional changes to the OPP
core going in this cycle, which thus may conflict.

However, it's not my call.

Kind regards
Uffe
Viresh Kumar Jan. 17, 2019, 4:24 a.m. UTC | #4
On 15-01-19, 21:52, Bjorn Andersson wrote:
> On Wed 09 Jan 22:33 PST 2019, Viresh Kumar wrote:
> 
> > +Rafael
> > 
> > On 10-01-19, 09:32, Rajendra Nayak wrote:
> > > Changes in v11:
> > > * Updated opp-level binding description based on feedback
> > > from Viresh
> > > * Other minor fixups in 'PATCH 2/9'
> > 
> > >  Documentation/devicetree/bindings/opp/opp.txt |   3 +
> > >  .../devicetree/bindings/power/qcom,rpmpd.txt  | 145 +++++++
> > >  arch/arm64/boot/dts/qcom/msm8996.dtsi         |  34 ++
> > >  arch/arm64/boot/dts/qcom/sdm845.dtsi          |  51 +++
> > >  drivers/opp/core.c                            |  18 +
> > >  drivers/opp/of.c                              |   2 +
> > >  drivers/opp/opp.h                             |   2 +
> > >  drivers/soc/qcom/Kconfig                      |  18 +
> > >  drivers/soc/qcom/Makefile                     |   2 +
> > >  drivers/soc/qcom/rpmhpd.c                     | 402 ++++++++++++++++++
> > >  drivers/soc/qcom/rpmpd.c                      | 317 ++++++++++++++
> > >  include/dt-bindings/power/qcom-rpmpd.h        |  39 ++
> > >  include/linux/pm_opp.h                        |   7 +
> > >  13 files changed, 1040 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt
> > >  create mode 100644 drivers/soc/qcom/rpmhpd.c
> > >  create mode 100644 drivers/soc/qcom/rpmpd.c
> > >  create mode 100644 include/dt-bindings/power/qcom-rpmpd.h
> > 
> > Rafael/Ulf: Who should pick this series ? Should I take this via OPP
> > tree ?
> > 
> 
> Given that the weight of the patches lies in arm-soc area it could be
> favourable to just take them that way, with the one opp-patch carrying
> your (Rafael's?) ack.
> 
> If you prefer otherwise, I suggest that we take patch 6 and 8 (the two
> dts patches) through arm-soc and you merge the rest in your tree.

Okay, take it via arm-soc. I will ask for a branch later on if I find
more patches going for the OPP core this cycle.
Marc Gonzalez Jan. 17, 2019, 3:03 p.m. UTC | #5
On 10/01/2019 05:02, Rajendra Nayak wrote:

> Rajendra Nayak (9):
>   dt-bindings: opp: Introduce opp-level bindings
>   OPP: Add support for parsing the 'opp-level' property
>   dt-bindings: power: Add qcom rpm power domain driver bindings
>   soc: qcom: rpmpd: Add a Power domain driver to model corners
>   soc: qcom: rpmpd: Add support for get/set performance state
>   arm64: dts: msm8996: Add rpmpd device node
>   soc: qcom: rpmhpd: Add RPMh power domain driver
>   arm64: dts: sdm845: Add rpmh powercontroller node
>   soc: qcom: rpmhpd: Mark mx as a parent for cx
> 
>  Documentation/devicetree/bindings/opp/opp.txt |   3 +
>  .../devicetree/bindings/power/qcom,rpmpd.txt  | 145 +++++++
>  arch/arm64/boot/dts/qcom/msm8996.dtsi         |  34 ++
>  arch/arm64/boot/dts/qcom/sdm845.dtsi          |  51 +++

Whenever I see these patches adding support for msm8996 (aka sdm820) and sdm845
simultaneously, I think to myself: "Why is sdm835 being left out? It was released
between sdm820 and sdm845, it cannot be /that/ different."

So I'm wondering: how much extra work would it be to add support for msm8998
aka sdm835?

Regards.
Rajendra Nayak Jan. 18, 2019, 3:54 a.m. UTC | #6
On 1/17/2019 8:33 PM, Marc Gonzalez wrote:
> On 10/01/2019 05:02, Rajendra Nayak wrote:
> 
>> Rajendra Nayak (9):
>>    dt-bindings: opp: Introduce opp-level bindings
>>    OPP: Add support for parsing the 'opp-level' property
>>    dt-bindings: power: Add qcom rpm power domain driver bindings
>>    soc: qcom: rpmpd: Add a Power domain driver to model corners
>>    soc: qcom: rpmpd: Add support for get/set performance state
>>    arm64: dts: msm8996: Add rpmpd device node
>>    soc: qcom: rpmhpd: Add RPMh power domain driver
>>    arm64: dts: sdm845: Add rpmh powercontroller node
>>    soc: qcom: rpmhpd: Mark mx as a parent for cx
>>
>>   Documentation/devicetree/bindings/opp/opp.txt |   3 +
>>   .../devicetree/bindings/power/qcom,rpmpd.txt  | 145 +++++++
>>   arch/arm64/boot/dts/qcom/msm8996.dtsi         |  34 ++
>>   arch/arm64/boot/dts/qcom/sdm845.dtsi          |  51 +++
> 
> Whenever I see these patches adding support for msm8996 (aka sdm820) and sdm845
> simultaneously, I think to myself: "Why is sdm835 being left out? It was released
> between sdm820 and sdm845, it cannot be /that/ different."

It isn't that different, and it should be quite straight forward to add support for it
with the rpmpd driver (the rpmhpd is for platforms sdm845 and beyond which use rpmh)

When I started working on these patches, support for sdm835 upstream was non-existent
so I started off with what was the better supported one which was the 820 (msm8996).
Marc Gonzalez Jan. 18, 2019, 10:17 a.m. UTC | #7
On 18/01/2019 04:54, Rajendra Nayak wrote:

> On 1/17/2019 8:33 PM, Marc Gonzalez wrote:
> 
>> On 10/01/2019 05:02, Rajendra Nayak wrote:
>>
>>> Rajendra Nayak (9):
>>>    dt-bindings: opp: Introduce opp-level bindings
>>>    OPP: Add support for parsing the 'opp-level' property
>>>    dt-bindings: power: Add qcom rpm power domain driver bindings
>>>    soc: qcom: rpmpd: Add a Power domain driver to model corners
>>>    soc: qcom: rpmpd: Add support for get/set performance state
>>>    arm64: dts: msm8996: Add rpmpd device node
>>>    soc: qcom: rpmhpd: Add RPMh power domain driver
>>>    arm64: dts: sdm845: Add rpmh powercontroller node
>>>    soc: qcom: rpmhpd: Mark mx as a parent for cx
>>>
>>>   Documentation/devicetree/bindings/opp/opp.txt |   3 +
>>>   .../devicetree/bindings/power/qcom,rpmpd.txt  | 145 +++++++
>>>   arch/arm64/boot/dts/qcom/msm8996.dtsi         |  34 ++
>>>   arch/arm64/boot/dts/qcom/sdm845.dtsi          |  51 +++
>>
>> Whenever I see these patches adding support for msm8996 (aka sdm820) and sdm845
>> simultaneously, I think to myself: "Why is sdm835 being left out? It was released
>> between sdm820 and sdm845, it cannot be /that/ different."
> 
> It isn't that different, and it should be quite straight forward to add support for it
> with the rpmpd driver (the rpmhpd is for platforms sdm845 and beyond which use rpmh)
> 
> When I started working on these patches, support for sdm835 upstream was non-existent
> so I started off with what was the better supported one which was the 820 (msm8996).

Once you land this patch series, could you take a quick look at how much work is needed
to add msm8998 support? I'm betting it would take you only a few hours.

Regards.
Rajendra Nayak Jan. 21, 2019, 9:20 a.m. UTC | #8
On 1/18/2019 3:47 PM, Marc Gonzalez wrote:
> On 18/01/2019 04:54, Rajendra Nayak wrote:
> 
>> On 1/17/2019 8:33 PM, Marc Gonzalez wrote:
>>
>>> On 10/01/2019 05:02, Rajendra Nayak wrote:
>>>
>>>> Rajendra Nayak (9):
>>>>     dt-bindings: opp: Introduce opp-level bindings
>>>>     OPP: Add support for parsing the 'opp-level' property
>>>>     dt-bindings: power: Add qcom rpm power domain driver bindings
>>>>     soc: qcom: rpmpd: Add a Power domain driver to model corners
>>>>     soc: qcom: rpmpd: Add support for get/set performance state
>>>>     arm64: dts: msm8996: Add rpmpd device node
>>>>     soc: qcom: rpmhpd: Add RPMh power domain driver
>>>>     arm64: dts: sdm845: Add rpmh powercontroller node
>>>>     soc: qcom: rpmhpd: Mark mx as a parent for cx
>>>>
>>>>    Documentation/devicetree/bindings/opp/opp.txt |   3 +
>>>>    .../devicetree/bindings/power/qcom,rpmpd.txt  | 145 +++++++
>>>>    arch/arm64/boot/dts/qcom/msm8996.dtsi         |  34 ++
>>>>    arch/arm64/boot/dts/qcom/sdm845.dtsi          |  51 +++
>>>
>>> Whenever I see these patches adding support for msm8996 (aka sdm820) and sdm845
>>> simultaneously, I think to myself: "Why is sdm835 being left out? It was released
>>> between sdm820 and sdm845, it cannot be /that/ different."
>>
>> It isn't that different, and it should be quite straight forward to add support for it
>> with the rpmpd driver (the rpmhpd is for platforms sdm845 and beyond which use rpmh)
>>
>> When I started working on these patches, support for sdm835 upstream was non-existent
>> so I started off with what was the better supported one which was the 820 (msm8996).
> 
> Once you land this patch series, could you take a quick look at how much work is needed
> to add msm8998 support? I'm betting it would take you only a few hours.

Sure, I can take a look. I think I do have a 8998 device which I can probably do
some testing on too.