Hi Alexandre,

-----Original Message-----
From: Alexandre Belloni [mailto:alexandre.belloni at free-electrons.com]
Sent: 2016?3?24? 19:25
To: Yang, Wenyou <redacted>
Cc: Ferre, Nicolas <redacted>; Jean-Christophe Plagniol-
Villard [off-list ref]; Russell King [off-list ref]; linux-
kernel at vger.kernel.org; devicetree at vger.kernel.org; linux-arm-
kernel at lists.infradead.org; linux-clk at vger.kernel.org; Rob Herring
[off-list ref]; Pawel Moll [off-list ref]; Mark Brown
[off-list ref]; Ian Campbell [off-list ref]; Kumar
Gala [off-list ref]
Subject: Re: [PATCH v5 3/5] ARM: at91: pm: configure PMC fast startup signals

On 21/03/2016 at 02:24:32 +0000, Yang, Wenyou wrote :

quoted

Hi Alexandre,

quoted

-----Original Message-----
From: Alexandre Belloni
[mailto:alexandre.belloni at free-electrons.com]
Sent: 2016?3?18? 1:15
To: Yang, Wenyou <redacted>
Cc: Ferre, Nicolas <redacted>; Jean-Christophe
Plagniol- Villard [off-list ref]; Russell King
[off-list ref]; linux- kernel at vger.kernel.org;
devicetree at vger.kernel.org; linux-arm- kernel at lists.infradead.org;
linux-clk at vger.kernel.org; Rob Herring [off-list ref]; Pawel
Moll [off-list ref]; Mark Brown [off-list ref]; Ian
Campbell [off-list ref]; Kumar Gala
[off-list ref]
Subject: Re: [PATCH v5 3/5] ARM: at91: pm: configure PMC fast
startup signals

On 16/03/2016 at 14:58:07 +0800, Wenyou Yang wrote :

quoted

The fast startup signal is used as wake up sources for ULP1 mode.
As soon as a fast startup signal is asserted, the embedded 12 MHz
RC oscillator restarts automatically.

This patch is to configure the fast startup signals, which signal
is enabled to trigger the PMC to wake up the system from ULP1 mode
should be configured via the DT.

Signed-off-by: Wenyou Yang <redacted>

I would actually avoid doing that from the PMC driver and do that
configuration from the aic5 driver. It has all the information you
need, it knows what kind of level or edge is needed to wake up and
what are the wakeup interrupts to enable. This will allow you to
stop introducing a new binding. Also, this will avoid discrepancies
between what is configured in the DT and what the user really wants
(for exemple differences between the edge direction configured for the PIOBu

in userspace versus what is in the device tree or wakeonlan
activation/deactivation).

quoted

Thank you for your feedback.

But some wake-ups such as WKUP pin, ACC_CE, RXLP_MCE, don't have the
corresponding

The WKUP pin can be configured from the shdwc driver, ACC_CE from the ACC
driver, RXLP_MCE, from the RXLP driver because you will need drivers for those
at some point anyway.

quoted

interrupt number. Moreover, I think, the ULP1 is very different form
the ULP0, it is not woken up by the interrupt. It is fallen sleep and woken up by

the some mechanism in the PMC.

quoted

Well, we don't really care about the mechanism. We only care about how the user
is able to configure the wakeup sources.

Understand your concerns.

With your patch set, what happens when no ULP1 sources are defined but there
are ULP0 sources? What happens when there are both ULP1 and ULP0 sources?

I think there is only one mode, either ULP1 or ULP0, in a runtime system.
The ULP1 sources are used to wake up the ULP1, and the ULP0 sources wake up the ULP0,
they don't mutually effect each other.

If system is in the ULP1 mode, and there are no ULP1 sources defined, the system will fail to
be waken up, even though there are ULP0 sources defined. The ULP0 source can't wake up the ULP1.

What would be good is to use ULP1 when only ULP1 sources are set up and
ULP0 in the other cases. This will greatly help the user. Also, what I'm suggesting
actually allows to change the ULP1 sources at runtime from devices that are
actually used which is quite better than setting them up statically from DT.

In the ULP1 mode, all clocks are disabled. It can get lower consumption and
quicker wake up (the processor restarts in less than 10us) than ULP0 mode.

The number of wake up sources is limited as well. It is very different from ULP0's


Hi Nicolas, what is your opinions?


Best Regards,
Wenyou Yang