From: Tero Kristo <t-kristo@ti.com> To: Rob Herring <robh@kernel.org> Cc: devicetree@vger.kernel.org, Tony Lindgren <tony@atomide.com>, Philipp Zabel <p.zabel@pengutronix.de>, Santosh Shilimkar <ssantosh@kernel.org>, linux-omap <linux-omap@vger.kernel.org>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances Date: Tue, 3 Sep 2019 11:14:19 +0300 [thread overview] Message-ID: <7c2c8a4d-d24e-ceec-afc1-04cdc4d5d952@ti.com> (raw) In-Reply-To: <CAL_Jsq+AJj1bgOQYG=c86A5HC_g2UZph387oVEKZyP4M18kURw@mail.gmail.com> On 03/09/2019 11:10, Rob Herring wrote: > On Tue, Sep 3, 2019 at 8:26 AM Tero Kristo <t-kristo@ti.com> wrote: >> >> On 02/09/2019 16:39, Rob Herring wrote: >>> On Fri, Aug 30, 2019 at 03:18:07PM +0300, 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. >>>> >>> >>> Converting this to schema would be nice. >> >> Do you have documentation about schema somewhere? Basically what I need >> to do to fix this. > > Documentation/devicetree/writing-schema.md (.rst in -next) > Documentation/devicetree/bindings/example-schema.yaml > >>>> Signed-off-by: Tero Kristo <t-kristo@ti.com> >>>> --- >>>> .../devicetree/bindings/arm/omap/prm-inst.txt | 31 +++++++++++++++++++ >>> >>> bindings/reset/ >> >> I did not put this under reset, because this is basically a >> multi-purpose function. Reset just happens to be the first functionality >> it is going to provide. It will be followed by power domain support >> later on. >> >> Any thoughts? > > I prefer that bindings be complete as possible even if driver support > is not there yet. Adding power domain support may only mean adding > '#power-domain-cells'. > > The location is fine then. Yeah, I assume just adding power-domain-cells should be enough. I am not too sure before I start trying this out though so did not want to add it yet. > >>>> 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" >>> >>> '-inst' seems a bit redundant. >> >> ti,xyz-prm is already reserved by the parent node of all these. >> >> The hierarchy is basically like this (omap4 as example): >> >> prm: prm@4a306000 { >> compatible = "ti,omap4-prm"; >> ... >> >> prm_dsp: prm@400 { >> compatible = "ti,omap4-prm-inst"; >> ... >> }; >> >> prm_device: prm@1b00 { >> compatible = "ti,omap4-prm-inst"; >> ... >> }; >> >> ... >> }; > > Okay. Then you need to state this binding must be a child of PRM. The > schema would need to take this into account too, so probably best to > not convert this yet. > Ok thanks, I'll make the necessary updates and post v4. -Tero -- 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: Rob Herring <robh@kernel.org> Cc: devicetree@vger.kernel.org, Tony Lindgren <tony@atomide.com>, Philipp Zabel <p.zabel@pengutronix.de>, Santosh Shilimkar <ssantosh@kernel.org>, linux-omap <linux-omap@vger.kernel.org>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances Date: Tue, 3 Sep 2019 11:14:19 +0300 [thread overview] Message-ID: <7c2c8a4d-d24e-ceec-afc1-04cdc4d5d952@ti.com> (raw) In-Reply-To: <CAL_Jsq+AJj1bgOQYG=c86A5HC_g2UZph387oVEKZyP4M18kURw@mail.gmail.com> On 03/09/2019 11:10, Rob Herring wrote: > On Tue, Sep 3, 2019 at 8:26 AM Tero Kristo <t-kristo@ti.com> wrote: >> >> On 02/09/2019 16:39, Rob Herring wrote: >>> On Fri, Aug 30, 2019 at 03:18:07PM +0300, 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. >>>> >>> >>> Converting this to schema would be nice. >> >> Do you have documentation about schema somewhere? Basically what I need >> to do to fix this. > > Documentation/devicetree/writing-schema.md (.rst in -next) > Documentation/devicetree/bindings/example-schema.yaml > >>>> Signed-off-by: Tero Kristo <t-kristo@ti.com> >>>> --- >>>> .../devicetree/bindings/arm/omap/prm-inst.txt | 31 +++++++++++++++++++ >>> >>> bindings/reset/ >> >> I did not put this under reset, because this is basically a >> multi-purpose function. Reset just happens to be the first functionality >> it is going to provide. It will be followed by power domain support >> later on. >> >> Any thoughts? > > I prefer that bindings be complete as possible even if driver support > is not there yet. Adding power domain support may only mean adding > '#power-domain-cells'. > > The location is fine then. Yeah, I assume just adding power-domain-cells should be enough. I am not too sure before I start trying this out though so did not want to add it yet. > >>>> 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" >>> >>> '-inst' seems a bit redundant. >> >> ti,xyz-prm is already reserved by the parent node of all these. >> >> The hierarchy is basically like this (omap4 as example): >> >> prm: prm@4a306000 { >> compatible = "ti,omap4-prm"; >> ... >> >> prm_dsp: prm@400 { >> compatible = "ti,omap4-prm-inst"; >> ... >> }; >> >> prm_device: prm@1b00 { >> compatible = "ti,omap4-prm-inst"; >> ... >> }; >> >> ... >> }; > > Okay. Then you need to state this binding must be a child of PRM. The > schema would need to take this into account too, so probably best to > not convert this yet. > Ok thanks, I'll make the necessary updates and post v4. -Tero -- 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-09-03 8:14 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-30 12:18 [PATCHv3 00/10] soc: ti: add OMAP PRM driver (for reset) Tero Kristo 2019-08-30 12:18 ` Tero Kristo 2019-08-30 12:18 ` [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances Tero Kristo 2019-08-30 12:18 ` Tero Kristo 2019-09-02 13:39 ` Rob Herring 2019-09-02 13:39 ` Rob Herring 2019-09-03 7:25 ` Tero Kristo 2019-09-03 7:25 ` Tero Kristo 2019-09-03 8:10 ` Rob Herring 2019-09-03 8:10 ` Rob Herring 2019-09-03 8:14 ` Tero Kristo [this message] 2019-09-03 8:14 ` Tero Kristo 2019-09-03 13:16 ` Tony Lindgren 2019-09-03 13:16 ` Tony Lindgren 2019-09-03 13:25 ` Philipp Zabel 2019-09-03 13:25 ` Philipp Zabel 2019-09-03 13:19 ` Adam Ford 2019-09-03 13:19 ` Adam Ford 2019-09-03 13:50 ` Tero Kristo 2019-09-03 13:50 ` Tero Kristo 2019-09-06 10:35 ` [PATCHv4 " Tero Kristo 2019-09-06 10:35 ` Tero Kristo 2019-09-06 12:56 ` Rob Herring 2019-09-06 12:56 ` Rob Herring 2019-09-06 15:36 ` Tony Lindgren 2019-09-06 15:36 ` Tony Lindgren 2019-09-06 20:02 ` Tero Kristo 2019-09-06 20:02 ` Tero Kristo 2019-08-30 12:18 ` [PATCHv3 02/10] soc: ti: add initial PRM driver with reset control support Tero Kristo 2019-08-30 12:18 ` Tero Kristo 2019-08-30 12:18 ` [PATCHv3 03/10] soc: ti: omap-prm: poll for reset complete during de-assert Tero Kristo 2019-08-30 12:18 ` Tero Kristo 2019-08-30 12:18 ` [PATCHv3 04/10] soc: ti: omap-prm: add support for denying idle for reset clockdomain Tero Kristo 2019-08-30 12:18 ` Tero Kristo 2019-08-30 12:18 ` [PATCHv3 05/10] soc: ti: omap-prm: sync func clock status with resets Tero Kristo 2019-08-30 12:18 ` Tero Kristo 2019-08-30 12:18 ` [PATCHv3 06/10] soc: ti: omap-prm: add omap4 PRM data Tero Kristo 2019-08-30 12:18 ` Tero Kristo 2019-08-30 12:18 ` [PATCHv3 07/10] soc: ti: omap-prm: add data for am33xx Tero Kristo 2019-08-30 12:18 ` Tero Kristo 2019-08-30 12:18 ` [PATCHv3 08/10] soc: ti: omap-prm: add dra7 PRM data Tero Kristo 2019-08-30 12:18 ` Tero Kristo 2019-08-30 12:18 ` [PATCHv3 09/10] soc: ti: omap-prm: add am4 " Tero Kristo 2019-08-30 12:18 ` Tero Kristo 2019-08-30 12:18 ` [PATCHv3 10/10] soc: ti: omap-prm: add omap5 " Tero Kristo 2019-08-30 12:18 ` Tero Kristo 2019-08-30 16:50 ` [PATCHv3 00/10] soc: ti: add OMAP PRM driver (for reset) santosh.shilimkar 2019-08-30 16:50 ` santosh.shilimkar 2019-09-02 6:50 ` Tero Kristo 2019-09-02 6:50 ` 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=7c2c8a4d-d24e-ceec-afc1-04cdc4d5d952@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@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.