Re: [PATCH 2/3] Documentation: dt: binding: fsl: update property description for RCPM
On Mon, Sep 10, 2018 at 3:46 AM Ran Wang wrote:
>
> Hi Scott,
>
> On 2018/9/8 4:23, Scott Wood wrote:
> >
> > On Fri, 2018-08-31 at 11:52 +0800, Ran Wang wrote:
> > > +Optional properties:
> > > + - big-endian : Indicate RCPM registers is big-endian. A RCPM node
> > > + that doesn't have this property will be regarded as little-endian.
> >
> > You've just broken all the existing powerpc device trees that are big-endian
> > and have no big-endian property.
>
> Yes, powerpc RCPM driver (arch/powerpc/sysdev/fsl_rcpm.c) will not refer
> to big-endian. However, I think if Layerscape RCPM driver use different
> compatible
> id (such as ' fsl,qoriq-rcpm-2.2'), it might be safe. Is that OK?
For Layerscape Chassis(gen3) based chips, the Reference Manual named
the power management IP as COP_PMU instead of RCPM which makes sense
to me as the register map is also quite different from the reg map of
RCPM. So I think it is reasonable to create a new binding and driver
for the Chassis Gen3 based PMU. However, the
arch/powerpc/sysdev/fsl_rcpm.c driver probably should be moved to
drivers/soc/fsl, as the Gen2.x Chassis and RCPM IP are also used in
some non-PowerPC Layerscape SoCs. From what I know, all the RCPM
based IP are all big endian, so there is no need to add this property
for the old binding.
>
> > > + - : This string
> > > + is referred by RCPM driver to judge if the consumer (such as flex
> > > timer)
> > > + is able to be regards as wakeup source or not, such as
> > > + 'fsl,ls1012a-
> > > ftm'.
> > > + Further, this property will carry the bit mask info to control
> > > + coresponding wake up source.
> >
> > What will you do if there are multiple instances of a device with the same
> > compatible, and different wakeup bits?
>
> You got me! This is a problem in current version. Well, we have to decouple
> wake up
> source IP and RCPM driver. That's why I add a plat_pm driver to prevent wake
> up IP
> knowing any information of RCPM. So in current context, one idea come to me
> is to
> redesign property ' fsl,ls1012a-ftm = <0x2>;', change to 'fsl,ls1012a-ftm
> = < 0x2>;'
> What do you say? And could you tell me which API I can use to check if that
> device's
> name is ftm0 (for example we want to find a node ftm0: ftm@29d000)?
>
> >Plus, it's an awkward design in
> > general, and you don't describe what the value actually means (bits in which
> > register?).
>
> Yes, I admit my design looks ugly and not flexible and extensible enough.
> However, for above reason,
> do you have any good idea, please? :)
Why do you have to move the wakeup information from device nodes to
the RCPM/PMU node? For information related to both on-chip device and
SoC integration, the information normally goes into the node of
on-chip device instead of the integration IP's device node. Existing
example like: interrupt, clock, memory map, and etc. It is much
cleaner than listing all the interrupts in the interrupt controller's
node, right?
>
> As to the register information, I can explain here in details (will add to
> commit
> message of next version): There is a RCPM HW block which has register named
> IPPDEXPCR.
> It controls whether prevent certain IP (such as timer, usb, etc) from
> entering low
> power mode when system suspended. So it's necessary to program it if we want
> one
> of those IP work as a wakeup source. However, different Layerscape SoCs have
> different bit vs.
> IP mapping layout. So I have to record this information in device tree and
> fetched by RCPM driver
> directly.
>
> Do I need to list all SoC's mapping information in this binding doc for
> reference?
>
> >What was wrong with the existing binding?
>
> There was one version of RCPM patch which requiring property
> 'fsl,#rcpm-wakeup-cells' but was not
> accepted by upstream finally. Now we will no need it any longer due to new
> design allow case of multiple
> RCPM devices existing case.
>
> >Alternatively, use the clock bindings.
>
> Sorry I didn't get your point.
>
> > > -
> > > -Example:
> > > - lpuart0: serial@295 {
> > > - compatible = "fsl,ls1021a-lpuart";
> > > - reg = <0x0 0x295 0x0 0x1000>;
> > > - interrupts = ;
> > > - clocks = <>;
> > > - clock-names = "ipg";
> > > - fsl,rcpm-wakeup = < 0x0 0x4000>;
> > > + big-endian;
> > > + fsl,ls1012a-ftm = <0x2>;
> > > + fsl,pfe = <0xf020>;
> >
> > fsl,pfe is not documented.
>
> pfe patch is not upstream yet, will remove it.
>
> Regards,
> Ran
>
> > -Scott
>
RE: [PATCH 2/3] Documentation: dt: binding: fsl: update property description for RCPM
Hi Scott,
On 2018/9/8 4:23, Scott Wood wrote:
>
> On Fri, 2018-08-31 at 11:52 +0800, Ran Wang wrote:
> > +Optional properties:
> > + - big-endian : Indicate RCPM registers is big-endian. A RCPM node
> > + that doesn't have this property will be regarded as little-endian.
>
> You've just broken all the existing powerpc device trees that are big-endian
> and have no big-endian property.
Yes, powerpc RCPM driver (arch/powerpc/sysdev/fsl_rcpm.c) will not refer
to big-endian. However, I think if Layerscape RCPM driver use different
compatible
id (such as ' fsl,qoriq-rcpm-2.2'), it might be safe. Is that OK?
> > + - : This string
> > + is referred by RCPM driver to judge if the consumer (such as flex timer)
> > + is able to be regards as wakeup source or not, such as
> > + 'fsl,ls1012a-
> > ftm'.
> > + Further, this property will carry the bit mask info to control
> > + coresponding wake up source.
>
> What will you do if there are multiple instances of a device with the same
> compatible, and different wakeup bits?
You got me! This is a problem in current version. Well, we have to decouple
wake up
source IP and RCPM driver. That's why I add a plat_pm driver to prevent wake up
IP
knowing any information of RCPM. So in current context, one idea come to me is
to
redesign property ' fsl,ls1012a-ftm = <0x2>;', change to 'fsl,ls1012a-ftm =
< 0x2>;'
What do you say? And could you tell me which API I can use to check if that
device's
name is ftm0 (for example we want to find a node ftm0: ftm@29d000)?
>Plus, it's an awkward design in
> general, and you don't describe what the value actually means (bits in which
> register?).
Yes, I admit my design looks ugly and not flexible and extensible enough.
However, for above reason,
do you have any good idea, please? :)
As to the register information, I can explain here in details (will add to
commit
message of next version): There is a RCPM HW block which has register named
IPPDEXPCR.
It controls whether prevent certain IP (such as timer, usb, etc) from entering
low
power mode when system suspended. So it's necessary to program it if we want one
of those IP work as a wakeup source. However, different Layerscape SoCs have
different bit vs.
IP mapping layout. So I have to record this information in device tree and
fetched by RCPM driver
directly.
Do I need to list all SoC's mapping information in this binding doc for
reference?
>What was wrong with the existing binding?
There was one version of RCPM patch which requiring property
'fsl,#rcpm-wakeup-cells' but was not
accepted by upstream finally. Now we will no need it any longer due to new
design allow case of multiple
RCPM devices existing case.
>Alternatively, use the clock bindings.
Sorry I didn't get your point.
> > -
> > -Example:
> > - lpuart0: serial@295 {
> > - compatible = "fsl,ls1021a-lpuart";
> > - reg = <0x0 0x295 0x0 0x1000>;
> > - interrupts = ;
> > - clocks = <>;
> > - clock-names = "ipg";
> > - fsl,rcpm-wakeup = < 0x0 0x4000>;
> > + big-endian;
> > + fsl,ls1012a-ftm = <0x2>;
> > + fsl,pfe = <0xf020>;
>
> fsl,pfe is not documented.
pfe patch is not upstream yet, will remove it.
Regards,
Ran
> -Scott
Re: [PATCH 2/3] Documentation: dt: binding: fsl: update property description for RCPM
On Fri, 2018-08-31 at 11:52 +0800, Ran Wang wrote:
> +Optional properties:
> + - big-endian : Indicate RCPM registers is big-endian. A RCPM node
> + that doesn't have this property will be regarded as little-endian.
You've just broken all the existing powerpc device trees that are big-endian
and have no big-endian property.
> + - : This string
> + is referred by RCPM driver to judge if the consumer (such as flex timer)
> + is able to be regards as wakeup source or not, such as 'fsl,ls1012a-
> ftm'.
> + Further, this property will carry the bit mask info to control
> + coresponding wake up source.
What will you do if there are multiple instances of a device with the same
compatible, and different wakeup bits? Plus, it's an awkward design in
general, and you don't describe what the value actually means (bits in which
register?). What was wrong with the existing binding? Alternatively, use the
clock bindings.
> -
> -Example:
> - lpuart0: serial@295 {
> - compatible = "fsl,ls1021a-lpuart";
> - reg = <0x0 0x295 0x0 0x1000>;
> - interrupts = ;
> - clocks = <>;
> - clock-names = "ipg";
> - fsl,rcpm-wakeup = < 0x0 0x4000>;
> + big-endian;
> + fsl,ls1012a-ftm = <0x2>;
> + fsl,pfe = <0xf020>;
fsl,pfe is not documented.
-Scott
RE: [PATCH 2/3] Documentation: dt: binding: fsl: update property description for RCPM
Hi Rob > -Original Message- > From: Rob Herring > Sent: Tuesday, September 04, 2018 09:25 > To: Ran Wang > Cc: Leo Li ; Mark Rutland ; > linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH 2/3] Documentation: dt: binding: fsl: update property > description for RCPM > > On Fri, Aug 31, 2018 at 11:52:18AM +0800, Ran Wang wrote: > > Add property 'big-endian' and supportted IP's configuration info. > > Remove property 'fsl,#rcpm-wakeup-cell'. > > "dt-bindings: soc: ..." for the subject > > It is obvious reading the diff you are removing fsl,#rcpm-wakeup-cell. > What is not obvious is why? The commit msg should answer that. Sure, I will add this in next version patch. > You also are mixing several things in this patch like adding ls1012 which you > don't mention. Please split. Got it, will split them and add more information in next version. Ran > > > > Signed-off-by: Ran Wang > > --- > > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 42 ++--- > -- > > 1 files changed, 13 insertions(+), 29 deletions(-)
Re: [PATCH 2/3] Documentation: dt: binding: fsl: update property description for RCPM
On Fri, Aug 31, 2018 at 11:52:18AM +0800, Ran Wang wrote: > Add property 'big-endian' and supportted IP's configuration info. > Remove property 'fsl,#rcpm-wakeup-cell'. "dt-bindings: soc: ..." for the subject It is obvious reading the diff you are removing fsl,#rcpm-wakeup-cell. What is not obvious is why? The commit msg should answer that. You also are mixing several things in this patch like adding ls1012 which you don't mention. Please split. > > Signed-off-by: Ran Wang > --- > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 42 ++- > 1 files changed, 13 insertions(+), 29 deletions(-)
