Re: Revisited, audio codec device tree entries.
David Gibson wrote: 1) We have a universal device-tree-based fabric driver which parses all the above-described interconnection information in the device tree and handles any situation. Cool, but probably a lot of work and fiddly to get right. Definitely a lot of work. I suggest we wait until there are a few PowerPC ASOC v2 audio drivers in the kernel before we even consider this. And it may not even be possible. I can easily imagine situations where we need board-specific code that belongs in a machine-specific fabric driver. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On 11/26/07, Timur Tabi [EMAIL PROTECTED] wrote: David Gibson wrote: 1) We have a universal device-tree-based fabric driver which parses all the above-described interconnection information in the device tree and handles any situation. Cool, but probably a lot of work and fiddly to get right. Definitely a lot of work. I suggest we wait until there are a few PowerPC ASOC v2 audio drivers in the kernel before we even consider this. And it may not even be possible. I can easily imagine situations where we need board-specific code that belongs in a machine-specific fabric driver. I'm fixing up the asoc v2 code to use MODULE_DEVICE_TABLE() and the real kernel aliasing/insmod system. Half of why we are having trouble is because asoc isn't using this mechanism. I've posted patches fixing i2c to use the same mechanism. I don't have the asoc ones ready yet. -- Timur Tabi Linux kernel developer at Freescale -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
Jon Smirl wrote: I'm fixing up the asoc v2 code to use MODULE_DEVICE_TABLE() and the real kernel aliasing/insmod system. Half of why we are having trouble is because asoc isn't using this mechanism. I've posted patches fixing i2c to use the same mechanism. I don't have the asoc ones ready yet. I look forward to porting my driver to ASoC V2 once the dust settles. :-) In the meantime, I'll post the V1 version this week or next. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
And I forgot the rant you guys usually get - for god's sake, why isn't
anyone using the model property?
Probably because it isn't useful all that often.
[EMAIL PROTECTED] {
\\ this is our magic audio fabric
device_type = digispeaker,flinger;
This is wrong in so many ways; see David's mail for a start.
\\ and this defines the layout Jon picked for the DACs
\\ just like Apple's layout-id value
model = flinger,2
flinger is some company that sells something they call the 2?
Interesting.
model should be the real-world exact model name/number of the device.
Isn't the primary concern of an audio codec, to play audio?
And the primary purpose of the device tree is to describe the hardware,
and (indirectly) how to program it. For an audio codec that has I2C
and I2S connections, the interface over which you program it is I2C.
There are other technicalities, too; for example, if the codec node
would be a child node of the I2S bus, you cannot have two codecs with
the same name on one such bus (since that bus isn't a bus really,
it's more like a broadcast interface; it cannot address separate devices
on that bus, so in the device tree the codecs wouldn't get a reg,
etc.)
Therefore, shouldn't the audio codec point back to it's control
interface?
No. The codec node _is_ the control interface.
Also, why give the name as 'i2s-handle'?
Why not?
Surely it could be any interface.
No it cannot; this property is only present for audio codecs that have
an I2S bus (and not even all those, it is dependent on the device
binding
in use).
In reverse, it would be, perhaps, as
above, i2c-handle, but then what if you change the interface
type (for instance a bunch of Wolfson codecs can do i2c and
spi for control). Your property name is obselete, then and
drivers will need to switch on property names to find out
which control interface is present.
That's another great argument against doing as you suggest, yes.
What they should really do, is be told where their control
interface handle is, then you can look at that handle and
the device it contains
What you *should* do is just look at the parent node if you want to
know how to talk to the device. This is the same for *all* nodes in
*all* device trees.
Remember, it doesn't matter what NAME you give it, the name
is for people to read,
Not only. When the generic naming recommended practice is in use,
name
can be used to find all nodes of a certain type. Neither name nor
device_type should be used for device driver matching though;
compatible
is for that.
[As a historic note, before the generic naming thing, name was used
for exactly what the first entry in compatible is used for now. But
let's try to forget that, okay?]
device_type is what you search for,
Unless you are programming in real Open Firmware itself, you do _not_
search for device_type. Ever.
and phandles let you attach specific devices to each other.
compatible is for when you want to tell people it acts the
same as this
_Including_ acts the same as itself.
and model is to give you the enviable ability
to define PRECISELY what you are looking at beyond a chip
name.
When a device driver uses model for anything, it is typically because
compatible says the device is a member of some family of devices that
all behave identically, but uh-oh, this isn't actually true.
It's also not all that great for human readers, since the format is
vendor-specific.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
Matt, the various properties you list do not mean what you think they mean. name - should be named according to the generic names convention. It's pretty much arbitrary, meant for human readability of the device tree. Drivers should not depend on it (some do, historically, but new drivers and trees should not). It is not arbitrary, there is a single well-defined name for every common class of device. It _is_ machine-readable (but shouldn't be used for driver matching, indeed -- it says nothing about the programming model). device_type - indicates the open firmware method interface for the device. Not method interface, just interface. Therefore, meaningless in flattened trees. Even in flat trees, a device_type of for example block indicates the node will have the required properties for that device type, for example block-size. Such properties are perfectly useful. OTOH, it isn't very useful to search for device with a specific device type from within the kernel, since it currently has no firmware interaction to speak of (flat trees don't interact, and the kernel kills real OF dead as soon as possible). No new driver should use this. Not without very good rationalisation, anyway. compatible - *this* is the one for driver selection. It describes the hardware level interface(s) of the device. model - usually just for debugging / diagnosis / human-readable purposes, describes exact model / revision of the hardware. It can be used to enable driver quirks / workarounds for when various devices are supposed to be compatible (as encoded in 'compatible') but aren't, due to hardware bugs. However, you should never aim to use it this way in design. Yeah. Any non-workaround value a driver would derive from model is usually better described using a separate property. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
Matt Sealey wrote: Jon Smirl wrote: The codec-fabric node was just being used to trigger the loading of the platform specific driver. Just remember one thing. 1) the term fabric when coined for audio drivers is a new, ALSA SoC specific term. It isn't relevant for anything but ALSA SoC drivers. Earlier this year, when I started working on an ASoC driver, the fabric driver was called a machine driver. 2) this device tree stuff will end up in more than Linux device trees Sorry, I don't understand. The device trees are technically OS-independent, so technically there's no such thing as a Linux device tree. In addition, the current master repository for device trees happens to be the Linux kernel, so I'm not sure where else device trees are going to be. 3) you're going to piss off Open Firmware developers by specifying very Linux-specific features in a device tree the same way Apple pissed off Linux developers by encoding MacOS X-specific features in the device tree. The current device trees have left their OF roots behind. Sure, we try to conform as much as possible, but they're not OF trees any more. Audio driver control like this has to be very specific for a good reason; you can do it a billion ways to Sunday. I'd suggest basically that if you must control a device in a way that needs to be defined by a device which can change address (either dynamically on boot or by board design change - per revision, for example, or with a change of controller) then simply use the device tree to report this address so that you can have the same basic fabric driver (all in Linux) which can handle minor modifications of your board design. My position is that the fabric driver should be loaded as a normal device tree and it should use the device tree to pick up some data to help it instantiate the other drivers. I'll be posting the code to my PowerPC ASoC driver in a couple weeks. If you require the codec to be subservient to some fabric then I The codec is subservient to a bus (sometimes multiple buses), which is why it is a child to bus nodes. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
Jon Smirl wrote: In the ALSA SOC model the i2s, codec and ac97 drivers are all generic. A fabric driver tells specifically how a generic codec is wired into the board. What I haven't been able figure out is how to load the right fabric driver. Do not use the device tree to load the fabric driver! The layout of the hardware and the relationship between the I2S, I2C, codec, and whatever device is determined by *both* the fabric driver and the device tree. The information about the devices itself, and *some* information about their relationship is stored in the device tree. Everything else is in the fabric driver. The design of the device tree is already locked in stone, so to speak. The DT can only store what it is allowed to store. If there's something more that you need, you'll have to put it in the fabric driver. If I weren't on vacation this week, I'd email you my code. It's almost done and it demonstrates what I'm thinking. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
So, like, the other day Timur Tabi mumbled: If I weren't on vacation this week, I'd email you my code. It's almost done and it demonstrates what I'm thinking. Are the margins of this paper too small for your proof? jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: In the ALSA SOC model the i2s, codec and ac97 drivers are all generic. A fabric driver tells specifically how a generic codec is wired into the board. What I haven't been able figure out is how to load the right fabric driver. Do not use the device tree to load the fabric driver! Heh, technically you can't use the device tree to load any device drivers, it's just a data structure. :-) You probably mean don't use the of_platform bus to load the fabric driver. He still needs to use the data in the device tree to decide what fabric drivers to use. of_platform_bus would be awkward to use for this because the node describing the fabric doesn't cleanly sit on any particular bus (ie. it describes the board; it does not describe the device). In this case; it probably is appropriate to have the platform code instantiate a platform_device for the fabric (instead of an of_platform device) which the fabric driver can bind against. Another option is to explicitly call of_platform_device_create in the platform code on the fabric node (which should be a child of the root node) so that you can have an of_platform_bus fabric driver. Cheers, g. The layout of the hardware and the relationship between the I2S, I2C, codec, and whatever device is determined by *both* the fabric driver and the device tree. The information about the devices itself, and *some* information about their relationship is stored in the device tree. Everything else is in the fabric driver. The design of the device tree is already locked in stone, so to speak. The DT can only store what it is allowed to store. If there's something more that you need, you'll have to put it in the fabric driver. If I weren't on vacation this week, I'd email you my code. It's almost done and it demonstrates what I'm thinking. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- 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: Revisited, audio codec device tree entries.
On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: In the ALSA SOC model the i2s, codec and ac97 drivers are all generic. A fabric driver tells specifically how a generic codec is wired into the board. What I haven't been able figure out is how to load the right fabric driver. Do not use the device tree to load the fabric driver! If I have a multiplatform kernel with 10 fabric drivers built in, how do you decide which one to activate without looking at the device tree? Multiplatform kernels are what is causing this problem. If the kernel is just for a single platform I can hardwire the fabric driver in without looking at the tree. The layout of the hardware and the relationship between the I2S, I2C, codec, and whatever device is determined by *both* the fabric driver and the device tree. The information about the devices itself, and *some* information about their relationship is stored in the device tree. Everything else is in the fabric driver. The design of the device tree is already locked in stone, so to speak. The DT can only store what it is allowed to store. If there's something more that you need, you'll have to put it in the fabric driver. If I weren't on vacation this week, I'd email you my code. It's almost done and it demonstrates what I'm thinking. -- Timur Tabi Linux Kernel Developer @ Freescale -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
David Gibson wrote: On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote: Gah! For the benefit of others on this list who may be misled. *Neither* of you correctly understands the device tree, what I've seen of *both* your suggested approaches is crap. The device tree describes the _hardware_. If you start reasoning about how to lay out the device tree based on your driver model, you're already wrong. Matt, the various properties you list do not mean what you think they mean. No, David, I understand exactly what they mean, in the context of a guy who works on Open Firmware, real Open Firmware, as was standardised 12 years ago. Not your whacky newspeak device trees, which to be fair, are a good idea, but it seems you all have tried to change something for the sake of changing something. name - should be named according to the generic names convention. It's pretty much arbitrary, meant for human readability of the device tree. Drivers should not depend on it (some do, historically, but new drivers and trees should not). I never said drivers should depend on it but why do you want to name an i2s bus as i2s or the i2c bus as i2c? There are far, far more descriptive names that can be used. i2s is basically audio, so why not audio or sound or headphone? Why is gpt a gpt and not a timer, it defeats the whole object of having a name for it. Since drivers never switch on it, why not give them real names? device_type - indicates the open firmware method interface for the device. Therefore, meaningless in flattened trees. No new driver should use this. .. you seem to think you must only design for the guys making Linux flattened device trees. I'm sorry, but I am not one of those guys and I am much more concerned with how this will affect the OF device tree and the usage for anyone else. Meaningless in flattened device trees, but useful information in real OF device trees, do you implement it or not? I'd say, yes. Even if you don't agree with real firmware, you can't just ignore it, shrug it away and say it doesn't matter. Jon's fabric driver should be looking for digispeaker,flinger and nothing else. The name doesn't matter but I called it sound because it's far, FAR more descriptive than i2s, and of course both the device_type and compatible properties report exactly what Jon will need to write a driver which handles, however that might be, his audio codec subsystem - pcm, control, magic gpios, or whatever. If there is an Open Firmware standard for it, I would use that name, then it gives everyone a rough idea of what to expect. Open Firmware developers can then CHOOSE TO IMPLEMENT THE STANDARD METHODS, and Linux device tree authors can just ignore it. You are cutting out a working specification for the sake of some arbitrary simplification. compatible - *this* is the one for driver selection. It describes the hardware level interface(s) of the device. Compatible is meant to list alternative, compatible devices as a *supplement* to device_type. device_type is your primary and compatible is your secondary. In this case, device_type is exactly what Jon wants, something to mark out that the audio device is his board design and requires special work (it is not merely an i2s bus that you can just use - although throwing PCM data at it would work, who knows what mixer it goes to, and what controls are needed to define the bitrate or other features) model - usually just for debugging / diagnosis / human-readable purposes, describes exact model / revision of the hardware. It can be used to enable driver quirks / workarounds for when various devices are supposed to be compatible (as encoded in 'compatible') but aren't, due to hardware bugs. However, you should never aim to use it this way in design. I don't see why model can't encode the particular revision of the hardware in this way when it comes to the audio group of features on his board. After all, if you are looking at a digispeaker,flinger (I made that name up) then you need to know depending on the board or even based on weird configurability options of the board, what certain things may be - Apple used layout-id and a number. Why NOT encode the model in the model? Why choose some magical, new property, which then has to be further standardised for no reason? I also think that specifying an audio codec - after all the Open Firmware standard defines an audio interface and device tree requirements for it, even if they are methods that we don't implement and you don't care about - as a function of it's control interface is so backwards it doesn't bare thinking about. If you want to output audio you do it through most audio controllers as a simple transfer of PCM data. Be it Creative or Freescale I2S or AC97, you push data at some port/fifo and it plays a sound. It is NOT defined by i2c control ports, you don't ever use those to *play* audio. It may also be very, very true that a codec DOES NOT REQUIRE
Re: Revisited, audio codec device tree entries.
On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote: On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: In the ALSA SOC model the i2s, codec and ac97 drivers are all generic. A fabric driver tells specifically how a generic codec is wired into the board. What I haven't been able figure out is how to load the right fabric driver. Do not use the device tree to load the fabric driver! Heh, technically you can't use the device tree to load any device drivers, it's just a data structure. :-) You probably mean don't use the of_platform bus to load the fabric driver. He still needs to use the data in the device tree to decide what fabric drivers to use. of_platform_bus would be awkward to use for this because the node describing the fabric doesn't cleanly sit on any particular bus (ie. it describes the board; it does not describe the device). In this case; it probably is appropriate to have the platform code instantiate a platform_device for the fabric (instead of an of_platform device) which the fabric driver can bind against. First, I have platform bus turned off in my builds. Platform bus is a place where cruft accumulates that really belongs somewhere else. For example when I turned it off I discovered that there was a PC speaker driver in my kernel and well as several drivers from 82xx chips. ALSA creates it own bus like i2c. My fabric driver sits on this bus., Kconfig attributes control if it is built-in. I've altered the i2c code to look for child device tree nodes and then load the appropriate drivers. Can't you then instantiate the ALSA bus device in your board platform code? Then when the driver is registered, the bus should call it's probe routine. 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: Revisited, audio codec device tree entries.
On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote: Grant Likely wrote: You probably mean don't use the of_platform bus to load the fabric driver. Yes, that is what I meant. He still needs to use the data in the device tree to decide what fabric drivers to use. I'm not sure about that. The fabric driver is tied to the platform itself, mostly because the fabric driver isn't really a device driver. It's a platform driver, in that its job is to initialize the other device drivers, or make sure the kernel initializes them. It's also responsible for telling ALSA which driver does what and how they're connected. With the current version of ASoC (V1), I don't think it's possible to have an independent platform driver. V2 is in development, but it's not ready yet and I haven't had a chance to study it. V2 is intended to address the problems that a device tree model raises. I'm using the v2 code. The v2 code is modeled after the i2c bus code which is the correct way to do drivers for open firmware. v1 creates asoc core as a platform device which was completely wrong since it is a driver core, not a device. That is fixed in v2 where it initializes with a subsysinit() call and then creates a bus. The whole driver organization of v2 is superior to v1. Open firmware support was the main motivation behind v2. In this case; it probably is appropriate to have the platform code instantiate a platform_device for the fabric (instead of an of_platform device) which the fabric driver can bind against. Another option is to explicitly call of_platform_device_create in the platform code on the fabric node (which should be a child of the root node) so that you can have an of_platform_bus fabric driver. I don't fully understand platform drivers. Do we really need a full-blown OF platform driver for this? -- Timur Tabi Linux Kernel Developer @ Freescale -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
Segher Boessenkool wrote:
And I forgot the rant you guys usually get - for god's sake, why isn't
anyone using the model property?
Probably because it isn't useful all that often.
[EMAIL PROTECTED] {
\\ this is our magic audio fabric
device_type = digispeaker,flinger;
This is wrong in so many ways; see David's mail for a start.
Why? I'm sorry but I am living in the real world where we have real
firmwares and real dynamic device trees here. You can't just say
this is wrong because it has a device_type.
\\ and this defines the layout Jon picked for the DACs
\\ just like Apple's layout-id value
model = flinger,2
flinger is some company that sells something they call the 2?
Interesting.
No, but who cares of the format of the model? It's for information -
in this case it's just there so that Jon can find out what layout
his codec, control interface, GPIOs, ports on the board, mixer
names, what colour the sky was on that day in June when he met his
wife-to-be, the name of his first dog, whatever information he needs
to implement on ANY driver model on ANY operating system is on that
particular version.
Maybe it should be digispeaker,2 or digispeaker,666 - who cares?
It's for the driver to know what it means.
I suggest it because I think Apple's layout-id is cryptic and
ridiculous duplication. Jon suggested to me a couple days back
that the layout-id is so model-specific (it increments each time
they brought out a new board, so it is synchronised with the
root model property!) that it's redundant. He suggested using
the root model property to switch his driver on the layout.
In this scenario, why not use the model property to keep the
audio driver more self-contained here? That was the theory
behind it.
model should be the real-world exact model name/number of the device.
Well, on this example, it's quite obvious it's an MPC5200B I2S bus,
but you're not describing solely the i2s bus (although in the
example it will operate with a standard mpc5200b-psc-i2s driver)
but the entire audio solution and indirectly how to program that
audio solution (ta-da!) - i2s bus, pcm codec, it's control interface,
and anything else besides, which is...
Isn't the primary concern of an audio codec, to play audio?
And the primary purpose of the device tree is to describe the hardware,
and (indirectly) how to program it.
.. exactly what it does.
For an audio codec that has I2C and I2S connections, the interface
over which you program it is I2C.
What if you don't connect I2C to something Linux can access directly?
There are other technicalities, too; for example, if the codec node
would be a child node of the I2S bus, you cannot have two codecs with
the same name on one such bus (since that bus isn't a bus really,
it's more like a broadcast interface; it cannot address separate devices
on that bus, so in the device tree the codecs wouldn't get a reg,
etc.)
*shrug* as an example..
Therefore, shouldn't the audio codec point back to it's control
interface?
No. The codec node _is_ the control interface.
I think that flies in the face of the implementation of a bunch of
codecs.
Also, why give the name as 'i2s-handle'?
Why not?
Surely it could be any interface.
No it cannot; this property is only present for audio codecs that have
an I2S bus (and not even all those, it is dependent on the device binding
in use).
See below.
In reverse, it would be, perhaps, as
above, i2c-handle, but then what if you change the interface
type (for instance a bunch of Wolfson codecs can do i2c and
spi for control). Your property name is obselete, then and
drivers will need to switch on property names to find out
which control interface is present.
That's another great argument against doing as you suggest, yes.
Why? The i2s codec sits on the i2s bus. You're right there is no
addressing on i2s it just has a stream of auduo going through it.
The i2s bus is one thing. This defines a PCM transport. This is
standardised.
The codec node defines which PCM/DAC you have on the end. This
DAC may have certain features - it may only have certain sample
rates supported, or may only support certain clock speeds. This
is what the codec node under the bus is for.
The codec node references the package handle of it's control
interface. If you want to play audio - well, go ahead, stream
some audio to the i2s bus, based on the abilities of the codec
(which are well defined in the datasheet you'd hope). You may
even use the OF standard properties for a sound node to define
these too - after all, it has a binding already and it would
improve driver support.
If you want to fiddle with it you need control interface, but
the primary purpose of an *audio device* is to play audio.
It is not to switch mixers on and off and change bass boost, that
is a totally secondary feature of an audio output or input
device, which may not even be present.
What they should really do, is be told
Re: Revisited, audio codec device tree entries.
On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote: On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote: On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: In the ALSA SOC model the i2s, codec and ac97 drivers are all generic. A fabric driver tells specifically how a generic codec is wired into the board. What I haven't been able figure out is how to load the right fabric driver. Do not use the device tree to load the fabric driver! Heh, technically you can't use the device tree to load any device drivers, it's just a data structure. :-) You probably mean don't use the of_platform bus to load the fabric driver. He still needs to use the data in the device tree to decide what fabric drivers to use. of_platform_bus would be awkward to use for this because the node describing the fabric doesn't cleanly sit on any particular bus (ie. it describes the board; it does not describe the device). In this case; it probably is appropriate to have the platform code instantiate a platform_device for the fabric (instead of an of_platform device) which the fabric driver can bind against. First, I have platform bus turned off in my builds. Platform bus is a place where cruft accumulates that really belongs somewhere else. For example when I turned it off I discovered that there was a PC speaker driver in my kernel and well as several drivers from 82xx chips. ALSA creates it own bus like i2c. My fabric driver sits on this bus., Kconfig attributes control if it is built-in. I've altered the i2c code to look for child device tree nodes and then load the appropriate drivers. Can't you then instantiate the ALSA bus device in your board platform code? Then when the driver is registered, the bus should call it's probe routine. Yes, I can do that. I have just been resisting creating a code linkage from arch/powerpc/platform/xx to sound/alsa/soc/powerpc. I also need to create the fabric driver after alsa has made the bus, subsys_initcall(asoc_bus_init); Hmmm, you could add a drivers_initcall to the platform code, but that only works if the ALSA code is compiled statically. It doesn't work for modules. :-( You might be stuck with using either a platform_device or an of_platform_device as a stepping stone to creating the device on the ALSA fabric driver. 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: Revisited, audio codec device tree entries.
On Mon, Nov 19, 2007 at 04:31:57PM +, Matt Sealey wrote: I never said drivers should depend on it but why do you want to name an i2s bus as i2s or the i2c bus as i2c? Because that's what they are? There are far, far more descriptive names that can be used. i2s is basically audio, so why not audio or sound or headphone? For i2s, that may be reasonable, but i2c can have several devices under it. Why is gpt a gpt and not a timer, it defeats the whole object of having a name for it. Since drivers never switch on it, why not give them real names? That one *should* be timer. Ask whoever did the device tree for it. :-P device_type - indicates the open firmware method interface for the device. Therefore, meaningless in flattened trees. No new driver should use this. .. you seem to think you must only design for the guys making Linux flattened device trees. I'm sorry, but I am not one of those guys and I am much more concerned with how this will affect the OF device tree and the usage for anyone else. Meaningless in flattened device trees, but useful information in real OF device trees, do you implement it or not? I'd say, yes. Yes, if you have real OF and provide the corresponding method interface. That doesn't mean the driver should match on it if it doesn't depend on the method interface. compatible - *this* is the one for driver selection. It describes the hardware level interface(s) of the device. Compatible is meant to list alternative, compatible devices as a *supplement* to device_type. device_type is your primary and compatible is your secondary. No, please read the spec: “compatible” Standard property name to define alternate “name” property values. No mention of device_type anywhere in the definition. The generic names recommendation further suggests that compatible always be used for matching. I don't see why model can't encode the particular revision of the hardware in this way when it comes to the audio group of features on his board. After all, if you are looking at a digispeaker,flinger (I made that name up) then you need to know depending on the board or even based on weird configurability options of the board, what certain things may be - Apple used layout-id and a number. Why NOT encode the model in the model? Why choose some magical, new property, which then has to be further standardised for no reason? compatible is not a magical, new property. I'm not going to defend what Apple did... I also think that specifying an audio codec - after all the Open Firmware standard defines an audio interface and device tree requirements for it, even if they are methods that we don't implement and you don't care about - as a function of it's control interface is so backwards it doesn't bare thinking about. It's how the device tree works. Devices go underneath the bus (or other attachment interface) that they're on. If you have an audio codec that has an i2c interface and an soc interface, then you have two nodes, because you're on two buses. If you want to output audio you do it through most audio controllers as a simple transfer of PCM data. Be it Creative or Freescale I2S or AC97, you push data at some port/fifo and it plays a sound. It is NOT defined by i2c control ports, you don't ever use those to *play* audio. You certainly do use the i2c ports in order to do anything with the device underneath the i2c bus. It may also be very, very true that a codec DOES NOT REQUIRE implementation of it's control interface, or that control interface could be connected to some other chip which handles initial configuration (like a boot sequencer eeprom) and not to a system bus. Sure... in that case, then that's *not the bus it's on*. There's still some register set somewhere that software uses to shove data at the codec; that's where the node should go. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote: On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote: On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: In the ALSA SOC model the i2s, codec and ac97 drivers are all generic. A fabric driver tells specifically how a generic codec is wired into the board. What I haven't been able figure out is how to load the right fabric driver. Do not use the device tree to load the fabric driver! Heh, technically you can't use the device tree to load any device drivers, it's just a data structure. :-) You probably mean don't use the of_platform bus to load the fabric driver. He still needs to use the data in the device tree to decide what fabric drivers to use. of_platform_bus would be awkward to use for this because the node describing the fabric doesn't cleanly sit on any particular bus (ie. it describes the board; it does not describe the device). In this case; it probably is appropriate to have the platform code instantiate a platform_device for the fabric (instead of an of_platform device) which the fabric driver can bind against. First, I have platform bus turned off in my builds. Platform bus is a place where cruft accumulates that really belongs somewhere else. For example when I turned it off I discovered that there was a PC speaker driver in my kernel and well as several drivers from 82xx chips. ALSA creates it own bus like i2c. My fabric driver sits on this bus., Kconfig attributes control if it is built-in. I've altered the i2c code to look for child device tree nodes and then load the appropriate drivers. Can't you then instantiate the ALSA bus device in your board platform code? Then when the driver is registered, the bus should call it's probe routine. Yes, I can do that. I have just been resisting creating a code linkage from arch/powerpc/platform/xx to sound/alsa/soc/powerpc. I also need to create the fabric driver after alsa has made the bus, subsys_initcall(asoc_bus_init); Hmmm, you could add a drivers_initcall to the platform code, but that only works if the ALSA code is compiled statically. It doesn't work for modules. :-( You might be stuck with using either a platform_device or an of_platform_device as a stepping stone to creating the device on the ALSA fabric driver. I also concluded that I need a of_platform stepping stone. There are several ways this could be done, which one is the right one? a) fabric is global, create a global device node for it and implement it as a of_platform device b) fabric is per audio bus, make it an attribute or child node under i2s, ac97, spi. This is messy since it can appear in many places. This is the apple layout-id scheme. c) fabric is per codec entry. make it an attribute or child node under the codec node. d) after I load the codec node, walk up the device tree to the root node and then use the compatible string in the root node to trigger the specific fabric driver. This one avoids making obviously redundant attributes down lower in the tree. I need things to initialize in this order. All of these can be modules. 1) alsa subsystem 2) i2c ac97 bus 3) codec driver 4) fabric - it then glues everything together in alsa. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote: On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: You might be stuck with using either a platform_device or an of_platform_device as a stepping stone to creating the device on the ALSA fabric driver. I also concluded that I need a of_platform stepping stone. There are several ways this could be done, which one is the right one? a) fabric is global, create a global device node for it and implement it as a of_platform device This is really board level description stuff. I'd make the node global off the root myself and use whatever linkage you think appropriate to get you to the codec nodes (phandle's most likely) 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: Revisited, audio codec device tree entries.
Jon Smirl wrote: Now how do I pick which fabric driver to initialize? I'm doing it via a Kconfig option. For ASoC V1, I think that's the only way that works. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: Now how do I pick which fabric driver to initialize? I'm doing it via a Kconfig option. For ASoC V1, I think that's the only way that works. I believe that is your only choice on v1. V1 is not set up to correctly handle for device trees. It is fixed in v2 except for the problem with how to load the fabric; no one has address that problem yet. The sound portion of the code is pretty much the same between v1 and v2, it is all the driver setup code that has been reworked. -- Timur Tabi Linux Kernel Developer @ Freescale -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On Mon, Nov 19, 2007 at 04:31:57PM +, Matt Sealey wrote: David Gibson wrote: On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote: Gah! For the benefit of others on this list who may be misled. *Neither* of you correctly understands the device tree, what I've seen of *both* your suggested approaches is crap. The device tree describes the _hardware_. If you start reasoning about how to lay out the device tree based on your driver model, you're already wrong. Matt, the various properties you list do not mean what you think they mean. No, David, I understand exactly what they mean, in the context of a guy who works on Open Firmware, real Open Firmware, as was standardised 12 years ago. No, you really don't. Either your knowledge of OF is out of date, or you've forgotten what you thought you knew. Not your whacky newspeak device trees, which to be fair, are a good idea, but it seems you all have tried to change something for the sake of changing something. With a couple of tiny exceptions, everything I've said applies equally to real OF trees. [snip] device_type - indicates the open firmware method interface for the device. Therefore, meaningless in flattened trees. No new driver should use this. .. you seem to think you must only design for the guys making Linux flattened device trees. I'm sorry, but I am not one of those guys and I am much more concerned with how this will affect the OF device tree and the usage for anyone else. No, which is exactly why it's wrong to organize the device tree so that it's convenient for loading this fabric driver thing (which AFAICT is a Linux-specific driver model limitation). Meaningless in flattened device trees, but useful information in real OF device trees, do you implement it or not? I'd say, yes. Even if you don't agree with real firmware, you can't just ignore it, shrug it away and say it doesn't matter. Useful information in a real OF tree *if* an OF runtime interface for the device is defined and implemented. [snip] compatible - *this* is the one for driver selection. It describes the hardware level interface(s) of the device. Compatible is meant to list alternative, compatible devices as a *supplement* to device_type. device_type is your primary and compatible is your secondary. In this case, device_type is exactly what Jon wants, something to mark out that the audio device is his board design and requires special work (it is not merely an i2s bus that you can just use - although throwing PCM data at it would work, who knows what mixer it goes to, and what controls are needed to define the bitrate or other features) No, as Segher explains, that's Just Plain Wrong. Originally name did perform the function you think device_type had. But the generic names convention, which has been very well established for a long time now means that the register-level (or equivalent) programming interface is described by compatible. Period. model - usually just for debugging / diagnosis / human-readable purposes, describes exact model / revision of the hardware. It can be used to enable driver quirks / workarounds for when various devices are supposed to be compatible (as encoded in 'compatible') but aren't, due to hardware bugs. However, you should never aim to use it this way in design. I don't see why model can't encode the particular revision of the hardware in this way when it comes to the audio group of features on his board. After all, if you are looking at a digispeaker,flinger (I made that name up) then you need to know depending on the board or even based on weird configurability options of the board, what certain things may be - Apple used layout-id and a number. Why NOT encode the model in the model? Why choose some magical, new property, which then has to be further standardised for no reason? I also think that specifying an audio codec - after all the Open Firmware standard defines an audio interface and device tree requirements for it, even if they are methods that we don't implement and you don't care about - as a function of it's control interface is so backwards it doesn't bare thinking about. Sure, it's fine for a firmware to implement the OF method interface and put in the relevant device_type for audio in the appropriate place (although with complex sound systems with many components, the right place may be non-obvious or even not well defined). It's *not* fine to make up random new device_type values because you think it's convenient. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On Mon, Nov 19, 2007 at 04:58:44PM +, Matt Sealey wrote:
Segher Boessenkool wrote:
And I forgot the rant you guys usually get - for god's sake, why isn't
anyone using the model property?
Probably because it isn't useful all that often.
[EMAIL PROTECTED] {
\\ this is our magic audio fabric
device_type = digispeaker,flinger;
This is wrong in so many ways; see David's mail for a start.
Why? I'm sorry but I am living in the real world where we have real
firmwares and real dynamic device trees here. You can't just say
this is wrong because it has a device_type.
It's not wrong because it has a device_type, it's wrong because the
device_type value is some random made-up thing that doesn't have an OF
binding behind it. Nor do you suggest an OF binding. Nor should
driver selection be based off device_type.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On Mon, Nov 19, 2007 at 01:48:40PM +0100, Segher Boessenkool wrote: Matt, the various properties you list do not mean what you think they mean. name - should be named according to the generic names convention. It's pretty much arbitrary, meant for human readability of the device tree. Drivers should not depend on it (some do, historically, but new drivers and trees should not). It is not arbitrary, there is a single well-defined name for every common class of device. It _is_ machine-readable (but shouldn't be used for driver matching, indeed -- it says nothing about the programming model). Sorry, that was an (over?) simplification on my part. Yes, there are conventions as to what devices should be called by class (usually, but not universally observed), yes they can be used machine-readable under some circumstances. My point is that since driver matching is *not* done off name, and machine-readable uses are not common, the name tends not to matter very much. Plus if an incorrect name is used, it's usually not too bad to fix. device_type - indicates the open firmware method interface for the device. Not method interface, just interface. Right, I say method interface just to emphasise the fact that we're talking about the runtime OF-call interface, rather than register-level or other programming interface. Therefore, meaningless in flattened trees. Even in flat trees, a device_type of for example block indicates the node will have the required properties for that device type, for example block-size. Such properties are perfectly useful. OTOH, it isn't very useful to search for device with a specific device type from within the kernel, since it currently has no firmware interaction to speak of (flat trees don't interact, and the kernel kills real OF dead as soon as possible). Uh... it was you who convinced me that device_type was not appropriate for new flat-tree devices. No new driver should use this. Not without very good rationalisation, anyway. compatible - *this* is the one for driver selection. It describes the hardware level interface(s) of the device. model - usually just for debugging / diagnosis / human-readable purposes, describes exact model / revision of the hardware. It can be used to enable driver quirks / workarounds for when various devices are supposed to be compatible (as encoded in 'compatible') but aren't, due to hardware bugs. However, you should never aim to use it this way in design. Yeah. Any non-workaround value a driver would derive from model is usually better described using a separate property. Well, yes, if the need for the workaround is known when the device tree is created. But by their nature workarounds tend not to be planned, so from the driver's perspective it's legitimate to use *any* reliable-in-practice information to activate a workaround (even if it's not reliable in theory, if there's no other option). That includes both everything in the device tree, and any information the driver can probe from the hardware. My point above is that iIt's reasonably common in such cases for model to be a decent choice. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On Mon, Nov 19, 2007 at 12:28:02PM -0700, Grant Likely wrote: On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote: On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: You might be stuck with using either a platform_device or an of_platform_device as a stepping stone to creating the device on the ALSA fabric driver. I also concluded that I need a of_platform stepping stone. There are several ways this could be done, which one is the right one? a) fabric is global, create a global device node for it and implement it as a of_platform device This is really board level description stuff. I'd make the node global off the root myself and use whatever linkage you think appropriate to get you to the codec nodes (phandle's most likely) No. I think this is the whole damn point we've been spiralling around. An of_platform device is appropriate *only* if there is an OF node for the device. There should be an OF node for the device only if it it really is a well-defined hardware component which implements it. As far as I can understand, the fabric driver is really just a catchall to cover whatever various interconnections there are between audio components on the board. Those interconnections could (and probably should) be described in the OF tree. But that description would be to describe each of those interconnections individually e.g. codecs have links to sound PHY devices (speakers) or whatever, codecs, i2s AC97 and so forth devices have links between them appropriate to the type of device. Not as some imaginary fabric device. Therefore the fabric driver cannot be instantiated as an of_platfornm device. Therfore arch code will have to instantiate the fabric driver some other way. There are a couple of options here: 1) We have a universal device-tree-based fabric driver which parses all the above-described interconnection information in the device tree and handles any situation. Cool, but probably a lot of work and fiddly to get right. 2) Or, the platform code instantiates an appopriate fabric driver for the board (which will probably make assumptions about how things are interconnected). Platform code can optionally examine board level model properties or other device information to select the correct fabric driver and/or options. The fabric driver can optionally look at some parts of the device tree information to configure details of its operation. Option (2) is a hack, but it's a reasonably well-contained hack. It works for now, and doesn't preclude switching to option (1) later - without changes to the device tree, and on a board-by-board basis. It can also handle the (almost inevitable) case of device trees with missing or incorrect detailed audio interconnection information. The basic thing is that we have a mismatch between the Linux driver model and the device tree model. Rather than hacking the device tree to match the Linux model, we should provide whatever glue code is necessary to instantiate the necessary Linux drivers from the device tree information we have. This is, essentially, the exact purpose for which platform code exists. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Revisited, audio codec device tree entries.
I've been trying to write ALSA SOC code supporting audio codecs and
device trees.
This looks ok for the main device tree entires. Codecs are hung off
from their controlling bus. It may still need a little tweaking.
[EMAIL PROTECTED] { // PSC2
compatible = mpc5200b-psc-ac97,mpc5200-psc-ac97;
cell-index = 1;
reg = 2200 100;
interrupts = 2 2 0;
interrupt-parent = mpc5200_pic;
[EMAIL PROTECTED] {
compatible = idt,stac9766;
reg = 0;
};
};
[EMAIL PROTECTED] {
compatible = mpc5200b-i2c,mpc5200-i2c,fsl-i2c;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
[EMAIL PROTECTED] {
compatible = ti,tas5504;
reg = 15;
i2s-handle = [EMAIL PROTECTED];
};
};
[EMAIL PROTECTED] { // PSC4
compatible = mpc5200b-psc-i2s,mpc5200-psc-i2s;
cell-index = 1;
reg = 2400 100;
interrupts = 2 3 0;
interrupt-parent = mpc5200_pic;
};
In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
A fabric driver tells specifically how a generic codec is wired into
the board. What I haven't been able figure out is how to load the
right fabric driver.
It is starting to make more sense to me that fabric driver actually
does represent a physical device - the cluster of wires. David Gibson
made a proposal that a fabric node wrap the codec node. That doesn't
work very well with the i2c bus where the bus code is walking down the
nodes and triggering the instantiation of the i2c drivers.
But what about putting the fabric node inside the codec node?
[EMAIL PROTECTED] {
compatible = ti,tas5504;
reg = 15;
i2s-handle = [EMAIL PROTECTED];
codec-fabric {
compatible = digispeaker,fabric
};
};
[EMAIL PROTECTED] {
compatible = idt,stac9766;
reg = 0;
codec-fabric {
compatible = efika,fabric
};
};
This sort of makes sense, the ac97/i2c bus is connected to the codec,
which is then connected to the fabric.
The example used in the ALSA doc of an ac97 chip needing a fabric
driver was a case where the ac97 chip has an external amp. The fabric
driver uses a GPIO to turn the amp on/off with suspend/resume.
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
[EMAIL PROTECTED] { // PSC2
compatible = mpc5200b-psc-ac97,mpc5200-psc-ac97;
cell-index = 1;
reg = 2200 100;
interrupts = 2 2 0;
interrupt-parent = mpc5200_pic;
You need #address-cells, #size-cells here.
[EMAIL PROTECTED] {
compatible = idt,stac9766;
reg = 0;
};
};
[EMAIL PROTECTED] {
compatible = mpc5200b-i2c,mpc5200-i2c,fsl-i2c;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
And here.
[EMAIL PROTECTED] {
compatible = ti,tas5504;
reg = 15;
i2s-handle = [EMAIL PROTECTED];
Should use an alias here (or the full path, if that works).
};
};
[EMAIL PROTECTED] { // PSC4
compatible = mpc5200b-psc-i2s,mpc5200-psc-i2s;
cell-index = 1;
reg = 2400 100;
interrupts = 2 3 0;
interrupt-parent = mpc5200_pic;
};
In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
A fabric driver tells specifically how a generic codec is wired into
the board. What I haven't been able figure out is how to load the
right fabric driver.
Whatever way works for the platform.
It is starting to make more sense to me that fabric driver actually
does represent a physical device - the cluster of wires.
That's only part of it, as far as I understand.
David Gibson
made a proposal that a fabric node wrap the codec node. That doesn't
work very well with the i2c bus where the bus code is walking down the
nodes and triggering the instantiation of the i2c drivers.
Yeah, doesn't work at all.
But what about putting the fabric node inside the codec node?
_Which_ codec node? Having more than one isn't uncommon at all.
There is no way you can describe this fabric stuff in a generic way in
the device tree. Just hardcode it in your platform support code; if
the platform code supports several variant boards, _it_ can probe that
from the device tree (in whatever way works for that platform).
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On 11/18/07, Segher Boessenkool [EMAIL PROTECTED] wrote: David Gibson made a proposal that a fabric node wrap the codec node. That doesn't work very well with the i2c bus where the bus code is walking down the nodes and triggering the instantiation of the i2c drivers. Yeah, doesn't work at all. But what about putting the fabric node inside the codec node? _Which_ codec node? Having more than one isn't uncommon at all. In all of them. Fabric can probably be split into pieces that corresponds to the codec. There is no way you can describe this fabric stuff in a generic way in the device tree. Just hardcode it in your platform support code; if the platform code supports several variant boards, _it_ can probe that from the device tree (in whatever way works for that platform). The codec-fabric node was just being used to trigger the loading of the platform specific driver. Segher -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
Jon Smirl wrote: The codec-fabric node was just being used to trigger the loading of the platform specific driver. Just remember one thing. 1) the term fabric when coined for audio drivers is a new, ALSA SoC specific term. It isn't relevant for anything but ALSA SoC drivers. 2) this device tree stuff will end up in more than Linux device trees 3) you're going to piss off Open Firmware developers by specifying very Linux-specific features in a device tree the same way Apple pissed off Linux developers by encoding MacOS X-specific features in the device tree. Audio driver control like this has to be very specific for a good reason; you can do it a billion ways to Sunday. I'd suggest basically that if you must control a device in a way that needs to be defined by a device which can change address (either dynamically on boot or by board design change - per revision, for example, or with a change of controller) then simply use the device tree to report this address so that you can have the same basic fabric driver (all in Linux) which can handle minor modifications of your board design. If you require the codec to be subservient to some fabric then I suggest you make a sound node with a compatible entry which is defined as something specific to your board (digispeaker,audio) and let your driver pick that up and then switch on the model (rather like Apple's layout-id) of that device to pick out the specifics of that fabric. If it needs an audio codec (ac97 or i2s) and a control interface (i2c or spi) then it knows which ones it is looking for based on the model. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
Matt Sealey wrote:
Jon Smirl wrote:
If you require the codec to be subservient to some fabric then I
suggest you make a sound node with a compatible entry which is
defined as something specific to your board (digispeaker,audio) and
let your driver pick that up and then switch on the model (rather like
Apple's layout-id) of that device to pick out the specifics of that
fabric. If it needs an audio codec (ac97 or i2s) and a control
interface (i2c or spi) then it knows which ones it is looking for
based on the model.
Sigh, I suck, I forgot the example :D
And I forgot the rant you guys usually get - for god's sake, why isn't
anyone using the model property? Do I have to whine about this some
more to get your attention, guys? name, device_type, compatible and
model are your tools for building device trees and detecting
things. That's FOUR unique properties.
How come I only see device trees defined using name, with the same
device_type, and compatible? This is braindead design.
Why is every example device tree I see defining weird little extra
nodes for anything and everything that some driver API exposes? If
you want to expose a grand new kind of driver fabric like ALSA SoC
wants, put your codec in the tree, and give it a model property
with your unique name.
I'd suggest something like this:
[EMAIL PROTECTED] {
\\ this is our magic audio fabric
device_type = digispeaker,flinger;
\\ it's actually just an i2s pcm codec
compatible = mpc5200-psc-i2s;
\\ and this defines the layout Jon picked for the DACs
\\ just like Apple's layout-id value
model = flinger,2
[EMAIL PROTECTED] {
compatible = TXN,tas5504;
codec-control = codec-control;
}
\\ and every i2s driver on the planet will just ignore these
\\ unless it's one of our boards
digispeaker,amp-control = amp-control
}
Then you control the fabric for your boards and get to attach
whatever the hell you want to those codecs, control interfaces
and special little tweak features you always wanted.
Be careful cross-referencing devices with each other,
for instance in your example you made the i2c codec device
point back to an i2s handle - it's a good idea, but not well
executed in my opinion as it lacks context.
Isn't the primary concern of an audio codec, to play audio?
Therefore, shouldn't the audio codec point back to it's control
interface? Also, why give the name as 'i2s-handle'? Surely it
could be any interface. In reverse, it would be, perhaps, as
above, i2c-handle, but then what if you change the interface
type (for instance a bunch of Wolfson codecs can do i2c and
spi for control). Your property name is obselete, then and
drivers will need to switch on property names to find out
which control interface is present.
What they should really do, is be told where their control
interface handle is, then you can look at that handle and
the device it contains - that device itself will tell you the
bus type, any devices under it, and any quirky things you
need to do besides (above, codec-control etc. would point to
[EMAIL PROTECTED] {
[EMAIL PROTECTED] {
blah
}
}
[EMAIL PROTECTED] {
[EMAIL PROTECTED] {
blah
}
}
[EMAIL PROTECTED] {
[EMAIL PROTECTED] {
compatible = gpio-bit;
bit = 1;
open-drain;
}
}
If you couldn't tell it's a device on an i2c bus then you
are coding your driver badly. And you can have lots of
codecs, and just back reference which control interface
they have. I dunno.
Remember, it doesn't matter what NAME you give it, the name
is for people to read, device_type is what you search for,
and phandles let you attach specific devices to each other.
compatible is for when you want to tell people it acts the
same as this and model is to give you the enviable ability
to define PRECISELY what you are looking at beyond a chip
name. I'd suggest we use all of them for great justice.
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote: Matt Sealey wrote: Jon Smirl wrote: If you require the codec to be subservient to some fabric then I suggest you make a sound node with a compatible entry which is defined as something specific to your board (digispeaker,audio) and let your driver pick that up and then switch on the model (rather like Apple's layout-id) of that device to pick out the specifics of that fabric. If it needs an audio codec (ac97 or i2s) and a control interface (i2c or spi) then it knows which ones it is looking for based on the model. Sigh, I suck, I forgot the example :D And I forgot the rant you guys usually get - for god's sake, why isn't anyone using the model property? Do I have to whine about this some more to get your attention, guys? name, device_type, compatible and model are your tools for building device trees and detecting things. That's FOUR unique properties. How come I only see device trees defined using name, with the same device_type, and compatible? This is braindead design. Gah! For the benefit of others on this list who may be misled. *Neither* of you correctly understands the device tree, what I've seen of *both* your suggested approaches is crap. The device tree describes the _hardware_. If you start reasoning about how to lay out the device tree based on your driver model, you're already wrong. Matt, the various properties you list do not mean what you think they mean. name - should be named according to the generic names convention. It's pretty much arbitrary, meant for human readability of the device tree. Drivers should not depend on it (some do, historically, but new drivers and trees should not). device_type - indicates the open firmware method interface for the device. Therefore, meaningless in flattened trees. No new driver should use this. compatible - *this* is the one for driver selection. It describes the hardware level interface(s) of the device. model - usually just for debugging / diagnosis / human-readable purposes, describes exact model / revision of the hardware. It can be used to enable driver quirks / workarounds for when various devices are supposed to be compatible (as encoded in 'compatible') but aren't, due to hardware bugs. However, you should never aim to use it this way in design. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On 11/18/07, David Gibson [EMAIL PROTECTED] wrote: On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote: Matt Sealey wrote: Jon Smirl wrote: If you require the codec to be subservient to some fabric then I suggest you make a sound node with a compatible entry which is defined as something specific to your board (digispeaker,audio) and let your driver pick that up and then switch on the model (rather like Apple's layout-id) of that device to pick out the specifics of that fabric. If it needs an audio codec (ac97 or i2s) and a control interface (i2c or spi) then it knows which ones it is looking for based on the model. Sigh, I suck, I forgot the example :D And I forgot the rant you guys usually get - for god's sake, why isn't anyone using the model property? Do I have to whine about this some more to get your attention, guys? name, device_type, compatible and model are your tools for building device trees and detecting things. That's FOUR unique properties. How come I only see device trees defined using name, with the same device_type, and compatible? This is braindead design. Gah! For the benefit of others on this list who may be misled. *Neither* of you correctly understands the device tree, what I've seen of *both* your suggested approaches is crap. I'm awaiting guidance on how to do the device tree. I just want to figure out some way of getting my drivers loaded. I make no claim to having any expertise in device tree design. There are two classes of codecs, ones where control/data is combined and one where they are separate. Common examples - combined: ac97, hda - separate i2s + i2c. Then there is this fabric stuff which glues a generic codec driver into a specific board layout. While a generic AC97 design may not need a fabric driver, most other designs need it. If someone were to put an example into the Docmentation file, I'd follow it. The device tree describes the _hardware_. If you start reasoning about how to lay out the device tree based on your driver model, you're already wrong. Matt, the various properties you list do not mean what you think they mean. name - should be named according to the generic names convention. It's pretty much arbitrary, meant for human readability of the device tree. Drivers should not depend on it (some do, historically, but new drivers and trees should not). device_type - indicates the open firmware method interface for the device. Therefore, meaningless in flattened trees. No new driver should use this. compatible - *this* is the one for driver selection. It describes the hardware level interface(s) of the device. model - usually just for debugging / diagnosis / human-readable purposes, describes exact model / revision of the hardware. It can be used to enable driver quirks / workarounds for when various devices are supposed to be compatible (as encoded in 'compatible') but aren't, due to hardware bugs. However, you should never aim to use it this way in design. -- 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 [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
