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 > = <&ftm0 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 = <&sysclk>; > > > - clock-names = "ipg"; > > > - fsl,rcpm-wakeup = <&rcpm 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 = <&ftm0 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 = <&sysclk>; > > - clock-names = "ipg"; > > - fsl,rcpm-wakeup = <&rcpm 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 = <&sysclk>; > - clock-names = "ipg"; > - fsl,rcpm-wakeup = <&rcpm 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(-)