ASoC drivers for the Freescale MPC8610 SoC

On Mon, 2008-01-07 at 09:52 -0600, Timur Tabi wrote:

So all I'm trying to do now is get my driver, with warts and all, into the tree 
so that I can focus with Liam et al to get a real ASoC V2 up and running.

I'll commit the MPC8610 into the ASoC (v1) dev tree soon (hopefully
tonight). This will allow folks to use it in the meantime whilst we sort
out any changes.

I'll then port (what I can) to V2, although I may need some assistance
with some of the PPC sections.

Fwiw we are looking at submitting V2 in March/April time. 


Liam

PS. Sorry for the silence lately. We've just moved to a new opensource
server over the holidays and have been without some services i.e. mail.



Privacy & Confidentiality Notice
-------------------------------------------------
This message and any attachments contain privileged and confidential information that is intended solely for the person(s) to whom it is addressed. If you are not an intended recipient you must not: read; copy; distribute; discuss; take any action in or make any reliance upon the contents of this message; nor open or read any attachment. If you have received this message in error, please notify us as soon as possible on the following telephone number and destroy this message including any attachments. Thank you.
-------------------------------------------------
Wolfson Microelectronics plc
Tel: +44 (0)131 272 7000
Fax: +44 (0)131 272 7001
Web: www.wolfsonmicro.com

Registered in Scotland

Company number SC089839

Registered office: 

Westfield House, 26 Westfield Road, Edinburgh, EH11 2QB, UK

On Mon, Jan 07, 2008 at 06:28:54PM +0000, Mark Brown wrote:

On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote:

quoted

David Gibson wrote:

quoted

quoted

Ok, but couldn't you strucutre your I2S or fabric driver so that it
only becomes fully operational once the codec driver has registered
with it?

quoted

Not in ASoC V1.  You have to understand, ASoC V1 was designed without any 
consideration for runtime-bindings and other OF goodies.  All connections 
between the drivers are static, literally.  In fact, I wouldn't be surprised if 
some ASoC drivers cannot be compiled as modules.

I'd just like to emphasise this point - ASoC v1 really doesn't
understand the idea that the components of the sound subsystem might be
probed separately.  It's set up to handle bare hardware with everything
being probed from code in the machine/fabric driver.  This makes life
very messy for platforms with something like the device tree.

As has been said, handling this properly is one of the major motivations
behind ASoC v2.

Ick.  Ok.

Nonetheless, messing up the device tree to workaround ASoC V1's silly
limitations is not a good idea.  The device tree must represent the
hardware as much as possible.  If that means we have to have a bunch
of platform-specific hacks to instatiate the drivers in the correct
order / combination, that's unfortunate, but there you go.

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

On 1/9/08, David Gibson [off-list ref] wrote:

On Mon, Jan 07, 2008 at 06:28:54PM +0000, Mark Brown wrote:

quoted

On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote:

quoted

David Gibson wrote:

quoted

quoted

Ok, but couldn't you strucutre your I2S or fabric driver so that it
only becomes fully operational once the codec driver has registered
with it?

quoted

Not in ASoC V1.  You have to understand, ASoC V1 was designed without any
consideration for runtime-bindings and other OF goodies.  All connections
between the drivers are static, literally.  In fact, I wouldn't be surprised if
some ASoC drivers cannot be compiled as modules.

I'd just like to emphasise this point - ASoC v1 really doesn't
understand the idea that the components of the sound subsystem might be
probed separately.  It's set up to handle bare hardware with everything
being probed from code in the machine/fabric driver.  This makes life
very messy for platforms with something like the device tree.

As has been said, handling this properly is one of the major motivations
behind ASoC v2.

Ick.  Ok.

Nonetheless, messing up the device tree to workaround ASoC V1's silly
limitations is not a good idea.  The device tree must represent the
hardware as much as possible.  If that means we have to have a bunch
of platform-specific hacks to instatiate the drivers in the correct
order / combination, that's unfortunate, but there you go.

ASOC v2 is sitting on a Wolfson server out of tree. I have been using
it for several months without problem. The pace of it being merged
could probably be sped up.

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

On Thu, 2008-01-10 at 00:41 -0500, Jon Smirl wrote:

ASOC v2 is sitting on a Wolfson server out of tree. I have been using
it for several months without problem. The pace of it being merged
could probably be sped up.

I think we are probably looking at submission in the next 8 - 10 weeks.
Currently most of the core code is complete, however some platforms and
codecs still need porting.

Liam

Liam Girdwood wrote:

I think we are probably looking at submission in the next 8 - 10 weeks.
Currently most of the core code is complete, however some platforms and
codecs still need porting.

With that in mind, can I get some kind of consensus from the PPC side as to whether this ASoC V1 driver is okay?  I want to get it into 2.6.25.

Keep in mind:

1) ASoC V1 is not PowerPC-friendly, so it's impossible to make an ASoC V1 PowerPC driver "100% correct".

2) The CS4270 driver does not support I2C nodes in the device tree, so there's not point in adding any to the 8610 DTS.

3) Liam and I are working on porting this driver to ASoC V2 and resolving all open PPC issue, but that won't be done in time for 2.6.25.

-- 
Timur Tabi
Linux kernel developer at Freescale

On 1/10/08, Timur Tabi [off-list ref] wrote:

Liam Girdwood wrote:

quoted

I think we are probably looking at submission in the next 8 - 10 weeks.
Currently most of the core code is complete, however some platforms and
codecs still need porting.

With that in mind, can I get some kind of consensus from the PPC side as to
whether this ASoC V1 driver is okay?  I want to get it into 2.6.25.

Keep in mind:

1) ASoC V1 is not PowerPC-friendly, so it's impossible to make an ASoC V1
PowerPC driver "100% correct".

The driver doesn't need to be 100% correct.  Drivers are easy to
change if they aren't quite right.  There are no long term
consequences.

However, the device tree issues must be addressed before it is merged
and deployed.  Otherwise we end up having to support poorly designed
trees over the long term.

So, I'm okay with merging the driver *minus* the .dts and
booting-without-of.txt changes.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Grant Likely wrote:

The driver doesn't need to be 100% correct.  Drivers are easy to
change if they aren't quite right.  There are no long term
consequences.

However, the device tree issues must be addressed before it is merged
and deployed.  Otherwise we end up having to support poorly designed
trees over the long term.

I agree.  Correct me if I'm wrong, but I think the only device tree "issue" is the definition of the 'codec' node under the SSI node.  If so, I'm not sure what other changes need to be mode.

-- 
Timur Tabi
Linux kernel developer at Freescale

On 1/10/08, Timur Tabi [off-list ref] wrote:

Grant Likely wrote:

quoted

The driver doesn't need to be 100% correct.  Drivers are easy to
change if they aren't quite right.  There are no long term
consequences.

 >

quoted

However, the device tree issues must be addressed before it is merged
and deployed.  Otherwise we end up having to support poorly designed
trees over the long term.

I agree.  Correct me if I'm wrong, but I think the only device tree "issue" is
the definition of the 'codec' node under the SSI node.  If so, I'm not sure what
other changes need to be mode.

Isn't your codec is i2c controlled? Where does the main node for the
code live, i2c bus or ssi bus? What does the link between the buses
look like for pointing to the codec entry?

What about fsl,ssi being too generic for a compatible type?

--
Timur Tabi
Linux kernel developer at Freescale

-- 
Jon Smirl
jonsmirl@gmail.com

Jon Smirl wrote:

Isn't your codec is i2c controlled? Where does the main node for the
code live, i2c bus or ssi bus? What does the link between the buses
look like for pointing to the codec entry?

The CS4270 driver is "old style", which means it probes all possible I2C addresses until it finds a hit, and then stops.  This has all the obvious drawbacks, but I'm stuck with that design for now.

What about fsl,ssi being too generic for a compatible type?

Already fixed:

		ssi@16000 {
			compatible = "fsl,mpc8610-ssi";
-- 
Timur Tabi
Linux kernel developer at Freescale

On 1/10/08, Timur Tabi [off-list ref] wrote:

Jon Smirl wrote:

quoted

Isn't your codec is i2c controlled? Where does the main node for the
code live, i2c bus or ssi bus? What does the link between the buses
look like for pointing to the codec entry?

The CS4270 driver is "old style", which means it probes all possible I2C
addresses until it finds a hit, and then stops.  This has all the obvious
drawbacks, but I'm stuck with that design for now.

quoted

What about fsl,ssi being too generic for a compatible type?

Already fixed:

                ssi@16000 {
                        compatible = "fsl,mpc8610-ssi";

Nit: node name should be either i2s@16000 (the mode that it is in), or
sound@16000 (if you feel that this node encapsulates the concept of a
sound device enough).

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Grant Likely wrote:

Nit: node name should be either i2s@16000 (the mode that it is in), or
sound@16000 (if you feel that this node encapsulates the concept of a
sound device enough).

Well, SSI stands for "Synchronous Serial  Interface" (although it's capable of asynchronous communication as well).  From the manual:

"The SSI is a full-duplex, serial port that allows the chip to communicate with a variety of serial devices.  These serial devices can be standard CODer-DECoder (CODECs), Digital Signal Processors (DSPs), microprocessors, peripherals, and popular industry audio CODECs that implement the inter-IC sound bus standard (I2S) and Intel AC97 standard."

It might an I2S device in this case, but it could be an AC97 device in some other case.  It all depends on how the board is wired.  Do we really want to change the name of an SOC device based on what it's connected to?

-- 
Timur Tabi
Linux kernel developer at Freescale

On 1/10/08, Timur Tabi [off-list ref] wrote:

Jon Smirl wrote:

quoted

Isn't your codec is i2c controlled? Where does the main node for the
code live, i2c bus or ssi bus? What does the link between the buses
look like for pointing to the codec entry?

The CS4270 driver is "old style", which means it probes all possible I2C
addresses until it finds a hit, and then stops.  This has all the obvious
drawbacks, but I'm stuck with that design for now.

So the codec is controlled from the i2c bus and SSI is used to supply
it with data. Based on what has been said on this list, the device
tree node for the codec should be on the i2c bus with a link from the
ssi bus to it.

quoted

What about fsl,ssi being too generic for a compatible type?

Already fixed:

                ssi@16000 {
                        compatible = "fsl,mpc8610-ssi";
--
Timur Tabi
Linux kernel developer at Freescale

-- 
Jon Smirl
jonsmirl@gmail.com

Jon Smirl wrote:

So the codec is controlled from the i2c bus and SSI is used to supply
it with data. Based on what has been said on this list, the device
tree node for the codec should be on the i2c bus with a link from the
ssi bus to it.

I'm working on that now.  I'll have a new patch with this exact change this afternoon.

-- 
Timur Tabi
Linux kernel developer at Freescale