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
On 11/26/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> David Gibson wrote:
>
> > 1) We have a "universal" device-tree-based fabric driver which
> > parses all the above-described interconnection information in the
> > device tree and handles any situation. Cool, but probably a lot of
> > work
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
On Mon, Nov 19, 2007 at 04:58:44PM +, Matt Sealey wrote:
> Segher Boessenkool wrote:
> >> And I forgot the rant you guys usually get - for god's sake, why isn't
> >> anyone using the "model" property?
> >
> > Probably because it isn't useful all that often.
> >
> >> [EMAIL PROTECTED] {
> >>
On Mon, Nov 19, 2007 at 04:31:57PM +, Matt Sealey wrote:
> David Gibson wrote:
> > On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote:
> >
> > Gah! For the benefit of others on this list who may be misled.
> >
> > *Neither* of you correctly understands the device tree, what I've see
On Mon, Nov 19, 2007 at 12:28:02PM -0700, Grant Likely wrote:
> On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > You might be stuck with using either a platform_device or an
> > > of_platform_device as a stepping stone to creating the
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
On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > Now how do I pick which fabric driver to initialize?
>
> I'm doing it via a Kconfig option. For ASoC V1, I think that's the only way
> that works.
I believe that is your only choice on v1. V1 is not set up to
correctly ha
Jon Smirl wrote:
> Now how do I pick which fabric driver to initialize?
I'm doing it via a Kconfig option. For ASoC V1, I think that's the only way
that works.
--
Timur Tabi
Linux Kernel Developer @ Freescale
___
Linuxppc-dev mailing list
Linuxppc-
On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > You might be stuck with using either a platform_device or an
> > of_platform_device as a stepping stone to creating the device on the
> > ALSA fabric driver.
>
> I also concluded that I need
On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > > > On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > > > On 11/19/0
On 11/19/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 19, 2007 at 04:31:57PM +, Matt Sealey wrote:
> > I never said drivers should depend on it but why do you want to name
> > an i2s bus as "i2s" or the i2c bus as "i2c"?
>
> Because that's what they are?
>
> > There are far, far more
On Mon, Nov 19, 2007 at 04:31:57PM +, Matt Sealey wrote:
> I never said drivers should depend on it but why do you want to name
> an i2s bus as "i2s" or the i2c bus as "i2c"?
Because that's what they are?
> There are far, far more descriptive names that can be used. i2s is
> basically audio,
On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > > On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > > On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > > > Jon Smirl wr
Segher Boessenkool wrote:
>> And I forgot the rant you guys usually get - for god's sake, why isn't
>> anyone using the "model" property?
>
> Probably because it isn't useful all that often.
>
>> [EMAIL PROTECTED] {
>> \\ this is our magic audio fabric
>> device_type = "digispeaker,flinge
On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > You probably mean "don't use the of_platform bus to load the fabric
> > driver".
>
> Yes, that is what I meant.
>
> > He still needs to use the data in the device tree to decide
> > what fabric drivers to use.
>
> I'm no
On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > You probably mean "don't use the of_platform bus to load the fabric
> > driver".
>
> Yes, that is what I meant.
>
> > He still needs to use the data in the device tree to decide
> > what fabric drivers to use.
>
> I'm no
On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > > Jon Smirl wrote:
> > > >
> > > > > In the ALSA SOC model the i2s, codec
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 itsel
On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > Jon Smirl wrote:
> > >
> > > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > > A fabric driver tells s
David Gibson wrote:
> On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote:
>
> Gah! For the benefit of others on this list who may be misled.
>
> *Neither* of you correctly understands the device tree, what I've seen
> of *both* your suggested approaches is crap.
>
> The device tree des
On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > Jon Smirl wrote:
> >
> > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > A fabric driver tells specifically how a generic codec is wired into
> > > the board.
On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > Jon Smirl wrote:
> >
> > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > A fabric driver tells specifically how a generic codec is wired into
> > > the board. Wh
On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > A fabric driver tells specifically how a generic codec is wired into
> > the board. What I haven't been able figure out is how to load the
> > right
On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> 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 n
On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > A fabric driver tells specifically how a generic codec is wired into
> > the board. What I haven't been able figure out is how to load the
> > right
So, like, the other day Timur Tabi mumbled:
>
> If I weren't on vacation this week, I'd email you my code. It's almost done
> and it demonstrates what I'm thinking.
Are the margins of this paper too small for your proof?
jdl
___
Linuxppc-dev mailing
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
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
> 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
> dr
> And I forgot the rant you guys usually get - for god's sake, why isn't
> anyone using the "model" property?
Probably because it isn't useful all that often.
> [EMAIL PROTECTED] {
> \\ this is our magic audio fabric
> device_type = "digispeaker,flinger";
This is wrong in so many way
On 11/18/07, David Gibson <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote:
> > Matt Sealey wrote:
> > > Jon Smirl wrote:
> > >
> > > If you require the codec to be subservient to some "fabric" then I
> > > suggest you make a "sound" node with a compatible en
On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote:
> Matt Sealey wrote:
> > Jon Smirl wrote:
> >
> > If you require the codec to be subservient to some "fabric" then I
> > suggest you make a "sound" node with a compatible entry which is
> > defined as something specific to your board (dig
On 11/18/07, Matt Sealey <[EMAIL PROTECTED]> wrote:
> I'd suggest something like this:
>
> [EMAIL PROTECTED] {
> \\ this is our magic audio fabric
> device_type = "digispeaker,flinger";
>
> \\ it's actually just an i2s pcm codec
> compatible = "mpc5200-psc-i2s";
>
>
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
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 dev
On 11/18/07, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
> > David Gibson
> > made a proposal that a fabric node wrap the codec node. That doesn't
> > work very well with the i2c bus where the bus code is walking down the
> > nodes and triggering the instantiation of the i2c drivers.
>
> Yeah, do
> [EMAIL PROTECTED] { // PSC2
> compatible = "mpc5200b-psc-ac97","mpc5200-psc-ac97";
> cell-index = <1>;
> reg = <2200 100>;
> interrupts = <2 2 0>;
> interrupt-pa
I've been trying to write ALSA SOC code supporting audio codecs and
device trees.
This looks ok for the main device tree entires. Codecs are hung off
from their controlling bus. It may still need a little tweaking.
[EMAIL PROTECTED] { // PSC2
co
Jon Smirl wrote:
> This could work. The generic codec is a alsa soc_device_driver, not a
> of_device_driver. The codec node could instantiate the fabric as a
> of_device_driver which could then instantiate the soc_device_driver
> for the generic codec.
>
> The generic codecs are supposed to work
On 10/24/07, David Gibson <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 24, 2007 at 08:17:57PM -0400, Jon Smirl wrote:
> > On 10/24/07, David Gibson <[EMAIL PROTECTED]> wrote:
> > > I'm afraid I still don't understand quite what information this
> > > "fabric" driver is conveying. Is it really inherent
On Wed, Oct 24, 2007 at 08:17:57PM -0400, Jon Smirl wrote:
> On 10/24/07, David Gibson <[EMAIL PROTECTED]> wrote:
> > I'm afraid I still don't understand quite what information this
> > "fabric" driver is conveying. Is it really inherently platform
> > specific, or is it something that can be enco
On 10/24/07, David Gibson <[EMAIL PROTECTED]> wrote:
> I'm afraid I still don't understand quite what information this
> "fabric" driver is conveying. Is it really inherently platform
> specific, or is it something that can be encoded directly in a
> sensible way. If the latter we could have a ge
On Wed, Oct 24, 2007 at 11:19:33AM -0400, Jon Smirl wrote:
> On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > > codec0: [EMAIL PROTECTED] {
> > > > compatible = "ti,tas5508";
> > > > reg = <0>;
> > > >
On Wed, Oct 24, 2007 at 10:38:11AM -0600, Grant Likely wrote:
> On 10/24/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
[snip]
> > > For example:
> > > [EMAIL PROTECTED] {
> > > compatible = ",,sound" // The board might have
> > > more than
On Wed, Oct 24, 2007 at 11:54:23AM -0400, Jon Smirl wrote:
> On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > Do you want to pick one and add it to the device tree documentation
> > > with an example for i2s and ac97? I'll use which ever one is picked.
> >
> > Sure, I'll draft something u
On Wed, Oct 24, 2007 at 09:28:42AM -0600, Grant Likely wrote:
> On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > Jon Smirl wrote:
[snip]
> > My vote is for this version. In fact, I think it *has* to be this way. If
> > you're using a CS4270 codec (as I am), the I2C interface is *optional*.
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > Why are you using a vendor named directory? I don't believe vendor
> > named directories are used anywhere in the kernel. The directories are
> > always named after the platform or architecture. Vendor directories
> > end u
Jon Smirl wrote:
> Why are you using a vendor named directory? I don't believe vendor
> named directories are used anywhere in the kernel. The directories are
> always named after the platform or architecture. Vendor directories
> end up in a big mess if Freescale decides to sell a CPU to someone
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > Calling it directly from the platform code is an option, but where
> > does the fabric driver code live? It doesn't make a lot of sense to
> > put ALSA code into arch/powerpc/platforms/52xx. I could make a
> > function call
Jon Smirl wrote:
> Calling it directly from the platform code is an option, but where
> does the fabric driver code live? It doesn't make a lot of sense to
> put ALSA code into arch/powerpc/platforms/52xx. I could make a
> function call from arch/powerpc/platforms/52xx over to
> sound/soc/powerpc
On 10/24/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > Heh, I'm one of the folks who objected to it; here's what was written:
> >
> > > > >
> > > > > [EMAIL PROTECTED] { // use to trigger loading platform specific
> > > > > fabric driver
> > >
On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> Heh, I'm one of the folks who objected to it; here's what was written:
>
> > > >
> > > > [EMAIL PROTECTED] { // use to trigger loading platform specific fabric
> > > > driver
> > > > device_type = "pseudo-sound"
> > > > };
> > >
> > > I
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > Now is probably a good time to mention that there is *nothing* in the
> > device tree that enforces a 1:1 relationship between device tree nodes
> > and driver instances. Sure, it make sense to register the i2s and
> >
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > If you need to scan the tree, don't do it when the driver registers,
> > do it in the platform code instead. Otherwise you unconditionally
> > incur the penalty of scanning the whole device tree on every system
> > that
Grant Likely wrote:
> If you need to scan the tree, don't do it when the driver registers,
> do it in the platform code instead. Otherwise you unconditionally
> incur the penalty of scanning the whole device tree on every system
> that loads the driver, regardless of whether or not the device is
Grant Likely wrote:
> Now is probably a good time to mention that there is *nothing* in the
> device tree that enforces a 1:1 relationship between device tree nodes
> and driver instances. Sure, it make sense to register the i2s and
> codec drivers from probing on the i2s and codec nodes. Howeve
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > It makes sense to me, there needs to be some way to trigger loading
> > the fabric driver.
>
> Well, you only really two have choices:
>
> 1) Probe on the AC97/SSI nodes
> 2) When the driver initializes, just scan all the n
On 10/24/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > Do you want to pick one and add it to the device tree documentation
> > > with an example for i2s and ac97? I'll use which ever one is picked.
> >
> > Sure, I'll draft something up and pos
Jon Smirl wrote:
> It makes sense to me, there needs to be some way to trigger loading
> the fabric driver.
Well, you only really two have choices:
1) Probe on the AC97/SSI nodes
2) When the driver initializes, just scan all the nodes in the device tree (no
probing).
I think option #2 makes th
On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > Do you want to pick one and add it to the device tree documentation
> > with an example for i2s and ac97? I'll use which ever one is picked.
>
> Sure, I'll draft something up and post it for review.
>
> On the device probing front; what about
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > I see your point about putting the child node onto the control bus.
> > ac97 is both a control and data bus. For the i2s case the child should
> > go onto the i2c bus.
>
> I know AC97 is *also* a control bus, but treating I
On 10/24/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > Two valid methods have been proposed
> > > 1. a codec-
> >
> > oops
> >
> > 1. a codec-handle property in the i2s node
> > 2. an i2s-handle property in the codec node
> >
> > Either are re
Jon Smirl wrote:
> I see your point about putting the child node onto the control bus.
> ac97 is both a control and data bus. For the i2s case the child should
> go onto the i2c bus.
I know AC97 is *also* a control bus, but treating I2S and AC97 differently is
bad, IMHO. If you're going to put
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > What I meant was that there is no attempt to describe how the codec is
> > connected to the external world. Those connections are described in
> > the fabric driver.
>
> Hmmm, I'm not sure I'm okay with that. We can always
On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > Two valid methods have been proposed
> > 1. a codec-
>
> oops
>
> 1. a codec-handle property in the i2s node
> 2. an i2s-handle property in the codec node
>
> Either are reasonable. I prefer putting the handle in the i2s node;
> but I'm look
On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > The DTC experts need to tell us which way to make the pointers between
> > i2s and i2c for the codec. Here's a another way it could be done that
> > looks more like the ac97 model.
>
> I *really* don't think this is a good idea. Put the nod
On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > Jon Smirl wrote:
> > > > Is this consensus on how the tree should look?
> > > >
> > > > There is no attempt to describe the codec con
On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > codec0: [EMAIL PROTECTED] {
> > > compatible = "ti,tas5508";
> > > reg = <0>;
> > > i2s-handle = <&[EMAIL PROTECTED]>;
> > > };
> >
> > I'd
On 10/24/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > Jon Smirl wrote:
> > > Is this consensus on how the tree should look?
> > >
> > > There is no attempt to describe the codec connections inside the
> > > device tree.
> >
> > I don't think I ag
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > codec0: [EMAIL PROTECTED] {
> > compatible = "ti,tas5508";
> > reg = <0>;
> > i2s-handle = <&[EMAIL PROTECTED]>;
> > };
>
> I'd do this the other way around -- that is:
>
> [EMAIL PROTECTED] {
Jon Smirl wrote:
> What I meant was that there is no attempt to describe how the codec is
> connected to the external world. Those connections are described in
> the fabric driver.
Hmmm, I'm not sure I'm okay with that. We can always add properties to those
nodes if it's necessary. However, no
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > Is this consensus on how the tree should look?
> >
> > There is no attempt to describe the codec connections inside the
> > device tree.
>
> I don't think I agree with that. The device tree should indicate which codec
> is
Jon Smirl wrote:
> Is this consensus on how the tree should look?
>
> There is no attempt to describe the codec connections inside the
> device tree.
I don't think I agree with that. The device tree should indicate which codec
is
connected to which I2S/AC97 device.
I see that you do that for
Is this consensus on how the tree should look?
There is no attempt to describe the codec connections inside the
device tree. Instead ASoC handles this by loading a platform specific
fabric driver. A simple example of this is that it is some codecs can
assign the six channel outputs under software
>> First example is ac97 audio:
>>
>> [EMAIL PROTECTED] { // PSC1
> I think the codec node should be a child of this node, not a separate
> node.
> Then there should be another codec node as a child of the i2c node.
AC'97 codecs don't typically have an I2C connection (if ever).
You sh
Jon Smirl wrote:
> Is this what the device tree entries should look like?
>
> First example is ac97 audio:
>
> [EMAIL PROTECTED] { // PSC1
> device_type = "sound";
> compatible = "mpc5200b-psc-ac97\0mpc5200-psc-ac97";
> cell-index = <0>;
> reg = <2000 100>;
>
> Isn't this the ac97 bus node? Can't the ac97 codecs simply be
> children of this bus?
They should be, yes.
>> [EMAIL PROTECTED] { // use to trigger loading platform specific fabric
>> driver
>> device_type = "pseudo-sound"
>> };
>
> I don't think this is a good idea. The device tree is
On 10/22/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> Is this what the device tree entries should look like?
>
> First example is ac97 audio:
>
> [EMAIL PROTECTED] { // PSC1
> device_type = "sound";
> compatible = "mpc5200b-psc-ac97\0mpc5200-psc-ac97";
This format is so, like.
On Mon, Oct 22, 2007 at 09:59:00PM -0400, Jon Smirl wrote:
> Is this what the device tree entries should look like?
>
> First example is ac97 audio:
>
> [EMAIL PROTECTED] { // PSC1
> device_type = "sound";
Kill all these device_type values.
> compatible = "mpc5200b-psc-ac9
Is this what the device tree entries should look like?
First example is ac97 audio:
[EMAIL PROTECTED] { // PSC1
device_type = "sound";
compatible = "mpc5200b-psc-ac97\0mpc5200-psc-ac97";
cell-index = <0>;
reg = <2000 100>;
interrupts = <2 1 0>;
interr
81 matches
Mail list logo
