Revisited, audio codec device tree entries.

Revisited, audio codec device tree entries.

[Jon Smirl]

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.

		ac97@2200 {		// PSC2
			compatible = "mpc5200b-psc-ac97","mpc5200-psc-ac97";
			cell-index = <1>;
			reg = <2200 100>;
			interrupts = <2 2 0>;
			interrupt-parent = <&mpc5200_pic>;
			codec@0 {
				compatible = "idt,stac9766";
				reg = <0>;
			};
		};

		i2c@3d40 {
			compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
			reg = <3d40 40>;
			interrupts = <2 10 0>;
			interrupt-parent = <&mpc5200_pic>;
			fsl5200-clocking;

			codec@15 {
				compatible = "ti,tas5504";
				reg = <15>;
				i2s-handle = <i2s@2400>;
			};
		};
		
		i2s@2400 {		// 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?

			codec@15 {
				compatible = "ti,tas5504";
				reg = <15>;
				i2s-handle = <i2s@2400>;
				codec-fabric {
					compatible = "digispeaker,fabric"
				};
			};

			codec@0 {
				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
jonsmirl@gmail.com

Re: Revisited, audio codec device tree entries.

[Segher Boessenkool]

> 		ac97@2200 {		// 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.

> 			codec@0 {
> 				compatible = "idt,stac9766";
> 				reg = <0>;
> 			};
> 		};
>
> 		i2c@3d40 {
> 			compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
> 			reg = <3d40 40>;
> 			interrupts = <2 10 0>;
> 			interrupt-parent = <&mpc5200_pic>;
> 			fsl5200-clocking;

And here.

> 			codec@15 {
> 				compatible = "ti,tas5504";
> 				reg = <15>;
> 				i2s-handle = <i2s@2400>;

Should use an alias here (or the full path, if that works).

> 			};
> 		};
> 		
> 		i2s@2400 {		// 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

Re: Revisited, audio codec device tree entries.

[Jon Smirl]

On 11/18/07, Segher Boessenkool <segher@kernel.crashing.org> 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
jonsmirl@gmail.com

Re: Revisited, audio codec device tree entries.

[Matt Sealey]

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 <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: Revisited, audio codec device tree entries.

[Matt Sealey]

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:

sound@0 {
	\\ 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"

	codec@15 {
		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

i2c@3d40 {
	codec-control@15 {
		blah
	}
}

spi@beef {
	codec-control@19 {
		blah
	}
}

gpio@cafe {
	amp-control@0 {
		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 <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: Revisited, audio codec device tree entries.

[Jon Smirl]

On 11/18/07, Matt Sealey <matt@genesi-usa.com> wrote:
> I'd suggest something like this:
>
> sound@0 {
>         \\ 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"
>
>         codec@15 {
>                 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>
> }


This forces a single fabric driver for audio buses that can support
more than one device (like ac97). I can live with that, but is it ok
for the design?


> 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.

Others have pointed out that device trees are organized by control
interface. So the codec node should be under i2c and back point to
their data stream. We could use something like codec-data instead of
i2s-handle.

I don't have a strong opinion on how to organize this stuff. I just
need some way to get the ASOC fabric drivers loaded. Actually ASOC
calls them 'machine' drivers, it is Apple's audio code that call them
fabric drivers.


>
> 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
>
> i2c@3d40 {
>         codec-control@15 {
>                 blah
>         }
> }
>
> spi@beef {
>         codec-control@19 {
>                 blah
>         }
> }
>
> gpio@cafe {
>         amp-control@0 {
>                 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 <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: Revisited, audio codec device tree entries.

[David Gibson]

On Sun, Nov 18, 2007 at 11:31:13PM +0000, 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

Re: Revisited, audio codec device tree entries.

[Jon Smirl]

On 11/18/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Sun, Nov 18, 2007 at 11:31:13PM +0000, 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
jonsmirl@gmail.com

Re: Revisited, audio codec device tree entries.

[Segher Boessenkool]

> 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

Re: Revisited, audio codec device tree entries.

[David Gibson]

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

Re: Revisited, audio codec device tree entries.

[Matt Sealey]

David Gibson wrote:
> On Sun, Nov 18, 2007 at 11:31:13PM +0000, 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 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.

Therefore, pcm audio codecs as subordinate of control interfaces
is a dumb idea. Nuff said, I think.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: Revisited, audio codec device tree entries.

[Scott Wood]

On Mon, Nov 19, 2007 at 04:31:57PM +0000, 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

Re: Revisited, audio codec device tree entries.

[Grant Likely]

On 11/19/07, Scott Wood <scottwood@freescale.com> wrote:
> On Mon, Nov 19, 2007 at 04:31:57PM +0000, 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

That one's my fault.

sorry.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Revisited, audio codec device tree entries.

[David Gibson]

On Mon, Nov 19, 2007 at 04:31:57PM +0000, Matt Sealey wrote:
> David Gibson wrote:
> > On Sun, Nov 18, 2007 at 11:31:13PM +0000, 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

Re: Revisited, audio codec device tree entries.

[Segher Boessenkool]

> 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.

> sound@0 {
> 	\\ 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

Re: Revisited, audio codec device tree entries.

[Matt Sealey]

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.
> 
>> sound@0 {
>>     \\ 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 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.

Sorry Segher but you argued against this last time we had this
discussion. You said that all device nodes should be self-contained
and looking elsewhere in the tree is ridiculous.

What if you have a chip which has an SPI control interface, and
uses a custom FIFO setup to stream audio? What do you use then,
i2s-handle? Ha ha ha. Don't encode bus names in properties. They
should be descriptive. i2s-handle would point to a node which
has a device_type (on real firmware) and compatible property which
gives you ALL the information you need to determine

>> 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; 

Then, no real Open Firmware implementation can work. What you need to
do, then is repeat the device_type information in the compatible
property on real firmwares. This is dumb. Stop sidelining real firmwares
for the sake of the Linux device tree.

> "compatible" is for that.

Why don't we propose a solution then? device_type is the type of
device you're looking at. This might be chrp,iic or it might be
fsl,i2c or it could be something else. Write this into your device
tree spec. This is important for real firmwares and other operating
systems which try and conform to IEEE 1275.

Then get your fdt blob builder and fix it so that it concatenates
the device_type value into the compatible property, and ditches
the device_type value for FDT's.

Don't start killing off part of the Open Firmware spec for the sake
of it. If you expect real Open Firmware developers to actually pay
attention to the Linux device tree specs it needs to take them into
account and not just run off on the justification that it was
"decided by the community so it's canon" - you need to design the
trees based on users of the technology.

> [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.

Hello, we license one, so we're concerned about this.

Last time we shipped a real Open Firmware itself, you were the biggest
opponent on getting the device tree checked and standardised. Now you
want to just remove features, I don't see how we should even care if
you're going to be like that, but you're forcing us to do your bidding
against better knowledge.

When you have your own firmware to play with you can do what you like
with it, you can remove the property..  and Linux can happily support
it, but we *really* need to support other systems here and defining
things in backwards Linux ways is bad.

>> 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.

It's hard to define a value which describes something human readable
yet being simple to parse by a machine. Remember the whole justification
for XML? I don't think "model" (or by that regard, name, device_type
or compatible) *MUST* be human readable, but where and if it can be,
it should be.

name = some pretty name to differentiate it from something else in
the device tree. Not searchable, but just pretty in the output of
'.properties'

device_type = primary driver switch to look for the device, since it's
part of the OF spec, we have to implement it on our firmware. you
needn't in FDTs, but, please help us out on this.

compatible = if you don't find it in device_type, look here. I don't
think it should need to repeat device_type on real OF implementations.

model = you found the driver but you're concerned about some very
exact functionality which may not be present or software-detectable,
so you encode it here. Be that the SVR, be that the full part number
lasered into the die of the chip, be it mpc5200b,1.4 - this is up
to the guy who designed the hardware and the driver SHOULD be able
to use it AT IT'S OPTION to handle certain quirks, layout issues or
bugs in the device.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: Revisited, audio codec device tree entries.

[David Gibson]

On Mon, Nov 19, 2007 at 04:58:44PM +0000, 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.
> > 
> >> sound@0 {
> >>     \\ 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

Re: Revisited, audio codec device tree entries.

[Timur Tabi]

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

Re: Revisited, audio codec device tree entries.

[Jon Smirl]

On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> 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".

ALSA is using the term fabric in the aoa directory, and the term
'machine' in the soc directory.  They both mean the same thing, but it
is very confusing to call this a machine driver when we are talking
about device trees. Once everything gets settled the aoa code should
be merged into the soc code, it is almost identical in architecture.

>
> > 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
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: Revisited, audio codec device tree entries.

[Timur Tabi]

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

Re: Revisited, audio codec device tree entries.

[Jon Loeliger]

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

Re: Revisited, audio codec device tree entries.

[Grant Likely]

On 11/19/07, Timur Tabi <timur@freescale.com> 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.
grant.likely@secretlab.ca
(403) 399-0195

Re: Revisited, audio codec device tree entries.

[Jon Smirl]

On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/19/07, Timur Tabi <timur@freescale.com> 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.

static void of_register_i2c_devices(struct i2c_adapter *adap, struct
device_node *adap_node)
{
	struct device_node *node = NULL;

	while ((node = of_get_next_child(adap_node, node))) {
		struct i2c_board_info info;
		const u32 *addr;
		const char *compatible;
		int len;

		addr = of_get_property(node, "reg", &len);
		if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
			printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing reg attribute\n");
			continue;
		}

		info.irq = irq_of_parse_and_map(node, 0);
		if (info.irq == NO_IRQ)
			info.irq = -1;

		compatible = of_get_property(node, "compatible", &len);
		if (!compatible) {
			printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing compatible
attribute\n");
			continue;
		}
		strncpy(info.driver_name, compatible, sizeof(info.driver_name));
		info.type[0] = '\0';

		info.platform_data = NULL;
		info.addr = *addr;
		
		i2c_new_device(adap, &info);
	}
}

I have a similar loop in the ac97 driver for loading codecs it controls.

So now I'm at this point:
i2c bus driver loaded, initialized from of
i2s bus driver loaded, initialized from of
tas5504 codec loaded onto i2c, initialized from i2c loop above
multiple fabric drivers loaded onto the alsa bus

Now how do I pick which fabric driver to initialize?

Codec and i2s are also attached to alsa bus.




>
> 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.
> grant.likely@secretlab.ca
> (403) 399-0195
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: Revisited, audio codec device tree entries.

[Grant Likely]

On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 11/19/07, Timur Tabi <timur@freescale.com> 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.
grant.likely@secretlab.ca
(403) 399-0195

Re: Revisited, audio codec device tree entries.

[Jon Smirl]

On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > On 11/19/07, Timur Tabi <timur@freescale.com> 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);

> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: Revisited, audio codec device tree entries.

[Grant Likely]

On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > On 11/19/07, Timur Tabi <timur@freescale.com> 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.
grant.likely@secretlab.ca
(403) 399-0195

Re: Revisited, audio codec device tree entries.

[Jon Smirl]

On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > > On 11/19/07, Timur Tabi <timur@freescale.com> 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
jonsmirl@gmail.com

Re: Revisited, audio codec device tree entries.

[Grant Likely]

On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/19/07, Grant Likely <grant.likely@secretlab.ca> 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.
grant.likely@secretlab.ca
(403) 399-0195

Re: Revisited, audio codec device tree entries.

[David Gibson]

On Mon, Nov 19, 2007 at 12:28:02PM -0700, Grant Likely wrote:
> On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> 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

Re: Revisited, audio codec device tree entries.

[Timur Tabi]

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

Re: Revisited, audio codec device tree entries.

[Jon Smirl]

On 11/26/07, Timur Tabi <timur@freescale.com> 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
jonsmirl@gmail.com

Re: Revisited, audio codec device tree entries.

[Timur Tabi]

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

Re: Revisited, audio codec device tree entries.

[Timur Tabi]

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

Re: Revisited, audio codec device tree entries.

[Jon Smirl]

On 11/19/07, Timur Tabi <timur@freescale.com> 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
jonsmirl@gmail.com

Re: Revisited, audio codec device tree entries.

[Timur Tabi]

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.

> 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

Re: Revisited, audio codec device tree entries.

[Grant Likely]

On 11/19/07, Timur Tabi <timur@freescale.com> 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.
>

Even it it's just based on the board "model" property; that's still
deciding what the ALSA fabric is based on data in the device tree.
:-)

> > 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?

Both the platform bus and the of_platform bus do exactly the same
thing in a simple manner.  They allow devices to be matched with
drivers.  It is a low overhead mechanism.

In both cases, devices carry with them some metadata to describe the
devices.  For platform devices, that meta data is a resource structure
and a device specific pdata structure.  For of_platform devices, the
metadata is a pointer to a device tree node.

That's it.  Using either mechanism allows the platform code to say
"these devices are present" without having to explicitly call routines
into the driver.  In other words; it can provide late binding of
drivers to devices.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Revisited, audio codec device tree entries.

[Jon Smirl]

On 11/19/07, Timur Tabi <timur@freescale.com> 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
jonsmirl@gmail.com

Re: Revisited, audio codec device tree entries.

[Jon Smirl]

On 11/19/07, Timur Tabi <timur@freescale.com> 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
jonsmirl@gmail.com

Re: Revisited, audio codec device tree entries.

[Grant Likely]

On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/19/07, Timur Tabi <timur@freescale.com> 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.

Simple; instantiate the needed platform_device or of_platform_device
in the board platform code (arch/powerpc/platforms/*).  Then the
driver has something to bind against.

That way the driver's probe() method gets called without having to
traverse the entire tree.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195