Re: Device trees and audio codecs
On Mon, Oct 22, 2007 at 08:07:14AM -0500, Timur Tabi wrote: Either you do it at driver __init time, or via a probe. The probe actually occurs at __init time, anyway, so they're kinda the same thing. The only thing the probe gets you is that you're called multiple times for each instance of a node in the tree. It also means that you're *not* called if there's no node in the tree at all -- which I believe was Jon's point about being platform specific. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
Jon Smirl wrote: Doing it that way will make the kernel specific to the target device. Currently I can load the same mpc5200 kernel on several different target devices since the platform specific code is triggered in the probe machine phase. Maybe I need to take a look at your code, but the fabric driver is, in effect, a platform-specific driver. Its job is to figure out what hardware is on the board, how it's connected, and then initialize and connect the other drivers as appropriate. I tried making the fabric driver into a platform driver instead of an openfirmware driver, but the mpc5200 code is not initializing platform drivers correctly. Yeah, that wouldn't work. Platform drivers are initialized way too early. I could insert calls into arch/powerpc/platforms/52xx/whatever to load the specific asoc fabric, but doing that is a mess. There must be a way to trigger loading of machine specific drivers Either you do it at driver __init time, or via a probe. The probe actually occurs at __init time, anyway, so they're kinda the same thing. The only thing the probe gets you is that you're called multiple times for each instance of a node in the tree. Since the Apple audio drivers are not ASoC drivers, I suggest we don't pay attention to what they do. Those Apple drivers are very similar to asoc drivers. They could easily be folded into the asoc code. Perhaps, but that's a job for another day (and another developer). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
Jon Smirl wrote: I meant an ac97 bus. ac97 is conceptually the same as i2s with the control signals also routed over it. ac97 and i2s are handled in the same PSC on the 5200. I have received conflicting opinions as to whether a codec hooked to an ac97 bus should get a chip specific codec entry in the device tree. I think it should. For one thing, ASoC requires a pointer to a structure in the codec device driver so that it knows which functions to call to change volume. What if you have multiple i2s/ac97 devices and multiple codecs? You'll need to know which i2s device is connected to which codec. The only way to distinguish that is by having a node for the codec under the i2s node. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
It seems to me there are four issues here: 1) How to describe the audio transport controller; 2) How to describe the codecs; 3) How the various parts are connected together in the device tree; 4) How to describe the layout. How do we want to be consistent with the Efika which uses an AC97 codec that only connects to i2s? Huh? AC'97 isn't I2S. Yeah you probably could hook it up to some I2S device if you do all the interleaving and whatever stuff by hand -- but then you probably shouldn't call the I2S host an I2S anymore, but name it ac97 in the device tree, or this-or-that-i2s-controller-hooked-up- in-this-particular-crazy-way. You will want to know which driver to use for the device, and if it's hooked up in strange and unforeseen ways you want to know about it. I meant an ac97 bus. ac97 is conceptually the same as i2s with the control signals also routed over it. ac97 and i2s are handled in the same PSC on the 5200. Okay. On any specific board, there can _only_ be ac97 or _only_ i2s codecs hooked onto the bus; the device node for the PSC should say which it is, either by having different compatible entries for the different modes, or by having some device-specific property in there saying which it is. Ideally, the name of the node would be i2s resp. ac97 as well. This handles 1). I have received conflicting opinions as to whether a codec hooked to an ac97 bus should get a chip specific codec entry in the device tree. Every codec gets its own device node, and its compatible entry describes it uniquely. This is a very basic property of device trees. This handles 2). Without the codec specific entry only generic ac97 features can be used. The Efika has a STA9766. Looking at the data sheet for the chip I see that it implements some proprietary functions in addition to the standard ones. asoc has a generic ac97 driver. Should the ac97 bus be required to have a entry for the generic ac97 device? It would make loading the driver much easier. If the kernel driver does _not_ recognise the codec in the device tree, it could use a generic ac97 codec driver, if such a thing indeed exists. If on the other hand it knows about the specific codec, it can use a chip- specific driver. AC'97 codecs are addressed over the AC'97 bus, so the codecs should be children of the ac97 bus in the device tree, and have fully qualified names like [EMAIL PROTECTED] or [EMAIL PROTECTED] etc. I2S codecs that are addressed (== its configuration registers written) over I2C should be children of their I2C bus in the device tree, with fully qualified names like [EMAIL PROTECTED]; they should show which I2S bus they sit on, for example by having an i2s-bus property (containing the phandle of the i2s bus) in the codec node. This is 3). Now for 4), the layout thing; you could try to describe the layout in the device tree, but that would probably fail; there just is too much variance. If I understand you correctly, you have a platform-specific layout driver; now you need to find a nice way to probe this from the device tree. Maybe you should just look at the properties in the root node of the device tree for this. _Please_ don't name busses that are not plain I2S i2s in the device tree. At best this means you'll need a quirk in the kernel code to deal with this later. the i2s and ac97 drivers for the mpc5200 already exist. I'm using these preexisting drivers. Sure, but that doesn't mean you cannot fix the way things are probed in those drivers. Bugs are there to fix ;-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On 10/21/07, Jon Smirl [EMAIL PROTECTED] wrote: I have received conflicting opinions as to whether a codec hooked to an ac97 bus should get a chip specific codec entry in the device tree. Without the codec specific entry only generic ac97 features can be used. The Efika has a STA9766. Looking at the data sheet for the chip I see that it implements some proprietary functions in addition to the standard ones. You definitely want the codec node on the control bus. This is analogous to how Ethernet PHYs are handled. The PHY nodes are children of an MDIO node (because that's the control path). The ethernet MAC node contains a phandle to the PHY. In I2S/I2C terms, the CODEC ~= MAC, I2C ~= MDIO and I2S ~= MAC. In AC97 terms this analogy doesn't work because AC97 doesn't separate the control and data interfaces. An AC97 codec is simply a child of an AC97 controller. For the MPC5200; the device tree should reflect the required mode. If the PSC needs to be in AC97 mode, then the device tree should say compatible = fsl,mpc5200b-psc-ac97. If the PSC needs to be in I2C mode, then it should be compatible = fsl,mpc5200b-psc-i2s. For the 5200 PSCs, the device node not only reflects the hardware (a PSC core), but also reflects the schematic design (it is wired either as an I2S bus or an AC97 bus). Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
Jon Smirl wrote: I'm working on ALSA ASoC support for a codec chip on my mpc5200 based target hardware. How should the codec be represented in the device tree? I'm also working on an ASoC driver, but for the 8610. I have a similar problem. Under ASoC the device drivers for the codec chips are platform independent. In the current ASoC model there are three device drivers: i2s (or spi, etc), the generic codec, and a platform specific 'fabric' driver. Some codecs are linked to both i2c and i2s. Annoying, isn't it? :-) You can use phandles to cross-reference nodes. I suggest putting the codec node under the i2s node (and containing I2S-specific information), and then putting another codec node under the i2c node (this is a new layout proposed by Scott Wood), and use a phandle to let the i2s-codec node point to the i2c-codec node. The fabric driver corresponds to the 'layout-id' in the Apple model. It tells how to configure the generic codec driver for the specific configuration needed by the actual platform hardware. For development purposes I'm using an Efika as a target platform. It is easy enough to load the i2s driver using the device tree. I can add entries to the i2s node to trigger loading of the generic sta9766 codec driver. How do I trigger loading the Efika specific fabric driver? You don't need a device tree entry to trigger loading a driver. You can just load the driver and initialize it in its __init function. However, in this case, you might want to do what I'm doing -- putting a probe function in the fabric driver for the i2s device (which gets its own node under the SOC node), and then in that probe function search for all the other nodes that you need. My target hardware has a codec that is linked to both i2s and i2c. How should it be represented? Apple has three entries. One for i2s, one for the codec, and one for soundchip. What is the soundchip entry, does it correspond to real hardware? Since the Apple audio drivers are not ASoC drivers, I suggest we don't pay attention to what they do. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On 10/21/07, Timur Tabi [EMAIL PROTECTED] wrote: For development purposes I'm using an Efika as a target platform. It is easy enough to load the i2s driver using the device tree. I can add entries to the i2s node to trigger loading of the generic sta9766 codec driver. How do I trigger loading the Efika specific fabric driver? You don't need a device tree entry to trigger loading a driver. You can just load the driver and initialize it in its __init function. However, in this case, you might want to do what I'm doing -- putting a probe function in the fabric driver for the i2s device (which gets its own node under the SOC node), and then in that probe function search for all the other nodes that you need. Doing it that way will make the kernel specific to the target device. Currently I can load the same mpc5200 kernel on several different target devices since the platform specific code is triggered in the probe machine phase. I tried making the fabric driver into a platform driver instead of an openfirmware driver, but the mpc5200 code is not initializing platform drivers correctly. I could insert calls into arch/powerpc/platforms/52xx/whatever to load the specific asoc fabric, but doing that is a mess. There must be a way to trigger loading of machine specific drivers Since the Apple audio drivers are not ASoC drivers, I suggest we don't pay attention to what they do. Those Apple drivers are very similar to asoc drivers. They could easily be folded into the asoc code. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
I'm working on ALSA ASoC support for a codec chip on my mpc5200 based target hardware. What is ASoC? Under ASoC the device drivers for the codec chips are platform independent. In the current ASoC model there are three device drivers: i2s (or spi, etc), the generic codec, and a platform specific 'fabric' driver. Some codecs are linked to both i2c and i2s. The i2s driver is simply for data transport, the codec driver does, well, what codecs do; and what is the fabric driver for? Just to know which output ports are which, etc.? The fabric driver corresponds to the 'layout-id' in the Apple model. It tells how to configure the generic codec driver for the specific configuration needed by the actual platform hardware. The apple layout-id selects one of several tables with *lots* of info. I think you want a subset of that only. My target hardware has a codec that is linked to both i2s and i2c. How should it be represented? Since the codec is addressable on i2c, and not on i2s, it should be a child node of the i2c bus it sits on; and then you put a property in the codec node pointing to the i2s bus node it is connected to. Multiple of those (or multiple entries) if it is connected to more than one i2s bus. i2s-parent might be a good name for such a prop. Apple has three entries. One for i2s, one for the codec, and one for soundchip. What is the soundchip entry, does it correspond to real hardware? /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]: This is one of the i2s channels on the macio. Dunno why they put all those platform-XXX entries in here, (most of) these don't logically belong here. /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/sound: The codec. I guess Apple puts this here for their weirdo platform-do stuff; don't imitate this :-) /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]: The codec. _Do_ put it here in your tree :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On 10/21/07, Segher Boessenkool [EMAIL PROTECTED] wrote: I'm working on ALSA ASoC support for a codec chip on my mpc5200 based target hardware. What is ASoC? asoc = ALSA System on a Chip. It is in sound/soc Under ASoC the device drivers for the codec chips are platform independent. In the current ASoC model there are three device drivers: i2s (or spi, etc), the generic codec, and a platform specific 'fabric' driver. Some codecs are linked to both i2c and i2s. The i2s driver is simply for data transport, the codec driver does, well, what codecs do; and what is the fabric driver for? Just to know which output ports are which, etc.? Fabric driver tells how the generic codec is hooked up on the specific board. Some of the codecs are extremely flexible and can be hooked up hundreds of different ways. It is like GPIO pins, they are wired in however is convenient for the design. The fabric driver corresponds to the 'layout-id' in the Apple model. It tells how to configure the generic codec driver for the specific configuration needed by the actual platform hardware. The apple layout-id selects one of several tables with *lots* of info. I think you want a subset of that only. The fabric/layout-id stuff is platform specific. My target hardware has a codec that is linked to both i2s and i2c. How should it be represented? Since the codec is addressable on i2c, and not on i2s, it should be a child node of the i2c bus it sits on; and then you put a property in the codec node pointing to the i2s bus node it is connected to. Multiple of those (or multiple entries) if it is connected to more than one i2s bus. i2s-parent might be a good name for such a prop. How do we want to be consistent with the Efika which uses an AC97 codec that only connects to i2s? Apple has three entries. One for i2s, one for the codec, and one for soundchip. What is the soundchip entry, does it correspond to real hardware? /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]: This is one of the i2s channels on the macio. Dunno why they put all those platform-XXX entries in here, (most of) these don't logically belong here. Actually those platform-XXX entries may be the solution I am looking for. I can use the generic i2s driver to load a fabric driver as an ALSA module. /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/sound: The codec. I guess Apple puts this here for their weirdo platform-do stuff; don't imitate this :-) /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]: The codec. _Do_ put it here in your tree :-) -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On 10/21/07, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Sun, 2007-10-21 at 17:33 -0400, Jon Smirl wrote: This is one of the i2s channels on the macio. Dunno why they put all those platform-XXX entries in here, (most of) these don't logically belong here. Actually those platform-XXX entries may be the solution I am looking for. I can use the generic i2s driver to load a fabric driver as an ALSA module. Yuck. And your alternative is? I can use the DTC to load the I2S and codec drivers. How do I get the platform specific fabric driver loaded? There is no way to load a driver matching on the platform name. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On Sun, 2007-10-21 at 18:12 -0400, Jon Smirl wrote: On 10/21/07, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Sun, 2007-10-21 at 17:33 -0400, Jon Smirl wrote: This is one of the i2s channels on the macio. Dunno why they put all those platform-XXX entries in here, (most of) these don't logically belong here. Actually those platform-XXX entries may be the solution I am looking for. I can use the generic i2s driver to load a fabric driver as an ALSA module. Yuck. And your alternative is? I can use the DTC to load the I2S and codec drivers. How do I get the platform specific fabric driver loaded? There is no way to load a driver matching on the platform name. platform-do-XXX is unrelated to that. It's a kind of script in a blob that is used to toggle various bits, it's plain ugly, totally powermac specific (the code to handle it is in platform/powermac and I won't make it generic) and so you don't want it... ever. For your problem, an option is to do like apple, and have a sound pseudo device which represents the sound subsystem of the machine which cn ahave a compatible property and other bits that you can use to match your fabric against, and loads the other bits pieces. Except that I would put it at the root of the tree. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
Fabric driver tells how the generic codec is hooked up on the specific board. Some of the codecs are extremely flexible and can be hooked up hundreds of different ways. It is like GPIO pins, they are wired in however is convenient for the design. Gotcha. *Very* much like GPIOs, indeed. The fabric driver corresponds to the 'layout-id' in the Apple model. It tells how to configure the generic codec driver for the specific configuration needed by the actual platform hardware. The apple layout-id selects one of several tables with *lots* of info. I think you want a subset of that only. The fabric/layout-id stuff is platform specific. I mean that Apple's layout-id abstraction is bigger than your fabric abstraction seems to be. Not too important a point, anyway. My target hardware has a codec that is linked to both i2s and i2c. How should it be represented? Since the codec is addressable on i2c, and not on i2s, it should be a child node of the i2c bus it sits on; and then you put a property in the codec node pointing to the i2s bus node it is connected to. Multiple of those (or multiple entries) if it is connected to more than one i2s bus. i2s-parent might be a good name for such a prop. How do we want to be consistent with the Efika which uses an AC97 codec that only connects to i2s? Huh? AC'97 isn't I2S. Yeah you probably could hook it up to some I2S device if you do all the interleaving and whatever stuff by hand -- but then you probably shouldn't call the I2S host an I2S anymore, but name it ac97 in the device tree, or this-or-that-i2s-controller-hooked-up- in-this-particular-crazy-way. You will want to know which driver to use for the device, and if it's hooked up in strange and unforeseen ways you want to know about it. Maybe the platform code should do this, dunno. _Please_ don't name busses that are not plain I2S i2s in the device tree. At best this means you'll need a quirk in the kernel code to deal with this later. /rant So anyway, why is it inconsistent to have an audio codec that is configured over i2c sit on that i2c bus in the device tree as well, and refer to the i2s bus it pumps audio data over; vs. having an ac97 codec that sits on an ac97 bus sit on that ac97 bus in the device tree as well? In both cases, the device is a child of the bus via which it is addressed. The one exceptional case would be a dumb codec that isn't addressable at all; it would be a device tree child of the dumb transport bus (where else could it be put)? Actually those platform-XXX entries may be the solution I am looking for. Like Ben already said, no you _do not_ want the platform-do stuff. Trust him on this. Or if you're feeling brave, look at the existing kernel code that handles some of it ;-P Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On 10/21/07, Segher Boessenkool [EMAIL PROTECTED] wrote: How do we want to be consistent with the Efika which uses an AC97 codec that only connects to i2s? Huh? AC'97 isn't I2S. Yeah you probably could hook it up to some I2S device if you do all the interleaving and whatever stuff by hand -- but then you probably shouldn't call the I2S host an I2S anymore, but name it ac97 in the device tree, or this-or-that-i2s-controller-hooked-up- in-this-particular-crazy-way. You will want to know which driver to use for the device, and if it's hooked up in strange and unforeseen ways you want to know about it. I meant an ac97 bus. ac97 is conceptually the same as i2s with the control signals also routed over it. ac97 and i2s are handled in the same PSC on the 5200. I have received conflicting opinions as to whether a codec hooked to an ac97 bus should get a chip specific codec entry in the device tree. Without the codec specific entry only generic ac97 features can be used. The Efika has a STA9766. Looking at the data sheet for the chip I see that it implements some proprietary functions in addition to the standard ones. asoc has a generic ac97 driver. Should the ac97 bus be required to have a entry for the generic ac97 device? It would make loading the driver much easier. _Please_ don't name busses that are not plain I2S i2s in the device tree. At best this means you'll need a quirk in the kernel code to deal with this later. the i2s and ac97 drivers for the mpc5200 already exist. I'm using these preexisting drivers. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Device trees and audio codecs
I'm working on ALSA ASoC support for a codec chip on my mpc5200 based target hardware. How should the codec be represented in the device tree? Under ASoC the device drivers for the codec chips are platform independent. In the current ASoC model there are three device drivers: i2s (or spi, etc), the generic codec, and a platform specific 'fabric' driver. Some codecs are linked to both i2c and i2s. The fabric driver corresponds to the 'layout-id' in the Apple model. It tells how to configure the generic codec driver for the specific configuration needed by the actual platform hardware. For development purposes I'm using an Efika as a target platform. It is easy enough to load the i2s driver using the device tree. I can add entries to the i2s node to trigger loading of the generic sta9766 codec driver. How do I trigger loading the Efika specific fabric driver? My target hardware has a codec that is linked to both i2s and i2c. How should it be represented? Apple has three entries. One for i2s, one for the codec, and one for soundchip. What is the soundchip entry, does it correspond to real hardware? /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]: name i2s-a device_type soundbus compatible i2sbus built-in reg 0001 1000 8000 0100 8100 0100 interrupts 001e 0001 0001 0002 interrupt-parent ff981a38 platform-headphone-mute ff9828a0 platform-amp-mute ff9829f8 platform-hw-reset ff982b48 platform-linein-detect ff982c98 platform-headphone-detect ff982e58 platform-get-enable ff97c3b0 platform-enable ff97c3b0 platform-disable ff97c3b0 platform-get-clock-enable ff97c3b0 platform-clock-enable ff97c3b0 platform-clock-disable ff97c3b0 platform-get-sw-reset ff97c3b0 platform-clear-sw-reset ff97c3b0 platform-sw-reset ff97c3b0 platform-get-cell-enable ff97c3b0 platform-cell-enable ff97c3b0 platform-cell-disable ff97c3b0 linux,phandleff985b88 /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/sound: name sound device_type soundchip compatible AOAbase built-in layout-id0046 (70) object-model-version 0002 vendor-id106b (4203) platform-tas-codec-ref ff98cba8 linux,phandleff985d48 /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]: name codec device_type codec compatible tas3004 codec reg 006a (106) built-in platform-do-tas-codec-ref ff985d48 0800 0027 linux,phandleff98cba8 -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
