From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> To: Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> Cc: Segher Boessenkool <segher-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>, Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>, "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" <devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>, "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Olof Johansson <olofj-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Subject: Re: [RFC 2/2] ARM:Tegra: Device Tree Support: Initialize audio card gpio's from the device tree. Date: Thu, 2 Jun 2011 09:40:05 -0600 [thread overview] Message-ID: <BANLkTikyDmPiSWFh2yemsz3Uk6UWu0Fksw@mail.gmail.com> (raw) In-Reply-To: <4DE403C5.7060003-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> On Mon, May 30, 2011 at 2:53 PM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> wrote: > Perhaps the interrupt-mapping binding is not the best model. Interrupt > hardware in general is hierarchical but is not isomorphic to the physical > addressing hierarchy of the device tree. > > GPIOs share the need to "point across the tree to different nodes", but it > is unclear that there is a need for a entirely different hierarchy. > > That suggests the possibility of using the device tree addressing mechanism > as much as possible. Normal device tree addresses could be used to specify > GPIO numbers. > > Suppose we have: > > gpio-controller1: gpio-controller { > #address-cells = <2>; > #mode-cells = <2>; > gpio1: gpio@12,0 { > reg = <12 0>; > mode = <55 66>; > usage = "Audio Codec chip select"; /* Optional */ > } > }; > gpio-controller2: gpio-controller { > #address-cells = <1>; > #mode-cells = <1>; > gpio2: gpio@4 { > reg = <4>; > #mode-cells = <1>; > } > }; > [...] > chipsel-gpio = <&gpio1>, > <&gpio-controller1 13 0 55 77>, > <0>, /* holes are permitted, means no GPIO 2 */ > <&gpio2 88>, > <&gpio-controller2 5 1>; > > > A GPIO spec consist of: > > 1) A reference to either a gpio-controller or a gpio device node. > > 2) 0 or more address cells, according to the value of #address-cells in the > referenced node. If the node has no #address-cells property, the value is > assumed to be 0. > > 3) 0 or more mode cells, according to the value of #mode-cells in the > referenced node. I can see having nodes for individual gpios being useful in circumstances, but I really don't like having multiple methods of specifying a gpio (handle to the gpio-controller, or a handle to the gpio node, and a different specifier depending on the contents of the target node). I think it will be less confusing for users if the reference is always to the gpio controller. A specific gpio controller can still use child nodes to capture extra information about specific gpios, but doing so doesn't need to be exposed to a gpio consumer; it can all be internal to the gpio controller and its hardware specific binding (since any mode details are going to be hardware specific anyway most likely). [Amending to the above which was written before you latest post: even with the refined proposal to link to only a child node, the gpio specifier still changes depending on the contents of the child node] If a gpio controller does use child nodes, then I do like the approach of using #{address,size}-cells to line up with gpio numbering. However, we've already got a definition of #gpio-cells in use which specifies the total number of cells for a '*-gpio' property binding, so I do want to take care not to conflict with the existing pattern. I suspect the solution would simply be to state that #gpio-cells >= #address-cells must be true. > In the example, the chipsel-gpio specs are interpreted as: > > <&gpio1> - refers to a pre-bound gpio device node, in which the address > (12 0) and mode (55 66) are specified within that node. > > <&gpio-controller1 13 0 55 77> - refers to a GPIO controller node, > specifing the address (13 0) and the mode (55 77) in the client's GPIO spec. > > <gpio2> - another reference to a gpio node on a different controller. In > this case the address (4) is bound in the gpio node, but the mode (88) is > passed in from the client's GPIO spec. > > <&gpio-controller2 5 1> - another reference to a controller node, with a > one-cell address (5) and a one-cell mode (1), according to the values of > #address-cells and #mode-cells in that controller node. > > I expect that the "pre-bound gpio node" case would get a lot of use in > practice, as it lets you isolate the client from the details of the > interrupt controller addressing and modes. In my experience, GPIOs often > get reassigned between revisions of the same board, especially early in the > development cycle. I'm not convinced that the pre-bound gpio node will be any better or worse from a usability standpoint that direct references. I've certainly not had problems with keeping up with gpio moves (and everything else moving) on the FPGA projects that I've worked with. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.
WARNING: multiple messages have this Message-ID (diff)
From: grant.likely@secretlab.ca (Grant Likely) To: linux-arm-kernel@lists.infradead.org Subject: [RFC 2/2] ARM:Tegra: Device Tree Support: Initialize audio card gpio's from the device tree. Date: Thu, 2 Jun 2011 09:40:05 -0600 [thread overview] Message-ID: <BANLkTikyDmPiSWFh2yemsz3Uk6UWu0Fksw@mail.gmail.com> (raw) In-Reply-To: <4DE403C5.7060003@firmworks.com> On Mon, May 30, 2011 at 2:53 PM, Mitch Bradley <wmb@firmworks.com> wrote: > Perhaps the interrupt-mapping binding is not the best model. ?Interrupt > hardware in general is hierarchical but is not isomorphic to the physical > addressing hierarchy of the device tree. > > GPIOs share the need to "point across the tree to different nodes", but it > is unclear that there is a need for a entirely different hierarchy. > > That suggests the possibility of using the device tree addressing mechanism > as much as possible. ?Normal device tree addresses could be used to specify > GPIO numbers. > > Suppose we have: > > ? ? ? ?gpio-controller1: gpio-controller { > ? ? ? ? ? ? ? ?#address-cells = <2>; > ? ? ? ? ? ? ? ?#mode-cells = <2>; > ? ? ? ? ? ? ? ?gpio1: gpio at 12,0 { > ? ? ? ? ? ? ? ? ? ?reg = <12 0>; > ? ? ? ? ? ? ? ? ? ?mode = <55 66>; > ? ? ? ? ? ? ? ? ? ?usage = "Audio Codec chip select"; ?/* Optional */ > ? ? ? ? ? ? ? ?} > ? ? ? ?}; > ? ? ? ?gpio-controller2: gpio-controller { > ? ? ? ? ? ? ? ? #address-cells = <1>; > ? ? ? ? ? ? ? ? #mode-cells = <1>; > ? ? ? ? ? ? ? ? gpio2: gpio at 4 { > ? ? ? ? ? ? ? ? ? ? reg = <4>; > ? ? ? ? ? ? ? ? ? ? #mode-cells = <1>; > ? ? ? ? ? ? ? ? } > ? ? ? ?}; > ? ? ? ?[...] > ? ? ? ?chipsel-gpio = ?<&gpio1>, > ? ? ? ? ? ? ? ? ? ? ? ?<&gpio-controller1 13 0 55 77>, > ? ? ? ? ? ? ? ? ? ? ? ?<0>, /* holes are permitted, means no GPIO 2 */ > ? ? ? ? ? ? ? ? ? ? ? ?<&gpio2 88>, > ? ? ? ? ? ? ? ? ? ? ? ?<&gpio-controller2 5 1>; > > > A GPIO spec consist of: > > 1) A reference to either a gpio-controller or a gpio device node. > > 2) 0 or more address cells, according to the value of #address-cells in the > referenced node. ?If the node has no #address-cells property, the value is > assumed to be 0. > > 3) 0 or more mode cells, according to the value of #mode-cells in the > referenced node. I can see having nodes for individual gpios being useful in circumstances, but I really don't like having multiple methods of specifying a gpio (handle to the gpio-controller, or a handle to the gpio node, and a different specifier depending on the contents of the target node). I think it will be less confusing for users if the reference is always to the gpio controller. A specific gpio controller can still use child nodes to capture extra information about specific gpios, but doing so doesn't need to be exposed to a gpio consumer; it can all be internal to the gpio controller and its hardware specific binding (since any mode details are going to be hardware specific anyway most likely). [Amending to the above which was written before you latest post: even with the refined proposal to link to only a child node, the gpio specifier still changes depending on the contents of the child node] If a gpio controller does use child nodes, then I do like the approach of using #{address,size}-cells to line up with gpio numbering. However, we've already got a definition of #gpio-cells in use which specifies the total number of cells for a '*-gpio' property binding, so I do want to take care not to conflict with the existing pattern. I suspect the solution would simply be to state that #gpio-cells >= #address-cells must be true. > In the example, the chipsel-gpio specs are interpreted as: > > <&gpio1> ?- ?refers to a pre-bound gpio device node, in which the address > (12 0) and mode (55 66) are specified within that node. > > <&gpio-controller1 13 0 55 77> ?- ?refers to a GPIO controller node, > specifing the address (13 0) and the mode (55 77) in the client's GPIO spec. > > <gpio2> ?- ?another reference to a gpio node on a different controller. ?In > this case the address (4) is bound in the gpio node, but the mode (88) is > passed in from the client's GPIO spec. > > <&gpio-controller2 5 1> ?- ?another reference to a controller node, with a > one-cell address (5) and a one-cell mode (1), according to the values of > #address-cells and #mode-cells in that controller node. > > I expect that the "pre-bound gpio node" case would get a lot of use in > practice, as it lets you isolate the client from the details of the > interrupt controller addressing and modes. ?In my experience, GPIOs often > get reassigned between revisions of the same board, especially early in the > development cycle. I'm not convinced that the pre-bound gpio node will be any better or worse from a usability standpoint that direct references. I've certainly not had problems with keeping up with gpio moves (and everything else moving) on the FPGA projects that I've worked with. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.
next prev parent reply other threads:[~2011-06-02 15:40 UTC|newest] Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-05-27 20:56 [RFC 0/2] ARM: Tegra: Device Tree: Audio John Bonesio 2011-05-27 20:56 ` John Bonesio 2011-05-27 20:57 ` [RFC 1/2] ARM:Tegra: Device Tree Support: Initialize the audio card from the device tree John Bonesio 2011-05-27 21:05 ` Grant Likely 2011-05-27 21:05 ` Grant Likely 2011-05-28 1:28 ` Mark Brown 2011-05-28 1:28 ` Mark Brown 2011-06-01 7:07 ` Barry Song 2011-06-01 7:07 ` Barry Song [not found] ` <BANLkTi=NMjBjWVv_o3PocejhgGr8TdG+1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-06-01 16:47 ` Grant Likely 2011-06-01 16:47 ` Grant Likely [not found] ` <BANLkTi=PtEhxxmZo2DqvmySCmnEd3LbezQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-06-02 9:07 ` Barry Song 2011-06-02 9:07 ` Barry Song [not found] ` <BANLkTikWpiY_o27OF-Jxvq7iPeWzrAYOsQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-06-02 16:04 ` Grant Likely 2011-06-02 16:04 ` Grant Likely [not found] ` <20110602160445.GA8373-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org> 2011-06-02 16:21 ` Barry Song 2011-06-02 16:21 ` Barry Song [not found] ` <BANLkTikGp_O-Wd3nMhbV+-RLeXZoWeB6eQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-06-02 21:43 ` Russell King - ARM Linux 2011-06-02 21:43 ` Russell King - ARM Linux [not found] ` <20110602214322.GC10532-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2011-06-03 2:32 ` Barry Song 2011-06-03 2:32 ` Barry Song [not found] ` <BANLkTikiaA3CCRAXkB=x56wtt8nNF9dqxA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-06-03 6:20 ` Russell King - ARM Linux 2011-06-03 6:20 ` Russell King - ARM Linux 2011-06-02 21:36 ` Russell King - ARM Linux 2011-06-02 21:36 ` Russell King - ARM Linux [not found] ` <20110602213656.GB10532-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2011-06-03 1:19 ` Barry Song 2011-06-03 1:19 ` Barry Song [not found] ` <BANLkTimavC-6oMhAHHsBJ2_Em7aXi7eyNQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-06-07 3:44 ` Barry Song 2011-06-07 3:44 ` Barry Song 2011-06-14 15:42 ` Grant Likely 2011-06-14 15:42 ` Grant Likely 2011-05-27 20:57 ` [RFC 2/2] ARM:Tegra: Device Tree Support: Initialize audio card gpio's " John Bonesio 2011-05-27 21:06 ` Grant Likely 2011-05-27 21:06 ` Grant Likely 2011-05-28 1:24 ` Mark Brown 2011-05-28 1:24 ` Mark Brown [not found] ` <20110528012427.GB5971-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> 2011-05-30 3:11 ` Olof Johansson 2011-05-30 3:11 ` Olof Johansson [not found] ` <BANLkTinKLcYmStvBEGDcN84BapJXe5Y5bg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-05-30 3:38 ` Mark Brown 2011-05-30 3:38 ` Mark Brown [not found] ` <20110530033826.GE4130-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> 2011-05-30 6:11 ` Grant Likely 2011-05-30 6:11 ` Grant Likely [not found] ` <20110530061155.GC23517-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org> 2011-05-30 6:18 ` Mitch Bradley 2011-05-30 6:18 ` Mitch Bradley [not found] ` <4DE336A1.5040509-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 2011-05-30 6:22 ` Grant Likely 2011-05-30 6:22 ` Grant Likely 2011-05-30 7:01 ` Mark Brown 2011-05-30 7:01 ` Mark Brown [not found] ` <20110530070138.GA5036-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> 2011-05-30 16:22 ` Grant Likely 2011-05-30 16:22 ` Grant Likely 2011-05-30 18:54 ` Segher Boessenkool 2011-05-30 18:54 ` Segher Boessenkool [not found] ` <8d2515b13c817cc956b185d043bcef00-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> 2011-05-30 19:20 ` Grant Likely 2011-05-30 19:20 ` Grant Likely [not found] ` <BANLkTi=hkScxYpt449CQCky+bLU3UvkC_A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-05-30 20:53 ` Mitch Bradley 2011-05-30 20:53 ` Mitch Bradley [not found] ` <4DE403C5.7060003-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 2011-05-31 17:55 ` Stephen Warren 2011-05-31 17:55 ` Stephen Warren [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF0498E1C22D-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> 2011-05-31 18:42 ` Mitch Bradley 2011-05-31 18:42 ` Mitch Bradley [not found] ` <4DE536AD.5080200-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 2011-06-01 15:59 ` Stephen Warren 2011-06-01 15:59 ` Stephen Warren [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF0498E1C3F5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> 2011-06-01 16:18 ` Mark Brown 2011-06-01 16:18 ` Mark Brown [not found] ` <20110601161856.GB15583-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> 2011-06-02 15:40 ` Grant Likely 2011-06-02 15:40 ` Grant Likely 2011-06-01 21:32 ` Mitch Bradley 2011-06-01 21:32 ` Mitch Bradley [not found] ` <4DE6AFF7.3040905-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 2011-06-03 21:24 ` Stephen Warren 2011-06-03 21:24 ` Stephen Warren [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF0498E1C870-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> 2011-06-04 0:25 ` Mitch Bradley 2011-06-04 0:25 ` Mitch Bradley 2011-06-02 14:59 ` Grant Likely 2011-06-02 14:59 ` Grant Likely 2011-06-02 15:40 ` Grant Likely [this message] 2011-06-02 15:40 ` Grant Likely 2011-06-28 21:39 ` Grant Likely 2011-06-28 21:39 ` Grant Likely 2011-05-30 23:27 ` Benjamin Herrenschmidt 2011-05-30 23:27 ` Benjamin Herrenschmidt 2011-05-30 23:49 ` Olof Johansson 2011-05-30 23:49 ` Olof Johansson [not found] ` <20110530234909.GA3411-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2011-05-31 0:58 ` Segher Boessenkool 2011-05-31 0:58 ` Segher Boessenkool 2011-05-31 10:24 ` Mark Brown 2011-05-31 10:24 ` Mark Brown 2011-05-30 7:10 ` Mark Brown 2011-05-30 7:10 ` Mark Brown 2011-05-30 23:26 ` Benjamin Herrenschmidt 2011-05-30 23:26 ` Benjamin Herrenschmidt 2011-05-31 10:03 ` Mark Brown 2011-05-31 10:03 ` Mark Brown
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=BANLkTikyDmPiSWFh2yemsz3Uk6UWu0Fksw@mail.gmail.com \ --to=grant.likely-s3s/wqlpoipyb63q8fvjnq@public.gmane.org \ --cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \ --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=olofj-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \ --cc=segher-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org \ --cc=wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org \ /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.