[PATCH v12 0/3] ARM: rk3288: Add PM Domain support

[PATCH v12 0/3] ARM: rk3288: Add PM Domain support

[Caesar Wang]

    Add power domain drivers based on generic power domain for
    Rockchip platform, and support RK3288.

    https://chromium-review.googlesource.com/#/c/220253/9
    This is the GPU driver, add the following information in DT,
    and it can support the PMDOMAIN

gpu: gpu@ffa30000 {
    compatible = "arm,malit764",
                 "arm,malit76x",
                 "arm,malit7xx",
                 "arm,mali-midgard";
    reg = <0xffa30000 0x10000>;
    interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
                 <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
                 <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
    interrupt-names = "JOB", "MMU", "GPU";
    clocks = <&cru ACLK_GPU>;
    clock-names = "aclk_gpu";
    operating-points = <
                /* KHz uV */
                100000 800000
                200000 850000
                300000 950000
                400000 1000000
                600000 1150000
    >;
    power-domains = <&power RK3288_PD_GPU>;
    status = "disabled";
};

Based on:
    - [PATCH v4 1/3] PM / clock_ops: Add pm_clk_add_clk()
    http://patchwork.kernel.org/patch/5242121/

Changes in v12:
    - fix the title doamin->domain.
    - updated device_attach and device_detach API,otherwise it will compile
      fail on next kernel.
    - Remove essential clocks from rk3288 PD_VIO domain,
      Some clocks are essential for the system health and should not be
      turned down. However there is no owner for them so if they listed as
      belonging to power domain we'll try toggling them up and down during
      power domain transition. As a result we either fail to suspend or resume
      the system.

Changes in v11:
    - fix pm_genpd_init(&pd->genpd, NULL, false);

Changes in v10:
    - this switches over domain infos to use masks instead of recomputing
      them each time and also gets rid of custom domain translator and
      uses standard onecell on.
    - fix missing the #include <dt-bindings/power-domain/rk3288.h>
    - remove the notes

Changes in v9:
    - add document decription
    - fix v8 changes as follows:
    - This reconciles the v2 and v7 code so that we power domain have
      lists of clocks they toggle on and off during power transitions and
      independently from power domains clocks we attach clocks to devices
      comprising power domain and prepare them so they are turn on and off
      by runtime PM.
    - add rockchip_pm_add_one_domain() to control domains.
    - add pd_start/pd_stop interface to control clocks
    - add decription for power-doamin node

Changes in v8:
    - document go back to v2
    - This reconciles the v2 and v7 code so that we power domain have
      lists of clocks they toggle on and off during power transitions and
      independently from power domains clocks we attach clocks to devices
      comprising power domain and prepare them so they are turn on and off
      by runtime PM.
    - DTS go back to v2

Changes in v7:
    - Delete unused variables

Changes in v6:
    - delete pmu_lock
    - modify dev_lock using mutex
    - pm_clk_resume(pd->dev) change to pm_clk_resume(ed->dev)
    - pm_clk_suspend(pd->dev) change to pm_clk_suspend(ed->dev)
    - add devm_kfree(pd->dev, de) in rockchip_pm_domain_detach_dev

Changes in v5:
    - delete idle_lock
    - add timeout in rockchip_pmu_set_idle_request()

Changes in v4:
    - use list storage dev

Changes in v3:
    - DT structure has changed
    - change use pm_clk_resume() and pm_clk_suspend()
    - Decomposition power-controller, changed to multiple controller
    (gpu-power-controller, hevc-power-controller)

Changes in v2:
    - move clocks to "optional"
    - remove the "pd->pd.of_node = np"
    - make pd_vio clocks all one entry per line and alphabetize.
    - power: power-controller move back to pinctrl: pinctrl.

Caesar Wang (3):
  dt-bindings: add document of Rockchip power domain
  power-domain: rockchip: add power domain driver
  ARM: dts: add rk3288 power-domain node

 .../bindings/arm/rockchip/power_domain.txt         |  48 +++
 arch/arm/boot/dts/rk3288.dtsi                      |  59 +++
 arch/arm/mach-rockchip/Kconfig                     |   1 +
 arch/arm/mach-rockchip/Makefile                    |   1 +
 arch/arm/mach-rockchip/pm_domains.c                | 472 +++++++++++++++++++++
 include/dt-bindings/power-domain/rk3288.h          |  11 +
 6 files changed, 592 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/power_domain.txt
 create mode 100644 arch/arm/mach-rockchip/pm_domains.c
 create mode 100644 include/dt-bindings/power-domain/rk3288.h

-- 
1.9.1

[PATCH v12 0/3] ARM: rk3288: Add PM Domain support

[Caesar Wang]

    Add power domain drivers based on generic power domain for
    Rockchip platform, and support RK3288.

    https://chromium-review.googlesource.com/#/c/220253/9
    This is the GPU driver, add the following information in DT,
    and it can support the PMDOMAIN

gpu: gpu@ffa30000 {
    compatible = "arm,malit764",
                 "arm,malit76x",
                 "arm,malit7xx",
                 "arm,mali-midgard";
    reg = <0xffa30000 0x10000>;
    interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
                 <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
                 <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
    interrupt-names = "JOB", "MMU", "GPU";
    clocks = <&cru ACLK_GPU>;
    clock-names = "aclk_gpu";
    operating-points = <
                /* KHz uV */
                100000 800000
                200000 850000
                300000 950000
                400000 1000000
                600000 1150000
    >;
    power-domains = <&power RK3288_PD_GPU>;
    status = "disabled";
};

Based on:
    - [PATCH v4 1/3] PM / clock_ops: Add pm_clk_add_clk()
    http://patchwork.kernel.org/patch/5242121/

Changes in v12:
    - fix the title doamin->domain.
    - updated device_attach and device_detach API,otherwise it will compile
      fail on next kernel.
    - Remove essential clocks from rk3288 PD_VIO domain,
      Some clocks are essential for the system health and should not be
      turned down. However there is no owner for them so if they listed as
      belonging to power domain we'll try toggling them up and down during
      power domain transition. As a result we either fail to suspend or resume
      the system.

Changes in v11:
    - fix pm_genpd_init(&pd->genpd, NULL, false);

Changes in v10:
    - this switches over domain infos to use masks instead of recomputing
      them each time and also gets rid of custom domain translator and
      uses standard onecell on.
    - fix missing the #include <dt-bindings/power-domain/rk3288.h>
    - remove the notes

Changes in v9:
    - add document decription
    - fix v8 changes as follows:
    - This reconciles the v2 and v7 code so that we power domain have
      lists of clocks they toggle on and off during power transitions and
      independently from power domains clocks we attach clocks to devices
      comprising power domain and prepare them so they are turn on and off
      by runtime PM.
    - add rockchip_pm_add_one_domain() to control domains.
    - add pd_start/pd_stop interface to control clocks
    - add decription for power-doamin node

Changes in v8:
    - document go back to v2
    - This reconciles the v2 and v7 code so that we power domain have
      lists of clocks they toggle on and off during power transitions and
      independently from power domains clocks we attach clocks to devices
      comprising power domain and prepare them so they are turn on and off
      by runtime PM.
    - DTS go back to v2

Changes in v7:
    - Delete unused variables

Changes in v6:
    - delete pmu_lock
    - modify dev_lock using mutex
    - pm_clk_resume(pd->dev) change to pm_clk_resume(ed->dev)
    - pm_clk_suspend(pd->dev) change to pm_clk_suspend(ed->dev)
    - add devm_kfree(pd->dev, de) in rockchip_pm_domain_detach_dev

Changes in v5:
    - delete idle_lock
    - add timeout in rockchip_pmu_set_idle_request()

Changes in v4:
    - use list storage dev

Changes in v3:
    - DT structure has changed
    - change use pm_clk_resume() and pm_clk_suspend()
    - Decomposition power-controller, changed to multiple controller
    (gpu-power-controller, hevc-power-controller)

Changes in v2:
    - move clocks to "optional"
    - remove the "pd->pd.of_node = np"
    - make pd_vio clocks all one entry per line and alphabetize.
    - power: power-controller move back to pinctrl: pinctrl.

Caesar Wang (3):
  dt-bindings: add document of Rockchip power domain
  power-domain: rockchip: add power domain driver
  ARM: dts: add rk3288 power-domain node

 .../bindings/arm/rockchip/power_domain.txt         |  48 +++
 arch/arm/boot/dts/rk3288.dtsi                      |  59 +++
 arch/arm/mach-rockchip/Kconfig                     |   1 +
 arch/arm/mach-rockchip/Makefile                    |   1 +
 arch/arm/mach-rockchip/pm_domains.c                | 472 +++++++++++++++++++++
 include/dt-bindings/power-domain/rk3288.h          |  11 +
 6 files changed, 592 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/power_domain.txt
 create mode 100644 arch/arm/mach-rockchip/pm_domains.c
 create mode 100644 include/dt-bindings/power-domain/rk3288.h

-- 
1.9.1

Re: [PATCH v12 0/3] ARM: rk3288: Add PM Domain support

[Heiko Stübner]

Am Montag, 17. November 2014, 17:50:38 schrieb Caesar Wang:
>     Add power domain drivers based on generic power domain for
>     Rockchip platform, and support RK3288.
> 
>     https://chromium-review.googlesource.com/#/c/220253/9
>     This is the GPU driver, add the following information in DT,
>     and it can support the PMDOMAIN

I'm not sure what to do with this series. Kevin had concerns about the clocks 
being part of the power-domains and I don't see them actually addressed and/or 
Kevin being satisfied - actually he isn't even on the recipients list of this 
version of the series.


@Ceasar: you should include people being part of important previous 
conversations in new versions of patchsets - especially when they have voiced 
concerns.


I've added Tomasz whom I remember having previous experience on the Exynos 
Powerdomains, so maybe he can add some other perspective - new ideas.


@Tomasz: this is the part of Kevin's concerns from v10 of the powerdomain 
series:

Am Donnerstag, 13. November 2014, 12:24:47 schrieben Kevin Hilman:
> Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> writes:
> > Am Dienstag, 11. November 2014, 08:53:13 schrieb Kevin Hilman:
> >> I still don't like having lists of clocks in the power-domain DT.
> >> 
> >> DT is supposed to describe the hardware, and clocks are properties of
> >> devices, not power-domains, so the DT description should follow from
> >> that.
> > 
> > on the policy side one could argue that if the clock needs to be enabled
> > to
> > achieve sucessful domain state-changes, that it is also a property of the
> > domain itself in addition to the device.
> 
> You could, but from a hardware perspective, the clock is a property of
> the device.
> 
> > And on the pratical side we don't have drivers nor bindings for a big part
> > of the domain users - and this will probably be true for quite some time.
> > This of course makes it very impractical (or impossible) to collect the
> > clocks for parts like the gpu (mali), hevc, vcodec (video
> > encoder/decoder), rga (2d stuff), iep, isp.
> 
> This doesn't sound impossible at all.
> 
> You have to collect the clocks anyways.  The only debate is whether to
> list them in the device node or the power-domain node.
> 
> Even for devices without drivers, you just need a minimal node in the DT if
> which lists the clocks and has a phandle to the parent power domain.
> 
> Sounds rather simple to me, and since the DT is supposed to describe the
> hardware, doing it this way makes looking at the DT actually help
> understand the hardware.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v12 0/3] ARM: rk3288: Add PM Domain support

[Tomasz Figa]

On Fri, Nov 28, 2014 at 6:57 PM, Heiko Stübner <heiko@sntech.de> wrote:
>
> Am Montag, 17. November 2014, 17:50:38 schrieb Caesar Wang:
> >     Add power domain drivers based on generic power domain for
> >     Rockchip platform, and support RK3288.
> >
> >     https://chromium-review.googlesource.com/#/c/220253/9
> >     This is the GPU driver, add the following information in DT,
> >     and it can support the PMDOMAIN
>
> I'm not sure what to do with this series. Kevin had concerns about the clocks
> being part of the power-domains and I don't see them actually addressed and/or
> Kevin being satisfied - actually he isn't even on the recipients list of this
> version of the series.
>
>
> @Ceasar: you should include people being part of important previous
> conversations in new versions of patchsets - especially when they have voiced
> concerns.
>
>
> I've added Tomasz whom I remember having previous experience on the Exynos
> Powerdomains, so maybe he can add some other perspective - new ideas.
>

Thanks Heiko for adding me to this thread.

>
> @Tomasz: this is the part of Kevin's concerns from v10 of the powerdomain
> series:
>
> Am Donnerstag, 13. November 2014, 12:24:47 schrieben Kevin Hilman:
> > Heiko Stübner <heiko@sntech.de> writes:
> > > Am Dienstag, 11. November 2014, 08:53:13 schrieb Kevin Hilman:
> > >> I still don't like having lists of clocks in the power-domain DT.
> > >>
> > >> DT is supposed to describe the hardware, and clocks are properties of
> > >> devices, not power-domains, so the DT description should follow from
> > >> that.
> > >
> > > on the policy side one could argue that if the clock needs to be enabled
> > > to
> > > achieve sucessful domain state-changes, that it is also a property of the
> > > domain itself in addition to the device.
> >
> > You could, but from a hardware perspective, the clock is a property of
> > the device.
> >

Well, the system controller which control the power domains is also a
device. In DT we do not represent the domains alone, but rather the
system controller, which acts as a power domain provider. If it need
certain clocks to do its work, then I believe it should have them
listed in its node. However the dependencies between clocks and power
domains are not clear to me either, so I don't have any strong opinion
on whether this would be the best solution.

> > > And on the pratical side we don't have drivers nor bindings for a big part
> > > of the domain users - and this will probably be true for quite some time.
> > > This of course makes it very impractical (or impossible) to collect the
> > > clocks for parts like the gpu (mali), hevc, vcodec (video
> > > encoder/decoder), rga (2d stuff), iep, isp.
> >
> > This doesn't sound impossible at all.
> >
> > You have to collect the clocks anyways.  The only debate is whether to
> > list them in the device node or the power-domain node.
> >
> > Even for devices without drivers, you just need a minimal node in the DT if
> > which lists the clocks and has a phandle to the parent power domain.
> >
> > Sounds rather simple to me, and since the DT is supposed to describe the
> > hardware, doing it this way makes looking at the DT actually help
> > understand the hardware.
>

If the dependency between clocks and power domain is kind of "all
clocks of all devices in this domain should be enabled when performing
operation on the domain" then IMHO it should be more reasonable to put
the clocks only in nodes of respective devices and then follow the
links from the domain to devices inside of it and retrieve the clocks
from there, so that they don't have to be duplicated. AFAIK, we don't
like redundancy in DT.

Best regards,
Tomasz

Re: [PATCH v12 0/3] ARM: rk3288: Add PM Domain support

[Caesar Wang]

[-- Attachment #1: Type: text/plain, Size: 4759 bytes --]


On 2014年12月01日 22:57, Tomasz Figa wrote:
> On Fri, Nov 28, 2014 at 6:57 PM, Heiko Stübner <heiko@sntech.de> wrote:
>> Am Montag, 17. November 2014, 17:50:38 schrieb Caesar Wang:
>>>      Add power domain drivers based on generic power domain for
>>>      Rockchip platform, and support RK3288.
>>>
>>>      https://chromium-review.googlesource.com/#/c/220253/9
>>>      This is the GPU driver, add the following information in DT,
>>>      and it can support the PMDOMAIN
>> I'm not sure what to do with this series. Kevin had concerns about the clocks
>> being part of the power-domains and I don't see them actually addressed and/or
>> Kevin being satisfied - actually he isn't even on the recipients list of this
>> version of the series.
>>
>>
>> @Ceasar: you should include people being part of important previous
>> conversations in new versions of patchsets - especially when they have voiced
>> concerns.
>>
Thanks Heiko.
OK, Sorry.
I  missed some important people, I will add them in next patch.


>>
>> I've added Tomasz whom I remember having previous experience on the Exynos
>> Powerdomains, so maybe he can add some other perspective - new ideas.
>>
> Thanks Heiko for adding me to this thread.
>
>> @Tomasz: this is the part of Kevin's concerns from v10 of the powerdomain
>> series:
>>
>> Am Donnerstag, 13. November 2014, 12:24:47 schrieben Kevin Hilman:
>>> Heiko Stübner <heiko@sntech.de> writes:
>>>> Am Dienstag, 11. November 2014, 08:53:13 schrieb Kevin Hilman:
>>>>> I still don't like having lists of clocks in the power-domain DT.
>>>>>
>>>>> DT is supposed to describe the hardware, and clocks are properties of
>>>>> devices, not power-domains, so the DT description should follow from
>>>>> that.
>>>> on the policy side one could argue that if the clock needs to be enabled
>>>> to
>>>> achieve sucessful domain state-changes, that it is also a property of the
>>>> domain itself in addition to the device.
>>> You could, but from a hardware perspective, the clock is a property of
>>> the device.
>>>
> Well, the system controller which control the power domains is also a
> device. In DT we do not represent the domains alone, but rather the
> system controller, which acts as a power domain provider. If it need
> certain clocks to do its work, then I believe it should have them
> listed in its node. However the dependencies between clocks and power
> domains are not clear to me either, so I don't have any strong opinion
> on whether this would be the best solution.
>
>>>> And on the pratical side we don't have drivers nor bindings for a big part
>>>> of the domain users - and this will probably be true for quite some time.
>>>> This of course makes it very impractical (or impossible) to
>>> This doesn't sound impossible at all.
>>>
>>> You have to collect the clocks anyways.  The only debate is whether to
>>> list them in the device node or the power-domain node.
>>>
>>> Even for devices without drivers, you just need a minimal node in the DT if
>>> which lists the clocks and has a phandle to the parent power domain.
>>>
>>> Sounds rather simple to me, and since the DT is supposed to describe the
>>> hardware, doing it this way makes looking at the DT actually help
>>> understand the hardware.
> If the dependency between clocks and power domain is kind of "all
> clocks of all devices in this domain should be enabled when performing
> operation on the domain" then IMHO it should be more reasonable to put
> the clocks only in nodes of respective devices and then follow the
> links from the domain to devices inside of it and retrieve the clocks
> from there, so that they don't have to be duplicated. , we don't
> like redundancy in DT.

Thanks Tomasz for commnets.

Frankly,I agree your points,we can manager clocks in every devices of PM 
domains.

I remember jinkun havs submitted the newest v7 patch to fix it.
dts:  https://patchwork.kernel.org/patch/5144471/
driver: https://patchwork.kernel.org/patch/5144481/

But,this series patchs will  cause some problems.

Says:
we always be needed turn off clocks to save power when
the system enter suspend.So we need to enumerate the clocks are needed
to switch power doamin on and off .  I think the patch v7 will be an option
if devices of PM domains has the driver to manager the clocks. Now we only have the gpu and video driver.
but clocks for parts like the gpu (mali), hevc, vcodec (video
encoder/decoder), rga (2d stuff), iep, isp. These devices we need add the drives.

Otherwise,suspend/resume will fail. I know someone don't like to do so.
Maybe It is not perfect solution but just a workaround.
YUP,I believe someone can propose a better solution,but so far,I haven't a better way to solve it.  :-(


> Best regards,
> Tomasz
>
>
>


[-- Attachment #2: Type: text/html, Size: 7415 bytes --]