From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mitch Bradley Subject: Re: [PATCH] of: support an enumerated-bus compatible value Date: Mon, 02 Jul 2012 08:36:10 -1000 Message-ID: <4FF1EA1A.9030307@firmworks.com> References: <1340924755-31447-1-git-send-email-swarren@wwwdotorg.org> <4FF0A6B6.8040902@gmail.com> <4FF1C567.4060809@wwwdotorg.org> <4FF1D8F9.9040005@firmworks.com> <4FF1DDBD.9050106@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FF1DDBD.9050106-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Stephen Warren Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org List-Id: devicetree@vger.kernel.org On 7/2/2012 7:43 AM, Stephen Warren wrote: > On 07/02/2012 11:23 AM, Mitch Bradley wrote: >> On 7/2/2012 5:59 AM, Stephen Warren wrote: >>> On 07/01/2012 01:36 PM, Rob Herring wrote: >>>> On 06/28/2012 06:05 PM, Stephen Warren wrote: >>>>> From: Stephen Warren >>>>> >>>>> An "enumerated" bus is one that is not memory-mapped, hence hence >>>>> typically has #address-cells=1, and #size-cells=0. Such buses would be >>>>> used to group related non-memory-mapped nodes together, often just >>>>> under >>>>> the top-level of the device tree. The ability to group nodes into a >>>>> non- >>>>> memory-mapped subnode of the root is important, since if nodes exist to >>>>> describe multiple entities of the same type, the nodes will have the >>>>> same name, and hence require a unit address to differentiate them. It >>>>> doesn't make sense to assign bogus unit addresses from the CPU's own >>>>> address space for this purpose. An example: >>>>> >>>>> regulators { >>>>> compatible = "enumerated-bus"; >>>>> #address-cells = <1>; >>>>> #size-cells = <0>; >>>>> >>>>> regulator@0 { >>>>> compatible = "regulator-fixed"; >>>>> reg = <0>; >>>>> }; >>>>> >>>>> regulator@1 { >>>>> compatible = "regulator-fixed"; >>>>> reg = <1>; >>>>> }; >>>>> }; >>>>> >>>>> Finally, because such buses are not memory-mapped, we avoid creating >>>>> any IO/memory resources for the device. >>>> >>>> This seems like a work-around to use reg instead of using cell-index >>>> (which is discouraged). reg in this case is really not a hardware >>>> description. Do you have an intended use or just trying to fix the error >>>> messages? >>> >>> I'm not familiar with cell-index; can you please describe it some more. >>> Looking at some existing files in arch/powerpc/boot/dts, it looks like >>> something that exists alongside reg rather than replacing it, so I don't >>> see how it'd solve the problem. >>> >>> The portion of .dts file quoted above is the use-case. In more general >>> terms, I need to add a bunch of non-memory-mapped devices to DT. There >>> are multiple devices of a given type. The DT node names should be named >>> after the class of device not the instance, and hence all get named the >>> same. Hence, I need a unit address to differentiate the node names. >>> Hence I need to use the reg property in order that the unit address >>> matches the reg property. Is there some other way of solving these >>> requirements other than using a unit address to make the node names >>> unique? >> >> One of Rob's objections was that, in this case, the reg property is not >> a hardware description. That's an interesting point. If in fact >> numerous such devices exist, there must be some mechanism for software >> to choose which device to talk to, typically a number. Is that the case >> for these devices? If so, that number is a perfectly valid "reg" >> property value. If not, how does software choose to talk to a specific >> device? > > Yes, the reg value is purely a unique ID that exists to satisfy DT > semantics. > > These regulators will eventually be referenced by phandles from the > drivers that use them, just like interrupts/GPIOs/... I just haven't > hooked up any clients that do so yet. I'm still confused. Are you saying that the regulators cannot be controlled by software? Personally, I don't have a problem with "inventing" unique IDs and using the reg property to convey them. I'm just wondering about how this system works. >