From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <9e4733910710242011y771d5cbbuaa1eb274672ccb48@mail.gmail.com> Date: Wed, 24 Oct 2007 23:11:37 -0400 From: "Jon Smirl" To: "Jon Smirl" , "Grant Likely" , "PowerPC dev list" , "Timur Tabi" Subject: Re: Audio codec device tree entries In-Reply-To: <20071025003849.GB24382@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <471F52ED.10007@freescale.com> <9e4733910710240828x412f598dy7fc4a75faa76358d@mail.gmail.com> <9e4733910710240854y6ac115b6i5e0400eb369fcf7@mail.gmail.com> <20071025000425.GD23694@localhost.localdomain> <9e4733910710241717i3c436e76l48f6c273d7114b94@mail.gmail.com> <20071025003849.GB24382@localhost.localdomain> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 10/24/07, David Gibson wrote: > On Wed, Oct 24, 2007 at 08:17:57PM -0400, Jon Smirl wrote: > > On 10/24/07, David Gibson wrote: > > > I'm afraid I still don't understand quite what information this > > > "fabric" driver is conveying. Is it really inherently platform > > > specific, or is it something that can be encoded directly in a > > > sensible way. If the latter we could have a general "device tree" > > > fabric driver that will handle all systems with the layout correctly > > > encoded in the device tree. > > > > Codecs are like GPIOs, all of their pins are programmable. So the same > > codec can be wired into various boards quite differently and then > > software programmed to work the same. The fabric driver contains the > > mapping information. > > > > People were making a codec driver for each board, but this resulted in > > lots of similar codec drivers for the same chips. I believe a common > > Wolfson chip had eight drivers in the kernel. In the new model the > > codec drivers are generic and the fabric driver describes the mapping. > > Ok, but the fabric driver is about the wiring of a specific codec > chip, yes? If a board was foolishly designed to have two identical > codec chips, but each wired differently, it would need two instances > of the same codec driver, plus one instance each of two different > fabric drivers? AFAIK no one has built that case. My target board has two different codec chips. I was handling them both in a single fabric driver but there is no reason the code couldn't be split. I was thinking that there was a single fabric for the board, but you are right in observing that it is per codec chip. The term fabric is coming from the Apple aoa driver. They only have a single fabric per board. But there is no reason the Apple driver couldn't also be adjusted. > If this is so, then the fabric information *must* be per-codec, and > should therefore go with the codec node. > > > A side effect of this is that we need to load the fabric driver which > > doesn't have a device associated with it. > > Well, it does have a device associated with it, it's just a question > of how to represent it. There's not reason a single device node can't > cause instantiation of multiple driver instances. Depending on the > complexity of typical fabric arrangements, one of the following > options might make sense: > - the device node's compatible has enough information to > specify both fabric and codec driver. The fabric driver is > instantiated from this node, and instantiates the codec driver itself > (since I gather fabric drivers are frequently codec specific in any > case). This could work. The generic codec is a alsa soc_device_driver, not a of_device_driver. The codec node could instantiate the fabric as a of_device_driver which could then instantiate the soc_device_driver for the generic codec. The generic codecs are supposed to work cross platform so they can't include code that munges the of device tree. > - both fabric and codec drivers are instantiated from the same > device node, and co-ordinate with each other. > - The codec is represented as: > codec-fabric@... { > compatible = "..."; > > codec { > compatible = "..."; > > } > } > > This is different from a "pseudo" node, because the codec-fabric node > represents a real piece of hardware: specifically the cluster of > wires between the sound bus and the codec. > > Remember: the device tree describes the hardware, how the chooses to > structure its driver model to meet the demands of that hardware is up > to it. Don't put the cart before the horse. > > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson > -- Jon Smirl jonsmirl@gmail.com