lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 19 Mar 2021 14:09:43 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Aisheng Dong <aisheng.dong@....com>
Cc:     Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Ying Liu <victor.liu@....com>, Peng Fan <peng.fan@....com>,
        dl-linux-imx <linux-imx@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] firmware: imx: scu-pd: Update comments for single global
 power domain

On Fri, 19 Mar 2021 at 04:31, Aisheng Dong <aisheng.dong@....com> wrote:
>
> Hi Ulf,
>
> > From: Ulf Hansson <ulf.hansson@...aro.org>
> > Sent: Wednesday, March 17, 2021 5:31 PM
> >
> > Since the introduction of the PM domain support for the scu-pd, the genpd
> > framework has been continuously improved. More preciously, using a single
> > global power domain can quite easily be deployed for imx platforms.
> >
> > To avoid confusions, let's therefore make an update to the comments about
> > the missing pieces.
> >
> > Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
>
> Thanks for the update.
> Reviewed-by: Dong Aisheng <aisheng.dong@....com>
>
> BTW, I'm still uncertain if the new approach can finally work well for i.MX as SCU PD
> also supports multiple low power state.
> I could investigate it more when I adding multi low power states support.

The multiple low power states are currently only supported per genpd
and not per device. So, yes, in principle you could have one genpd per
device as you currently model it, to support this.

Although, thinking long term wise, we probably want something else
that doesn't rely on the device to be attached to a genpd to support
this use case.

In the past, I have been talking to different people from various SoC
vendors and it looks like the use case is there, but it's kind of
messy to support it. I would certainly be very interested to hear
about your use case, would you mind sharing some more about this?

Moreover, note that, there is a limitation in the genpd infrastructure
when you build a hierarchy with parent/childs genpds, when each genpd
has multiple idle states. That is, a parent-genpd may be allowed to
enter any of its idle states, no matter what idle state that has been
selected for the child-genpd. As a matter of fact, I am about to fix
this problem quite soon. Is perhaps this something that could be
valuable for your platforms too?

[...]

Kind regards
Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ