On 21/03/2016 at 02:24:32 +0000, Yang, Wenyou wrote : > Hi Alexandre, > > > -----Original Message----- > > From: Alexandre Belloni [mailto:alexandre.belloni@xxxxxxxxxxxxxxxxxx] > > Sent: 2016年3月18日 1:15 > > To: Yang, Wenyou <Wenyou.Yang@xxxxxxxxx> > > Cc: Ferre, Nicolas <Nicolas.FERRE@xxxxxxxxx>; Jean-Christophe Plagniol- > > Villard <plagnioj@xxxxxxxxxxxx>; Russell King <linux@xxxxxxxxxxxxxxxx>; linux- > > kernel@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-arm- > > kernel@xxxxxxxxxxxxxxxxxxx; linux-clk@xxxxxxxxxxxxxxx; Rob Herring > > <robh+dt@xxxxxxxxxx>; Pawel Moll <pawel.moll@xxxxxxx>; Mark Brown > > <broonie@xxxxxxxxxx>; Ian Campbell <ijc+devicetree@xxxxxxxxxxxxxx>; Kumar > > Gala <galak@xxxxxxxxxxxxxx> > > 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 : > > > 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 <wenyou.yang@xxxxxxxxx> > > > > 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). > > 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. > 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. > Well, we don't really care about the mechanism. We only care about how the user is able to configure the wakeup sources. 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? 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. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
