[alsa-devel] spi codec names in machine drivers
after the recent multi-component patch, spi codec names were changed to "<name>.<spics>" in the machine drivers. so if we have an ad193x codec on spi bus 0 cs 5, the name is now "ad193x.5".
this also seems to be how fmt_single_name in soc-core.c is doing things. am i reading this right ?
what if i have two codecs on two different spi busses but happen to have the same cs ? shouldnt the spi code do the same as i2c and include the bus in the id naming ? -mike
On Tue, Mar 29, 2011 at 02:05:04AM -0400, Mike Frysinger wrote:
after the recent multi-component patch, spi codec names were changed to "<name>.<spics>" in the machine drivers. so if we have an ad193x codec on spi bus 0 cs 5, the name is now "ad193x.5".
this also seems to be how fmt_single_name in soc-core.c is doing things. am i reading this right ?
what if i have two codecs on two different spi busses but happen to have the same cs ? shouldnt the spi code do the same as i2c and include the bus in the id naming ?
I think we should just switch to using dev_name() everywhere.
On Wed, Mar 30, 2011 at 17:20, Mark Brown wrote:
On Tue, Mar 29, 2011 at 02:05:04AM -0400, Mike Frysinger wrote:
after the recent multi-component patch, spi codec names were changed to "<name>.<spics>" in the machine drivers. so if we have an ad193x codec on spi bus 0 cs 5, the name is now "ad193x.5".
this also seems to be how fmt_single_name in soc-core.c is doing things. am i reading this right ?
what if i have two codecs on two different spi busses but happen to have the same cs ? shouldnt the spi code do the same as i2c and include the bus in the id naming ?
I think we should just switch to using dev_name() everywhere.
so you'd want the machine driver to use "spi0.5" ? or "ad193x-spi0.5" ? -mike
On Wed, Mar 30, 2011 at 20:11, Mark Brown wrote:
On Wed, Mar 30, 2011 at 05:58:29PM -0400, Mike Frysinger wrote:
so you'd want the machine driver to use "spi0.5" ? or "ad193x-spi0.5" ?
The latter, I guess.
makes sense to me
but back to the original question, how is it working today ? :) i want to make sure the current Blackfin machine drivers are written correctly, and the boards i readily have access to are either AC97 or I2C, so it's difficult for me to boot up and verify myself. -mike
On Wed, Mar 30, 2011 at 08:15:14PM -0400, Mike Frysinger wrote:
but back to the original question, how is it working today ? :) i want to make sure the current Blackfin machine drivers are written correctly, and the boards i readily have access to are either AC97 or I2C, so it's difficult for me to boot up and verify myself.
This is the common problem with SPI codecs, they're very rarely used so not frequently tested.
On Wed, Mar 30, 2011 at 20:30, Mark Brown wrote:
On Wed, Mar 30, 2011 at 08:15:14PM -0400, Mike Frysinger wrote:
but back to the original question, how is it working today ? :) i want to make sure the current Blackfin machine drivers are written correctly, and the boards i readily have access to are either AC97 or I2C, so it's difficult for me to boot up and verify myself.
This is the common problem with SPI codecs, they're very rarely used so not frequently tested.
so i need to scrounge up some addon boards and figure out the answer myself ;)
hmm, i wonder if it'd be easier to finish my SPI simulator and write a small simulated audio codec device to connect to it ... -mike
On Wed, Mar 30, 2011 at 20:32, Mike Frysinger wrote:
On Wed, Mar 30, 2011 at 20:30, Mark Brown wrote:
On Wed, Mar 30, 2011 at 08:15:14PM -0400, Mike Frysinger wrote:
but back to the original question, how is it working today ? :) i want to make sure the current Blackfin machine drivers are written correctly, and the boards i readily have access to are either AC97 or I2C, so it's difficult for me to boot up and verify myself.
This is the common problem with SPI codecs, they're very rarely used so not frequently tested.
so i need to scrounge up some addon boards and figure out the answer myself ;)
for the curious, the answer is as i feared ... the codec_name needed in the machine driver is "spi<busnum>.<csnum>". the codec name should not be in that string. unlike the i2c version which should be "<codec>.<busnum>-<id>". -mike
participants (2)
-
Mark Brown -
Mike Frysinger