From: Tero Kristo <t-kristo@ti.com> To: ssantosh@kernel.org, linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org, robh+dt@kernel.org, p.zabel@pengutronix.de Cc: tony@atomide.com, devicetree@vger.kernel.org Subject: Re: [PATCHv2 01/11] dt-bindings: omap: add new binding for PRM instances Date: Fri, 30 Aug 2019 12:18:42 +0300 [thread overview] Message-ID: <8f4bcd94-6555-26cc-2458-51b0e8712f68@ti.com> (raw) In-Reply-To: <20190828071941.32378-2-t-kristo@ti.com> Hi Rob, Quick question below based on some discussion on the implementation details of the PRM support. On 28/08/2019 10:19, Tero Kristo wrote: > Add new binding for OMAP PRM (Power and Reset Manager) instances. Each > of these will act as a power domain controller and potentially as a reset > provider. > > Signed-off-by: Tero Kristo <t-kristo@ti.com> > --- > .../devicetree/bindings/arm/omap/prm-inst.txt | 31 +++++++++++++++++++ > 1 file changed, 31 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt > > diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt > new file mode 100644 > index 000000000000..7c7527c37734 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt > @@ -0,0 +1,31 @@ > +OMAP PRM instance bindings > + > +Power and Reset Manager is an IP block on OMAP family of devices which > +handle the power domains and their current state, and provide reset > +handling for the domains and/or separate IP blocks under the power domain > +hierarchy. > + > +Required properties: > +- compatible: Must be one of: > + "ti,am3-prm-inst" > + "ti,am4-prm-inst" > + "ti,omap4-prm-inst" > + "ti,omap5-prm-inst" > + "ti,dra7-prm-inst" Each of these bindings describes multiple PRM instances, like ti,dra7-prm-inst maps eventually into 21 different PRM instances. I end up matching these in the kernel based on base address to map additional details, like support for reset handling, supported reset bits, etc. What is your take on this, should I just provide individual compatible strings for these all, the total amount of them would end up being like 70+, or keep them like this? I find it rather cumbersome if I would have to deal with 70+ different compatibles... Also, I would need to keep updating the bindings doc once I add new instances on the supported list. -Tero > +- reg: Contains PRM instance register address range > + (base address and length) > + > +Optional properties: > +- #reset-cells: Should be 1 if the PRM instance in question supports resets. > +- clocks: Associated clocks for the reset signals if any. Certain reset > + signals can't be toggled properly without functional clock > + being active for them. > + > +Example: > + > +prm_dsp2: prm@1b00 { > + compatible = "ti,dra7-prm-inst"; > + reg = <0x1b00 0x40>; > + #reset-cells = <1>; > + clocks = <&dsp2_clkctrl DRA7_DSP2_MMU0_DSP2_CLKCTRL 0>; > +}; > -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
WARNING: multiple messages have this Message-ID (diff)
From: Tero Kristo <t-kristo@ti.com> To: <ssantosh@kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-omap@vger.kernel.org>, <robh+dt@kernel.org>, <p.zabel@pengutronix.de> Cc: tony@atomide.com, devicetree@vger.kernel.org Subject: Re: [PATCHv2 01/11] dt-bindings: omap: add new binding for PRM instances Date: Fri, 30 Aug 2019 12:18:42 +0300 [thread overview] Message-ID: <8f4bcd94-6555-26cc-2458-51b0e8712f68@ti.com> (raw) In-Reply-To: <20190828071941.32378-2-t-kristo@ti.com> Hi Rob, Quick question below based on some discussion on the implementation details of the PRM support. On 28/08/2019 10:19, Tero Kristo wrote: > Add new binding for OMAP PRM (Power and Reset Manager) instances. Each > of these will act as a power domain controller and potentially as a reset > provider. > > Signed-off-by: Tero Kristo <t-kristo@ti.com> > --- > .../devicetree/bindings/arm/omap/prm-inst.txt | 31 +++++++++++++++++++ > 1 file changed, 31 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt > > diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt > new file mode 100644 > index 000000000000..7c7527c37734 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt > @@ -0,0 +1,31 @@ > +OMAP PRM instance bindings > + > +Power and Reset Manager is an IP block on OMAP family of devices which > +handle the power domains and their current state, and provide reset > +handling for the domains and/or separate IP blocks under the power domain > +hierarchy. > + > +Required properties: > +- compatible: Must be one of: > + "ti,am3-prm-inst" > + "ti,am4-prm-inst" > + "ti,omap4-prm-inst" > + "ti,omap5-prm-inst" > + "ti,dra7-prm-inst" Each of these bindings describes multiple PRM instances, like ti,dra7-prm-inst maps eventually into 21 different PRM instances. I end up matching these in the kernel based on base address to map additional details, like support for reset handling, supported reset bits, etc. What is your take on this, should I just provide individual compatible strings for these all, the total amount of them would end up being like 70+, or keep them like this? I find it rather cumbersome if I would have to deal with 70+ different compatibles... Also, I would need to keep updating the bindings doc once I add new instances on the supported list. -Tero > +- reg: Contains PRM instance register address range > + (base address and length) > + > +Optional properties: > +- #reset-cells: Should be 1 if the PRM instance in question supports resets. > +- clocks: Associated clocks for the reset signals if any. Certain reset > + signals can't be toggled properly without functional clock > + being active for them. > + > +Example: > + > +prm_dsp2: prm@1b00 { > + compatible = "ti,dra7-prm-inst"; > + reg = <0x1b00 0x40>; > + #reset-cells = <1>; > + clocks = <&dsp2_clkctrl DRA7_DSP2_MMU0_DSP2_CLKCTRL 0>; > +}; > -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-08-30 9:18 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-28 7:19 [PATCHv2 00/11] soc: ti: add OMAP PRM driver (for reset) Tero Kristo 2019-08-28 7:19 ` Tero Kristo 2019-08-28 7:19 ` [PATCHv2 01/11] dt-bindings: omap: add new binding for PRM instances Tero Kristo 2019-08-28 7:19 ` Tero Kristo 2019-08-30 9:18 ` Tero Kristo [this message] 2019-08-30 9:18 ` Tero Kristo 2019-08-28 7:19 ` [PATCHv2 02/11] soc: ti: add initial PRM driver with reset control support Tero Kristo 2019-08-28 7:19 ` Tero Kristo 2019-08-28 7:19 ` Tero Kristo 2019-08-29 13:12 ` Philipp Zabel 2019-08-29 13:12 ` Philipp Zabel 2019-08-30 7:28 ` Tero Kristo 2019-08-30 7:28 ` Tero Kristo 2019-08-30 7:28 ` Tero Kristo 2019-08-30 9:02 ` Philipp Zabel 2019-08-30 9:02 ` Philipp Zabel 2019-08-30 9:11 ` Tero Kristo 2019-08-30 9:11 ` Tero Kristo 2019-08-28 7:19 ` [PATCHv2 03/11] soc: ti: omap-prm: poll for reset complete during de-assert Tero Kristo 2019-08-28 7:19 ` Tero Kristo 2019-08-29 13:14 ` Philipp Zabel 2019-08-29 13:14 ` Philipp Zabel 2019-08-30 9:07 ` Tero Kristo 2019-08-30 9:07 ` Tero Kristo 2019-08-28 7:19 ` [PATCHv2 04/11] soc: ti: omap-prm: add support for denying idle for reset clockdomain Tero Kristo 2019-08-28 7:19 ` Tero Kristo 2019-08-28 7:19 ` [PATCHv2 05/11] soc: ti: omap-prm: sync func clock status with resets Tero Kristo 2019-08-28 7:19 ` Tero Kristo 2019-08-29 13:25 ` Philipp Zabel 2019-08-29 13:25 ` Philipp Zabel 2019-08-30 7:03 ` Tero Kristo 2019-08-30 7:03 ` Tero Kristo 2019-08-28 7:19 ` [PATCHv2 06/11] soc: ti: omap-prm: support resets with no associated clockdomain Tero Kristo 2019-08-28 7:19 ` Tero Kristo 2019-08-28 7:19 ` [PATCHv2 07/11] soc: ti: omap-prm: add omap4 PRM data Tero Kristo 2019-08-28 7:19 ` Tero Kristo 2019-08-28 7:19 ` [PATCHv2 08/11] soc: ti: omap-prm: add data for am33xx Tero Kristo 2019-08-28 7:19 ` Tero Kristo 2019-08-28 7:19 ` [PATCHv2 09/11] soc: ti: omap-prm: add dra7 PRM data Tero Kristo 2019-08-28 7:19 ` Tero Kristo 2019-08-28 7:19 ` [PATCHv2 10/11] soc: ti: omap-prm: add am4 " Tero Kristo 2019-08-28 7:19 ` Tero Kristo 2019-08-28 7:19 ` [PATCHv2 11/11] soc: ti: omap-prm: add omap5 " Tero Kristo 2019-08-28 7:19 ` Tero Kristo
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8f4bcd94-6555-26cc-2458-51b0e8712f68@ti.com \ --to=t-kristo@ti.com \ --cc=devicetree@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=p.zabel@pengutronix.de \ --cc=robh+dt@kernel.org \ --cc=ssantosh@kernel.org \ --cc=tony@atomide.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.