Power Domains on Amlogic SoCs

Power Domains on Amlogic SoCs

[Martin Blumenstingl]

Hello,

I would like to start a discussion how to structure the power domain
drivers for the Amlogic SoCs.
My main motivation is getting video output and video decoders working
on the 32-bit SoCs.

The Amlogic SoCs we various registers for "power domains", the ones I
know (in no specific order):
1. HHI_MEM_PD_REG0 (contains: HDMI memory PD, Ethernet memory PD,
audio DSP memory PD - at least on the 32-bit SoCs)
2. HHI_VPU_MEM_PD_REG{0,1,2} (contains: various VPU related power domains)
3. AO_RTI_GEN_PWR_SLEEP0, AO_RTI_GEN_PWR_ISO0 (contains: HDMI PD, HDMI
isolation, video codec PDs, video code isolation, ...)
4. AO_RTI_PWR_A9_CNTL0/AO_RTI_PWR_SYS_CPU_PD0,
P_AO_RTI_PWR_A9_CNTL1/AO_RTI_PWR_SYS_CPU_PD1 (contains: CPU core
related power bits)

currently we have three drivers, which handle *some* of these power
domain registers:
drivers/soc/amlogic/meson-gx-pwrc-vpu.c:
- partially manages HHI_MEM_PD_REG0
- fully manages HHI_VPU_MEM_PD_REG{0,1,2}
- partially manages AO_RTI_GEN_PWR_SLEEP0

arch/arm/mach-meson/platsmp.c:
- manages AO_RTI_PWR_A9_CNTL0 and P_AO_RTI_PWR_A9_CNTL1
- only for the 32-bit SoCs, these registers (or their replacements)
are controlled by the firmware on the 64-bit SoCs

drivers/media/platform/meson/vdec/* (not upstream yet due to firmware
blob licensing questions, latest patchset: [1]):
- also partially manages AO_RTI_GEN_PWR_SLEEP0, AO_RTI_GEN_PWR_ISO0
(the former is also partially managed by meson-gx-pwrc-vpu)

To use the meson-gx-pwrc-vpu driver on the 32-bit SoCs I would have to
create an "AO regmap/syscon" and pass it to that driver. However, the
register layout of the "AO bus" on these older SoCs is different to
what we have on the 64-bit SoCs. So having a big "AO regmap/syscon" is
not easy (I also believe that it even if we could achieve it then it
wouldn't be a good representation of the hardware).
The video decoder driver currently requires the same "AO regmap/syscon".

I would like to focus on the AO_RTI_GEN_PWR_SLEEP0,
AO_RTI_GEN_PWR_ISO0 registers for now. This will make it easier to
support VPU and the video decoder drivers on the 32-bit SoCs.
My idea is to create a separate power domain provider which manages
these registers. Each power domain is exposed with it's own ID (just
like we have the CLKIDs in the clock driver) and can then be passed to
the various consumer drivers.
The genpd improvements in v4.19 and v4.20 make this possible as each
power domain can now be managed at runtime (not just at driver probe
time), see: [0]

With a separate power domain provider the meson-gx-pwrc-vpu and video
decoder drivers would not access the AO registers anymore. Instead we
would pass all relevant power domains from the "AO power domain
provider" to their respective consumers.

Examples (incomplete) from the VPU power domain / video decoder perspective:
&vpu_power_domain {
  power-domains = <&ao_pwrc AO_VPU_HDMI_PD>, <&ao_pwrc AO_VPU_HDMI_ISO_PD>;
  power-domain-names = "vpu_hdmi", "vpu_hdmi_iso";
};

&video_decoder {
  power-domains = <&ao_pwrc AO_PWR_VDEC_1_PD>, <&ao_pwrc
AO_ISO_VDEC_1_PD>, <&ao_pwrc AO_PWR_VDEC_HVEC_PD>, <&ao_pwrc
AO_ISO_VDEC_HVEC_PD>;
  power-domain-names = "vdec_1", "vdec_1_iso", "vdec_hvec", "vdec_hvec_iso";
};

My main concern is "backwards compatibility". We need to take care of
the VPU power domain driver and the video decoder driver. The latter
is not mainlined yet, so I'm not sure we need to be backwards
compatible here.

Please let me know if you have any concerns, ideas, suggestions, ...
I can build an "RFC" series for this topic if this makes the discussion easier.


Regards
Martin


[0] https://linuxplumbersconf.org/event/2/contributions/130/attachments/138/170/Genpd-Improvements.pdf
[1] https://patchwork.kernel.org/patch/10669873/

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: Power Domains on Amlogic SoCs

[Ulf Hansson]

On Fri, 1 Mar 2019 at 23:30, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> Hello,
>
> I would like to start a discussion how to structure the power domain
> drivers for the Amlogic SoCs.
> My main motivation is getting video output and video decoders working
> on the 32-bit SoCs.
>
> The Amlogic SoCs we various registers for "power domains", the ones I
> know (in no specific order):
> 1. HHI_MEM_PD_REG0 (contains: HDMI memory PD, Ethernet memory PD,
> audio DSP memory PD - at least on the 32-bit SoCs)
> 2. HHI_VPU_MEM_PD_REG{0,1,2} (contains: various VPU related power domains)
> 3. AO_RTI_GEN_PWR_SLEEP0, AO_RTI_GEN_PWR_ISO0 (contains: HDMI PD, HDMI
> isolation, video codec PDs, video code isolation, ...)
> 4. AO_RTI_PWR_A9_CNTL0/AO_RTI_PWR_SYS_CPU_PD0,
> P_AO_RTI_PWR_A9_CNTL1/AO_RTI_PWR_SYS_CPU_PD1 (contains: CPU core
> related power bits)

It would be nice to know a bit more about if/how the hierarchical PM
domain topology looks like. Do you have this information?

>
> currently we have three drivers, which handle *some* of these power
> domain registers:
> drivers/soc/amlogic/meson-gx-pwrc-vpu.c:
> - partially manages HHI_MEM_PD_REG0
> - fully manages HHI_VPU_MEM_PD_REG{0,1,2}
> - partially manages AO_RTI_GEN_PWR_SLEEP0
>
> arch/arm/mach-meson/platsmp.c:
> - manages AO_RTI_PWR_A9_CNTL0 and P_AO_RTI_PWR_A9_CNTL1
> - only for the 32-bit SoCs, these registers (or their replacements)
> are controlled by the firmware on the 64-bit SoCs

So, the AO_RTI_PWR_A9_CNTL* is used to power off/on the CPU, entirely.
If I understand correct, the AO_RTI_PWR_SYS_CPU_PD* is used to put a
CPU in a deeper idlestate, like CPU retention, right?

If I am correct, you need a cpuidle driver to deal with this, of course.

For 64-bit SoCs, the custom FW/code is replaced by the PSCI FW?

>
> drivers/media/platform/meson/vdec/* (not upstream yet due to firmware
> blob licensing questions, latest patchset: [1]):
> - also partially manages AO_RTI_GEN_PWR_SLEEP0, AO_RTI_GEN_PWR_ISO0
> (the former is also partially managed by meson-gx-pwrc-vpu)
>
> To use the meson-gx-pwrc-vpu driver on the 32-bit SoCs I would have to
> create an "AO regmap/syscon" and pass it to that driver. However, the
> register layout of the "AO bus" on these older SoCs is different to
> what we have on the 64-bit SoCs. So having a big "AO regmap/syscon" is
> not easy (I also believe that it even if we could achieve it then it
> wouldn't be a good representation of the hardware).
> The video decoder driver currently requires the same "AO regmap/syscon".
>
> I would like to focus on the AO_RTI_GEN_PWR_SLEEP0,
> AO_RTI_GEN_PWR_ISO0 registers for now. This will make it easier to
> support VPU and the video decoder drivers on the 32-bit SoCs.
> My idea is to create a separate power domain provider which manages
> these registers. Each power domain is exposed with it's own ID (just
> like we have the CLKIDs in the clock driver) and can then be passed to
> the various consumer drivers.
> The genpd improvements in v4.19 and v4.20 make this possible as each
> power domain can now be managed at runtime (not just at driver probe
> time), see: [0]
>
> With a separate power domain provider the meson-gx-pwrc-vpu and video
> decoder drivers would not access the AO registers anymore. Instead we
> would pass all relevant power domains from the "AO power domain
> provider" to their respective consumers.

Overall, this seems like a reasonable way forward.

I guess the important point is that we model the topology of the HW
correctly in DT (no short cuts), as otherwise we may encounter issues
in the end I think.

>
> Examples (incomplete) from the VPU power domain / video decoder perspective:
> &vpu_power_domain {
>   power-domains = <&ao_pwrc AO_VPU_HDMI_PD>, <&ao_pwrc AO_VPU_HDMI_ISO_PD>;
>   power-domain-names = "vpu_hdmi", "vpu_hdmi_iso";
> };
>
> &video_decoder {
>   power-domains = <&ao_pwrc AO_PWR_VDEC_1_PD>, <&ao_pwrc
> AO_ISO_VDEC_1_PD>, <&ao_pwrc AO_PWR_VDEC_HVEC_PD>, <&ao_pwrc
> AO_ISO_VDEC_HVEC_PD>;
>   power-domain-names = "vdec_1", "vdec_1_iso", "vdec_hvec", "vdec_hvec_iso";
> };
>
> My main concern is "backwards compatibility". We need to take care of
> the VPU power domain driver and the video decoder driver. The latter
> is not mainlined yet, so I'm not sure we need to be backwards
> compatible here.

Yeah, that could be a bit troublesome, at least short term.

I think I have mentioned it before, in some thread - perhaps we should
add an OF helper function, which tells the caller the number of
power-domains that is described in the device node. That could help to
make the code more flexible in drivers/buses that deal with the PM
domain attach/detach, thus also potentially simplify to support
backwards compatibility, if/when that makes sense.

>
> Please let me know if you have any concerns, ideas, suggestions, ...
> I can build an "RFC" series for this topic if this makes the discussion easier.

It's always easier to look at code, unless there is a whiteboard available. :-)

If you keep me cced, I do my best to review it!

>
>
> Regards
> Martin
>
>
> [0] https://linuxplumbersconf.org/event/2/contributions/130/attachments/138/170/Genpd-Improvements.pdf
> [1] https://patchwork.kernel.org/patch/10669873/

Kind regards
Uffe

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: Power Domains on Amlogic SoCs

[Martin Blumenstingl]

Hi Ulf,

On Mon, Mar 4, 2019 at 4:41 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Fri, 1 Mar 2019 at 23:30, Martin Blumenstingl
> <martin.blumenstingl@googlemail.com> wrote:
> >
> > Hello,
> >
> > I would like to start a discussion how to structure the power domain
> > drivers for the Amlogic SoCs.
> > My main motivation is getting video output and video decoders working
> > on the 32-bit SoCs.
> >
> > The Amlogic SoCs we various registers for "power domains", the ones I
> > know (in no specific order):
> > 1. HHI_MEM_PD_REG0 (contains: HDMI memory PD, Ethernet memory PD,
> > audio DSP memory PD - at least on the 32-bit SoCs)
> > 2. HHI_VPU_MEM_PD_REG{0,1,2} (contains: various VPU related power domains)
> > 3. AO_RTI_GEN_PWR_SLEEP0, AO_RTI_GEN_PWR_ISO0 (contains: HDMI PD, HDMI
> > isolation, video codec PDs, video code isolation, ...)
> > 4. AO_RTI_PWR_A9_CNTL0/AO_RTI_PWR_SYS_CPU_PD0,
> > P_AO_RTI_PWR_A9_CNTL1/AO_RTI_PWR_SYS_CPU_PD1 (contains: CPU core
> > related power bits)
>
> It would be nice to know a bit more about if/how the hierarchical PM
> domain topology looks like. Do you have this information?
unfortunately I don't have this information
Jianxin, maybe you can give us some details here (see also below)?

> >
> > currently we have three drivers, which handle *some* of these power
> > domain registers:
> > drivers/soc/amlogic/meson-gx-pwrc-vpu.c:
> > - partially manages HHI_MEM_PD_REG0
> > - fully manages HHI_VPU_MEM_PD_REG{0,1,2}
> > - partially manages AO_RTI_GEN_PWR_SLEEP0
> >
> > arch/arm/mach-meson/platsmp.c:
> > - manages AO_RTI_PWR_A9_CNTL0 and P_AO_RTI_PWR_A9_CNTL1
> > - only for the 32-bit SoCs, these registers (or their replacements)
> > are controlled by the firmware on the 64-bit SoCs
>
> So, the AO_RTI_PWR_A9_CNTL* is used to power off/on the CPU, entirely.
> If I understand correct, the AO_RTI_PWR_SYS_CPU_PD* is used to put a
> CPU in a deeper idlestate, like CPU retention, right?
yes, we use AO_RTI_PWR_A9_CNTL* (in arch/arm/mach-meson/platsmp.c) to
turn on/off the CPU cores for SMP boot and CPU hotplug on the 32-bit
SoCs

> If I am correct, you need a cpuidle driver to deal with this, of course.
so far only SMP boot and CPU hotplug are implemented for the 32-bit SoCs.
I don't know about AO_RTI_PWR_SYS_CPU_PD* because these registers
don't exist on the 32-bit SoCs (as far as I know)

> For 64-bit SoCs, the custom FW/code is replaced by the PSCI FW?
indeed, on the 64-bit SoCs this is managed by the PSCI firmware

> >
> > drivers/media/platform/meson/vdec/* (not upstream yet due to firmware
> > blob licensing questions, latest patchset: [1]):
> > - also partially manages AO_RTI_GEN_PWR_SLEEP0, AO_RTI_GEN_PWR_ISO0
> > (the former is also partially managed by meson-gx-pwrc-vpu)
> >
> > To use the meson-gx-pwrc-vpu driver on the 32-bit SoCs I would have to
> > create an "AO regmap/syscon" and pass it to that driver. However, the
> > register layout of the "AO bus" on these older SoCs is different to
> > what we have on the 64-bit SoCs. So having a big "AO regmap/syscon" is
> > not easy (I also believe that it even if we could achieve it then it
> > wouldn't be a good representation of the hardware).
> > The video decoder driver currently requires the same "AO regmap/syscon".
> >
> > I would like to focus on the AO_RTI_GEN_PWR_SLEEP0,
> > AO_RTI_GEN_PWR_ISO0 registers for now. This will make it easier to
> > support VPU and the video decoder drivers on the 32-bit SoCs.
> > My idea is to create a separate power domain provider which manages
> > these registers. Each power domain is exposed with it's own ID (just
> > like we have the CLKIDs in the clock driver) and can then be passed to
> > the various consumer drivers.
> > The genpd improvements in v4.19 and v4.20 make this possible as each
> > power domain can now be managed at runtime (not just at driver probe
> > time), see: [0]
> >
> > With a separate power domain provider the meson-gx-pwrc-vpu and video
> > decoder drivers would not access the AO registers anymore. Instead we
> > would pass all relevant power domains from the "AO power domain
> > provider" to their respective consumers.
>
> Overall, this seems like a reasonable way forward.
>
> I guess the important point is that we model the topology of the HW
> correctly in DT (no short cuts), as otherwise we may encounter issues
> in the end I think.
to get the DT part right I am thinking about the following questions:
- which IP blocks do we have? (I mentioned four in my original mail
where I *believe* that they are separate IP blocks, but I'm not sure)
- what are the inputs/outputs of each IP block? (example: IP block X
uses clock Y)
- what are the differences between the SoCs (not only the "new" 64-bit
ones, but also the 32-bit ones)?
- do we have dependencies between power domains? (like in: do we need
to enable power domain before removing "isolation")
- what about the "isolation" bits - how do these work with the actual
"power domain" bits?
- are the power domains just "on" or "off", or is there something in
between (like low/medium/high power or performance)?

Ulf, since I'm new to this whole power-domain area: do my questions
make sense? what am I missing?

Jianxin, can you please answer Ulf's and my questions on this topic?

> >
> > Examples (incomplete) from the VPU power domain / video decoder perspective:
> > &vpu_power_domain {
> >   power-domains = <&ao_pwrc AO_VPU_HDMI_PD>, <&ao_pwrc AO_VPU_HDMI_ISO_PD>;
> >   power-domain-names = "vpu_hdmi", "vpu_hdmi_iso";
> > };
> >
> > &video_decoder {
> >   power-domains = <&ao_pwrc AO_PWR_VDEC_1_PD>, <&ao_pwrc
> > AO_ISO_VDEC_1_PD>, <&ao_pwrc AO_PWR_VDEC_HVEC_PD>, <&ao_pwrc
> > AO_ISO_VDEC_HVEC_PD>;
> >   power-domain-names = "vdec_1", "vdec_1_iso", "vdec_hvec", "vdec_hvec_iso";
> > };
> >
> > My main concern is "backwards compatibility". We need to take care of
> > the VPU power domain driver and the video decoder driver. The latter
> > is not mainlined yet, so I'm not sure we need to be backwards
> > compatible here.
>
> Yeah, that could be a bit troublesome, at least short term.
indeed. the video decoder drivers are not part of mainline yet.
This means we "only" have to consider two "power domain consumers"
which already exist:
- VPU power domain / VPU driver (display support)
- SMP / CPU hotplug support on the 32-bit SoCs (this currently doesn't
use the power-domain framework but a syscon in the platsmp.c driver)

> I think I have mentioned it before, in some thread - perhaps we should
> add an OF helper function, which tells the caller the number of
> power-domains that is described in the device node. That could help to
> make the code more flexible in drivers/buses that deal with the PM
> domain attach/detach, thus also potentially simplify to support
> backwards compatibility, if/when that makes sense.
>
> >
> > Please let me know if you have any concerns, ideas, suggestions, ...
> > I can build an "RFC" series for this topic if this makes the discussion easier.
>
> It's always easier to look at code, unless there is a whiteboard available. :-)
OK, I'll wait for additional questions you may have so Jianxin can
provide the details we need to know about the actual hardware
implementation.
After that I can start an RFC series (Jianxin's input will help us to
focus on the Linux drivers rather than having to discuss - or even
guess - the hardware details over and over again)

> If you keep me cced, I do my best to review it!
I will do that.
thank you for taking the time to go through my mail and give feedback!


Regards
Martin

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: Power Domains on Amlogic SoCs

[Kevin Hilman]

> On Mon, Mar 4, 2019 at 4:41 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>
>> On Fri, 1 Mar 2019 at 23:30, Martin Blumenstingl
>> <martin.blumenstingl@googlemail.com> wrote:
>> >
>> > Hello,
>> >
>> > I would like to start a discussion how to structure the power domain
>> > drivers for the Amlogic SoCs.
>> > My main motivation is getting video output and video decoders working
>> > on the 32-bit SoCs.
>> >
>> > The Amlogic SoCs we various registers for "power domains", the ones I
>> > know (in no specific order):
>> > 1. HHI_MEM_PD_REG0 (contains: HDMI memory PD, Ethernet memory PD,
>> > audio DSP memory PD - at least on the 32-bit SoCs)
>> > 2. HHI_VPU_MEM_PD_REG{0,1,2} (contains: various VPU related power domains)
>> > 3. AO_RTI_GEN_PWR_SLEEP0, AO_RTI_GEN_PWR_ISO0 (contains: HDMI PD, HDMI
>> > isolation, video codec PDs, video code isolation, ...)
>> > 4. AO_RTI_PWR_A9_CNTL0/AO_RTI_PWR_SYS_CPU_PD0,
>> > P_AO_RTI_PWR_A9_CNTL1/AO_RTI_PWR_SYS_CPU_PD1 (contains: CPU core
>> > related power bits)
>>
>> It would be nice to know a bit more about if/how the hierarchical PM
>> domain topology looks like. Do you have this information?
> unfortunately I don't have this information
> Jianxin, maybe you can give us some details here (see also below)?

I have some reasonble documentation that sheds some light here, at least
at the logical level, but with that I can guess at some of the physical
layout, and then hopefully get clarification/confirmation from Jianxin
as needed.

First off, AFAICT, there are 3 primary rails from the PMIC

- AO (always-on) domain
- EE (everything else) domain
- CPU domain (called A53 on the 64-bit SoCs)

At first glance, these would be the 3 top-level domains.  However, the
docs imply an explicit ordering in the AO powers on first, then EE, then
CPU domain. (Note: this obviously implies that from code running on the
CPU, we can never fully power off the EE domain itself, only sub-domains
of EE (e.g. GPU, VPU, VDEC, MMC, etc.)

So, while there are 3 distinct rails from the PMIC, the domains are
highly dependenent and we should probably model them as hierarchical.

That being said, the kernel is not going to be (directly) controlling
the CPU domain, because PSCI will be doing that (at least until I get
some time to work on OS-initiated mode for PSCI and experiment with CPU
PM domains.)  But it's probably worth modeling that in DT anyways, just
for the sake of documentation.

>> >
>> > currently we have three drivers, which handle *some* of these power
>> > domain registers:
>> > drivers/soc/amlogic/meson-gx-pwrc-vpu.c:
>> > - partially manages HHI_MEM_PD_REG0
>> > - fully manages HHI_VPU_MEM_PD_REG{0,1,2}
>> > - partially manages AO_RTI_GEN_PWR_SLEEP0
>> >
>> > arch/arm/mach-meson/platsmp.c:
>> > - manages AO_RTI_PWR_A9_CNTL0 and P_AO_RTI_PWR_A9_CNTL1
>> > - only for the 32-bit SoCs, these registers (or their replacements)
>> > are controlled by the firmware on the 64-bit SoCs
>>
>> So, the AO_RTI_PWR_A9_CNTL* is used to power off/on the CPU, entirely.
>> If I understand correct, the AO_RTI_PWR_SYS_CPU_PD* is used to put a
>> CPU in a deeper idlestate, like CPU retention, right?
> yes, we use AO_RTI_PWR_A9_CNTL* (in arch/arm/mach-meson/platsmp.c) to
> turn on/off the CPU cores for SMP boot and CPU hotplug on the 32-bit
> SoCs
>
>> If I am correct, you need a cpuidle driver to deal with this, of course.
> so far only SMP boot and CPU hotplug are implemented for the 32-bit SoCs.
> I don't know about AO_RTI_PWR_SYS_CPU_PD* because these registers
> don't exist on the 32-bit SoCs (as far as I know)
>
>> For 64-bit SoCs, the custom FW/code is replaced by the PSCI FW?
> indeed, on the 64-bit SoCs this is managed by the PSCI firmware
>
>> >
>> > drivers/media/platform/meson/vdec/* (not upstream yet due to firmware
>> > blob licensing questions, latest patchset: [1]):
>> > - also partially manages AO_RTI_GEN_PWR_SLEEP0, AO_RTI_GEN_PWR_ISO0
>> > (the former is also partially managed by meson-gx-pwrc-vpu)
>> >
>> > To use the meson-gx-pwrc-vpu driver on the 32-bit SoCs I would have to
>> > create an "AO regmap/syscon" and pass it to that driver. However, the
>> > register layout of the "AO bus" on these older SoCs is different to
>> > what we have on the 64-bit SoCs. So having a big "AO regmap/syscon" is
>> > not easy (I also believe that it even if we could achieve it then it
>> > wouldn't be a good representation of the hardware).
>> > The video decoder driver currently requires the same "AO regmap/syscon".
>> >
>> > I would like to focus on the AO_RTI_GEN_PWR_SLEEP0,
>> > AO_RTI_GEN_PWR_ISO0 registers for now. This will make it easier to
>> > support VPU and the video decoder drivers on the 32-bit SoCs.
>> > My idea is to create a separate power domain provider which manages
>> > these registers. Each power domain is exposed with it's own ID (just
>> > like we have the CLKIDs in the clock driver) and can then be passed to
>> > the various consumer drivers.
>> > The genpd improvements in v4.19 and v4.20 make this possible as each
>> > power domain can now be managed at runtime (not just at driver probe
>> > time), see: [0]
>> >
>> > With a separate power domain provider the meson-gx-pwrc-vpu and video
>> > decoder drivers would not access the AO registers anymore. Instead we
>> > would pass all relevant power domains from the "AO power domain
>> > provider" to their respective consumers.
>>
>> Overall, this seems like a reasonable way forward.
>>
>> I guess the important point is that we model the topology of the HW
>> correctly in DT (no short cuts), as otherwise we may encounter issues
>> in the end I think.
> to get the DT part right I am thinking about the following questions:
> - which IP blocks do we have? (I mentioned four in my original mail
> where I *believe* that they are separate IP blocks, but I'm not sure)

Besides the CPUs which we should handle separately, there's only 1 IP
blocks that are managed upstream today (VPU/HDMI), so that's all you
need to worry about for compatability, IMO.

> - what are the inputs/outputs of each IP block? (example: IP block X
> uses clock Y)
> - what are the differences between the SoCs (not only the "new" 64-bit
> ones, but also the 32-bit ones)?

AFAICT, the 64-bit ones are quite similar to each other.  I haven't
looked closely at the 32-bit ones at all.

> - do we have dependencies between power domains?

We definitely do between the top-level domains (see above.)

> (like in: do we need
> to enable power domain before removing "isolation")
> - what about the "isolation" bits - how do these work with the actual
> "power domain" bits?

The "isolation" is not a separate domain and should not be modeled as
such like in your DT examples below.  It's just a step in the process.
IOW, you isolate the domain, and then power it off.  Coming back, you
power it on and then un-isolate it.

> - are the power domains just "on" or "off", or is there something in
> between (like low/medium/high power or performance)?

In general, they are on/off.

However, CPUs are a bit special here as they can have various low-power
modes, which is why (until very recently) they have been managed by the
CPUidle framework, and not the power domain framework.  So for now, I
recommend we get the domains in place for all the peripherals, and then
consider the CPU management.

> Ulf, since I'm new to this whole power-domain area: do my questions
> make sense? what am I missing?
>
> Jianxin, can you please answer Ulf's and my questions on this topic?
>
>> >
>> > Examples (incomplete) from the VPU power domain / video decoder perspective:
>> > &vpu_power_domain {
>> >   power-domains = <&ao_pwrc AO_VPU_HDMI_PD>, <&ao_pwrc AO_VPU_HDMI_ISO_PD>;
>> >   power-domain-names = "vpu_hdmi", "vpu_hdmi_iso";
>> > };

As I mentioned above, don't model the "iso" as it's own domain.  The
driver should handle the isolation bit and power bit ordering itself.

>> > &video_decoder {
>> >   power-domains = <&ao_pwrc AO_PWR_VDEC_1_PD>, <&ao_pwrc
>> > AO_ISO_VDEC_1_PD>, <&ao_pwrc AO_PWR_VDEC_HVEC_PD>, <&ao_pwrc
>> > AO_ISO_VDEC_HVEC_PD>;
>> >   power-domain-names = "vdec_1", "vdec_1_iso", "vdec_hvec", "vdec_hvec_iso";
>> > };
>> >
>> > My main concern is "backwards compatibility". We need to take care of
>> > the VPU power domain driver and the video decoder driver. The latter
>> > is not mainlined yet, so I'm not sure we need to be backwards
>> > compatible here.
>>
>> Yeah, that could be a bit troublesome, at least short term.
> indeed. the video decoder drivers are not part of mainline yet.
> This means we "only" have to consider two "power domain consumers"
> which already exist:
> - VPU power domain / VPU driver (display support)

I don't think you have to worry about backward compatability at all.
Let's just create a new power-domain driver that manages everything (in
EE) with a new compatable, and switch to it, leaving the old one for
some time before eventually removing it.

> - SMP / CPU hotplug support on the 32-bit SoCs (this currently doesn't
> use the power-domain framework but a syscon in the platsmp.c driver)

And I don't thing you should switch this to power-domain either, so I
don't think this causes any concern for the new power domain driver.

>> I think I have mentioned it before, in some thread - perhaps we should
>> add an OF helper function, which tells the caller the number of
>> power-domains that is described in the device node. That could help to
>> make the code more flexible in drivers/buses that deal with the PM
>> domain attach/detach, thus also potentially simplify to support
>> backwards compatibility, if/when that makes sense.
>>
>> >
>> > Please let me know if you have any concerns, ideas, suggestions, ...
>> > I can build an "RFC" series for this topic if this makes the discussion easier.
>>
>> It's always easier to look at code, unless there is a whiteboard available. :-)
> OK, I'll wait for additional questions you may have so Jianxin can
> provide the details we need to know about the actual hardware
> implementation.
> After that I can start an RFC series (Jianxin's input will help us to
> focus on the Linux drivers rather than having to discuss - or even
> guess - the hardware details over and over again)

I can definitely help with this too.  If you can do an RFC with the "big
picture", and proposal for the 32-bit SoCs, I can fill in all the
missing pieces for the various 64-bit SoCs.

Kevin

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: Power Domains on Amlogic SoCs

[Martin Blumenstingl]

Hi Kevin,

thank you for your detailed email!

On Thu, Mar 7, 2019 at 9:13 PM Kevin Hilman <khilman@baylibre.com> wrote:
>
>
> > On Mon, Mar 4, 2019 at 4:41 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >>
> >> On Fri, 1 Mar 2019 at 23:30, Martin Blumenstingl
> >> <martin.blumenstingl@googlemail.com> wrote:
> >> >
> >> > Hello,
> >> >
> >> > I would like to start a discussion how to structure the power domain
> >> > drivers for the Amlogic SoCs.
> >> > My main motivation is getting video output and video decoders working
> >> > on the 32-bit SoCs.
> >> >
> >> > The Amlogic SoCs we various registers for "power domains", the ones I
> >> > know (in no specific order):
> >> > 1. HHI_MEM_PD_REG0 (contains: HDMI memory PD, Ethernet memory PD,
> >> > audio DSP memory PD - at least on the 32-bit SoCs)
> >> > 2. HHI_VPU_MEM_PD_REG{0,1,2} (contains: various VPU related power domains)
> >> > 3. AO_RTI_GEN_PWR_SLEEP0, AO_RTI_GEN_PWR_ISO0 (contains: HDMI PD, HDMI
> >> > isolation, video codec PDs, video code isolation, ...)
> >> > 4. AO_RTI_PWR_A9_CNTL0/AO_RTI_PWR_SYS_CPU_PD0,
> >> > P_AO_RTI_PWR_A9_CNTL1/AO_RTI_PWR_SYS_CPU_PD1 (contains: CPU core
> >> > related power bits)
> >>
> >> It would be nice to know a bit more about if/how the hierarchical PM
> >> domain topology looks like. Do you have this information?
> > unfortunately I don't have this information
> > Jianxin, maybe you can give us some details here (see also below)?
>
> I have some reasonble documentation that sheds some light here, at least
> at the logical level, but with that I can guess at some of the physical
> layout, and then hopefully get clarification/confirmation from Jianxin
> as needed.
>
> First off, AFAICT, there are 3 primary rails from the PMIC
>
> - AO (always-on) domain
> - EE (everything else) domain
> - CPU domain (called A53 on the 64-bit SoCs)
>
> At first glance, these would be the 3 top-level domains.  However, the
> docs imply an explicit ordering in the AO powers on first, then EE, then
> CPU domain. (Note: this obviously implies that from code running on the
> CPU, we can never fully power off the EE domain itself, only sub-domains
> of EE (e.g. GPU, VPU, VDEC, MMC, etc.)
>
> So, while there are 3 distinct rails from the PMIC, the domains are
> highly dependenent and we should probably model them as hierarchical.
OK, taking VPU as an example (to confirm that I understand this correctly):
VPU needs some power domain bits from the AO domain
thus the VPU power-controller should have the following properties (in
the .dtsi):
  power-domains = <&ao_power_domain PD_RELATED_TO_VPU>, ...;
then the VPU driver only has (assuming that the VPU power controller
has #power-domain-cells = <0>):
    power-domains = <&vpu_power_domain>;

> That being said, the kernel is not going to be (directly) controlling
> the CPU domain, because PSCI will be doing that (at least until I get
> some time to work on OS-initiated mode for PSCI and experiment with CPU
> PM domains.)  But it's probably worth modeling that in DT anyways, just
> for the sake of documentation.
OK

> >> >
> >> > currently we have three drivers, which handle *some* of these power
> >> > domain registers:
> >> > drivers/soc/amlogic/meson-gx-pwrc-vpu.c:
> >> > - partially manages HHI_MEM_PD_REG0
> >> > - fully manages HHI_VPU_MEM_PD_REG{0,1,2}
> >> > - partially manages AO_RTI_GEN_PWR_SLEEP0
> >> >
> >> > arch/arm/mach-meson/platsmp.c:
> >> > - manages AO_RTI_PWR_A9_CNTL0 and P_AO_RTI_PWR_A9_CNTL1
> >> > - only for the 32-bit SoCs, these registers (or their replacements)
> >> > are controlled by the firmware on the 64-bit SoCs
> >>
> >> So, the AO_RTI_PWR_A9_CNTL* is used to power off/on the CPU, entirely.
> >> If I understand correct, the AO_RTI_PWR_SYS_CPU_PD* is used to put a
> >> CPU in a deeper idlestate, like CPU retention, right?
> > yes, we use AO_RTI_PWR_A9_CNTL* (in arch/arm/mach-meson/platsmp.c) to
> > turn on/off the CPU cores for SMP boot and CPU hotplug on the 32-bit
> > SoCs
> >
> >> If I am correct, you need a cpuidle driver to deal with this, of course.
> > so far only SMP boot and CPU hotplug are implemented for the 32-bit SoCs.
> > I don't know about AO_RTI_PWR_SYS_CPU_PD* because these registers
> > don't exist on the 32-bit SoCs (as far as I know)
> >
> >> For 64-bit SoCs, the custom FW/code is replaced by the PSCI FW?
> > indeed, on the 64-bit SoCs this is managed by the PSCI firmware
> >
> >> >
> >> > drivers/media/platform/meson/vdec/* (not upstream yet due to firmware
> >> > blob licensing questions, latest patchset: [1]):
> >> > - also partially manages AO_RTI_GEN_PWR_SLEEP0, AO_RTI_GEN_PWR_ISO0
> >> > (the former is also partially managed by meson-gx-pwrc-vpu)
> >> >
> >> > To use the meson-gx-pwrc-vpu driver on the 32-bit SoCs I would have to
> >> > create an "AO regmap/syscon" and pass it to that driver. However, the
> >> > register layout of the "AO bus" on these older SoCs is different to
> >> > what we have on the 64-bit SoCs. So having a big "AO regmap/syscon" is
> >> > not easy (I also believe that it even if we could achieve it then it
> >> > wouldn't be a good representation of the hardware).
> >> > The video decoder driver currently requires the same "AO regmap/syscon".
> >> >
> >> > I would like to focus on the AO_RTI_GEN_PWR_SLEEP0,
> >> > AO_RTI_GEN_PWR_ISO0 registers for now. This will make it easier to
> >> > support VPU and the video decoder drivers on the 32-bit SoCs.
> >> > My idea is to create a separate power domain provider which manages
> >> > these registers. Each power domain is exposed with it's own ID (just
> >> > like we have the CLKIDs in the clock driver) and can then be passed to
> >> > the various consumer drivers.
> >> > The genpd improvements in v4.19 and v4.20 make this possible as each
> >> > power domain can now be managed at runtime (not just at driver probe
> >> > time), see: [0]
> >> >
> >> > With a separate power domain provider the meson-gx-pwrc-vpu and video
> >> > decoder drivers would not access the AO registers anymore. Instead we
> >> > would pass all relevant power domains from the "AO power domain
> >> > provider" to their respective consumers.
> >>
> >> Overall, this seems like a reasonable way forward.
> >>
> >> I guess the important point is that we model the topology of the HW
> >> correctly in DT (no short cuts), as otherwise we may encounter issues
> >> in the end I think.
> > to get the DT part right I am thinking about the following questions:
> > - which IP blocks do we have? (I mentioned four in my original mail
> > where I *believe* that they are separate IP blocks, but I'm not sure)
>
> Besides the CPUs which we should handle separately, there's only 1 IP
> blocks that are managed upstream today (VPU/HDMI), so that's all you
> need to worry about for compatability, IMO.
ACK - and Maxime has already signaled that he's happy to change the vdec driver

> > - what are the inputs/outputs of each IP block? (example: IP block X
> > uses clock Y)
> > - what are the differences between the SoCs (not only the "new" 64-bit
> > ones, but also the 32-bit ones)?
>
> AFAICT, the 64-bit ones are quite similar to each other.  I haven't
> looked closely at the 32-bit ones at all.
do you know about any inputs to the power domains?
the VPU power domain currently for example manages the VPU clock. is this fine?
are there other cases where the power domain should manage the clock
(HDMI for example)?

> > - do we have dependencies between power domains?
>
> We definitely do between the top-level domains (see above.)
OK

> > (like in: do we need
> > to enable power domain before removing "isolation")
> > - what about the "isolation" bits - how do these work with the actual
> > "power domain" bits?
>
> The "isolation" is not a separate domain and should not be modeled as
> such like in your DT examples below.  It's just a step in the process.
> IOW, you isolate the domain, and then power it off.  Coming back, you
> power it on and then un-isolate it.
OK, understood, the combination of "power on/off + isolation" should
be exposed as a single "power domain" (everything else is managed by
the power controller driver internally)

> > - are the power domains just "on" or "off", or is there something in
> > between (like low/medium/high power or performance)?
>
> In general, they are on/off.
>
> However, CPUs are a bit special here as they can have various low-power
> modes, which is why (until very recently) they have been managed by the
> CPUidle framework, and not the power domain framework.  So for now, I
> recommend we get the domains in place for all the peripherals, and then
> consider the CPU management.
ACK

> > Ulf, since I'm new to this whole power-domain area: do my questions
> > make sense? what am I missing?
> >
> > Jianxin, can you please answer Ulf's and my questions on this topic?
> >
> >> >
> >> > Examples (incomplete) from the VPU power domain / video decoder perspective:
> >> > &vpu_power_domain {
> >> >   power-domains = <&ao_pwrc AO_VPU_HDMI_PD>, <&ao_pwrc AO_VPU_HDMI_ISO_PD>;
> >> >   power-domain-names = "vpu_hdmi", "vpu_hdmi_iso";
> >> > };
>
> As I mentioned above, don't model the "iso" as it's own domain.  The
> driver should handle the isolation bit and power bit ordering itself.
OK, understood and noted.

> >> > &video_decoder {
> >> >   power-domains = <&ao_pwrc AO_PWR_VDEC_1_PD>, <&ao_pwrc
> >> > AO_ISO_VDEC_1_PD>, <&ao_pwrc AO_PWR_VDEC_HVEC_PD>, <&ao_pwrc
> >> > AO_ISO_VDEC_HVEC_PD>;
> >> >   power-domain-names = "vdec_1", "vdec_1_iso", "vdec_hvec", "vdec_hvec_iso";
> >> > };
> >> >
> >> > My main concern is "backwards compatibility". We need to take care of
> >> > the VPU power domain driver and the video decoder driver. The latter
> >> > is not mainlined yet, so I'm not sure we need to be backwards
> >> > compatible here.
> >>
> >> Yeah, that could be a bit troublesome, at least short term.
> > indeed. the video decoder drivers are not part of mainline yet.
> > This means we "only" have to consider two "power domain consumers"
> > which already exist:
> > - VPU power domain / VPU driver (display support)
>
> I don't think you have to worry about backward compatability at all.
> Let's just create a new power-domain driver that manages everything (in
> EE) with a new compatable, and switch to it, leaving the old one for
> some time before eventually removing it.
OK, that means I'll have to be careful with the compatible string (I
have to invent a meaningful new one).
apart from that it should be straight forward, so I like the idea

> > - SMP / CPU hotplug support on the 32-bit SoCs (this currently doesn't
> > use the power-domain framework but a syscon in the platsmp.c driver)
>
> And I don't thing you should switch this to power-domain either, so I
> don't think this causes any concern for the new power domain driver.
OK. to educate myself: I assume that this is because the needs of the
SMP driver are so special that it makes no sense to model it as power
controller?

> >> I think I have mentioned it before, in some thread - perhaps we should
> >> add an OF helper function, which tells the caller the number of
> >> power-domains that is described in the device node. That could help to
> >> make the code more flexible in drivers/buses that deal with the PM
> >> domain attach/detach, thus also potentially simplify to support
> >> backwards compatibility, if/when that makes sense.
> >>
> >> >
> >> > Please let me know if you have any concerns, ideas, suggestions, ...
> >> > I can build an "RFC" series for this topic if this makes the discussion easier.
> >>
> >> It's always easier to look at code, unless there is a whiteboard available. :-)
> > OK, I'll wait for additional questions you may have so Jianxin can
> > provide the details we need to know about the actual hardware
> > implementation.
> > After that I can start an RFC series (Jianxin's input will help us to
> > focus on the Linux drivers rather than having to discuss - or even
> > guess - the hardware details over and over again)
>
> I can definitely help with this too.  If you can do an RFC with the "big
> picture", and proposal for the 32-bit SoCs, I can fill in all the
> missing pieces for the various 64-bit SoCs.
great, I'll work on an RFC - then we can figure out how to go from there!


Regards
Martin

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: Power Domains on Amlogic SoCs

[Maxime Jourdan]

Hi Martin

On Fri, Mar 1, 2019 at 11:30 PM Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> Hello,
>
> I would like to start a discussion how to structure the power domain
> drivers for the Amlogic SoCs.
> My main motivation is getting video output and video decoders working
> on the 32-bit SoCs.
>
> The Amlogic SoCs we various registers for "power domains", the ones I
> know (in no specific order):
> 1. HHI_MEM_PD_REG0 (contains: HDMI memory PD, Ethernet memory PD,
> audio DSP memory PD - at least on the 32-bit SoCs)
> 2. HHI_VPU_MEM_PD_REG{0,1,2} (contains: various VPU related power domains)
> 3. AO_RTI_GEN_PWR_SLEEP0, AO_RTI_GEN_PWR_ISO0 (contains: HDMI PD, HDMI
> isolation, video codec PDs, video code isolation, ...)
> 4. AO_RTI_PWR_A9_CNTL0/AO_RTI_PWR_SYS_CPU_PD0,
> P_AO_RTI_PWR_A9_CNTL1/AO_RTI_PWR_SYS_CPU_PD1 (contains: CPU core
> related power bits)
>
> currently we have three drivers, which handle *some* of these power
> domain registers:
> drivers/soc/amlogic/meson-gx-pwrc-vpu.c:
> - partially manages HHI_MEM_PD_REG0
> - fully manages HHI_VPU_MEM_PD_REG{0,1,2}
> - partially manages AO_RTI_GEN_PWR_SLEEP0
>
> arch/arm/mach-meson/platsmp.c:
> - manages AO_RTI_PWR_A9_CNTL0 and P_AO_RTI_PWR_A9_CNTL1
> - only for the 32-bit SoCs, these registers (or their replacements)
> are controlled by the firmware on the 64-bit SoCs
>
> drivers/media/platform/meson/vdec/* (not upstream yet due to firmware
> blob licensing questions, latest patchset: [1]):
> - also partially manages AO_RTI_GEN_PWR_SLEEP0, AO_RTI_GEN_PWR_ISO0
> (the former is also partially managed by meson-gx-pwrc-vpu)
>
> To use the meson-gx-pwrc-vpu driver on the 32-bit SoCs I would have to
> create an "AO regmap/syscon" and pass it to that driver. However, the
> register layout of the "AO bus" on these older SoCs is different to
> what we have on the 64-bit SoCs. So having a big "AO regmap/syscon" is
> not easy (I also believe that it even if we could achieve it then it
> wouldn't be a good representation of the hardware).
> The video decoder driver currently requires the same "AO regmap/syscon".
>
> I would like to focus on the AO_RTI_GEN_PWR_SLEEP0,
> AO_RTI_GEN_PWR_ISO0 registers for now. This will make it easier to
> support VPU and the video decoder drivers on the 32-bit SoCs.
> My idea is to create a separate power domain provider which manages
> these registers. Each power domain is exposed with it's own ID (just
> like we have the CLKIDs in the clock driver) and can then be passed to
> the various consumer drivers.
> The genpd improvements in v4.19 and v4.20 make this possible as each
> power domain can now be managed at runtime (not just at driver probe
> time), see: [0]
>
> With a separate power domain provider the meson-gx-pwrc-vpu and video
> decoder drivers would not access the AO registers anymore. Instead we
> would pass all relevant power domains from the "AO power domain
> provider" to their respective consumers.
>
> Examples (incomplete) from the VPU power domain / video decoder perspective:
> &vpu_power_domain {
>   power-domains = <&ao_pwrc AO_VPU_HDMI_PD>, <&ao_pwrc AO_VPU_HDMI_ISO_PD>;
>   power-domain-names = "vpu_hdmi", "vpu_hdmi_iso";
> };
>
> &video_decoder {
>   power-domains = <&ao_pwrc AO_PWR_VDEC_1_PD>, <&ao_pwrc
> AO_ISO_VDEC_1_PD>, <&ao_pwrc AO_PWR_VDEC_HVEC_PD>, <&ao_pwrc
> AO_ISO_VDEC_HVEC_PD>;
>   power-domain-names = "vdec_1", "vdec_1_iso", "vdec_hvec", "vdec_hvec_iso";
> };
>
> My main concern is "backwards compatibility". We need to take care of
> the VPU power domain driver and the video decoder driver. The latter
> is not mainlined yet, so I'm not sure we need to be backwards
> compatible here.
>

I'll gladly update the VDEC patch series to use power domains rather
than the AO syscon if you manage to get a power driver upstream!

When it comes to backwards compatibility, supporting both the power
bindings + AO syscon would be messy, but not the end of the world.

Maxime

> Please let me know if you have any concerns, ideas, suggestions, ...
> I can build an "RFC" series for this topic if this makes the discussion easier.
>
>
> Regards
> Martin
>
>
> [0] https://linuxplumbersconf.org/event/2/contributions/130/attachments/138/170/Genpd-Improvements.pdf
> [1] https://patchwork.kernel.org/patch/10669873/
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic