[alsa-devel] Does anyone really have success experience with SPI codecs with new name-based SOC API?
Does anyone really have success experience with SPI codecs with new name-based SOC API? There are really few SPI codecs in ASoC subsystem, so I wonder if only I cannot bind my SPI codec to machine driver.
The codec is registered with name spi0.0 it's the behavior of SPI subsystem, I suppose. So the form is %s%d.%d and not %s.%d as supposed in fmt_single_name() in soc_core.c
For me dev_name(dev)==spi0.0 dev->driver->name==cs4271-codec
Is this really working code? ----- strncpy(name, dev_name(dev), NAME_SIZE);
/* are we a "%s.%d" name (platform and SPI components) */ found = strstr(name, dev->driver->name); if (found) { /* get ID */ if (sscanf(&found[strlen(dev->driver->name)], ".%d", id) == 1) {
/* discard ID from name if ID == -1 */ if (*id == -1) found[strlen(dev->driver->name)] = '\0'; }
} else { -----
On Thu, 2010-11-18 at 14:31 +0300, Alexander wrote:
Does anyone really have success experience with SPI codecs with new name-based SOC API? There are really few SPI codecs in ASoC subsystem, so I wonder if only I cannot bind my SPI codec to machine driver.
Just use the registered codec name in the machine driver so soc-core can match it correctly. You should not worry about incompatibilities in the naming convention between SPI registered devices and I2C ones. The only thing that we try to guarantee is to be able to uniquely identify the devices on the system.
Thanks, Dimitrios
On Thu, 2010-11-18 at 14:31 +0300, Alexander wrote:
Does anyone really have success experience with SPI codecs with new name-based SOC API? There are really few SPI codecs in ASoC subsystem, so I wonder if only I cannot bind my SPI codec to machine driver.
The codec is registered with name spi0.0 it's the behavior of SPI subsystem, I suppose. So the form is %s%d.%d and not %s.%d as supposed in fmt_single_name() in soc_core.c
Just use the registered codec name in the machine driver so soc-core can match it correctly. You should not worry about incompatibilities in the naming convention between SPI registered devices and I2C ones. The only thing that we try to guarantee is to be able to uniquely identify the devices on the system.
Thanks, Dimitrios
Hi Alexander,
On Thu, Nov 18, 2010 at 9:31 AM, Alexander subaparts@yandex.ru wrote:
Does anyone really have success experience with SPI codecs with new name-based SOC API? There are really few SPI codecs in ASoC subsystem, so I wonder if only I cannot bind my SPI codec to machine driver.
The codec is registered with name spi0.0 it's the behavior of SPI subsystem, I suppose. So the form is %s%d.%d and not %s.%d as supposed in fmt_single_name() in soc_core.c
For me dev_name(dev)==spi0.0 dev->driver->name==cs4271-codec
Is this really working code?
strncpy(name, dev_name(dev), NAME_SIZE);
/* are we a "%s.%d" name (platform and SPI components) */ found = strstr(name, dev->driver->name); if (found) { /* get ID */ if (sscanf(&found[strlen(dev->driver->name)], ".%d", id) == 1) {
/* discard ID from name if ID == -1 */ if (*id == -1) found[strlen(dev->driver->name)] = '\0'; }
} else {
Have you managed to bind the SPI codec? I am trying the same thing here. Please let me know.
Regards,
Fabio Estevam
On Thu, 2010-12-02 at 16:12 -0200, Fabio Estevam wrote:
On Thu, Nov 18, 2010 at 9:31 AM, Alexander subaparts@yandex.ru wrote:
Does anyone really have success experience with SPI codecs with new name-based SOC API? There are really few SPI codecs in ASoC subsystem, so I wonder if only I cannot bind my SPI codec to machine driver.
The codec is registered with name spi0.0 it's the behavior of SPI subsystem, I suppose. So the form is %s%d.%d and not %s.%d as supposed in fmt_single_name() in soc_core.c
Have you managed to bind the SPI codec? I am trying the same thing here. Please let me know.
I've received a reply from Dimitris Papastamos, SoC subsystem developer, and he written, that I should use it as is, ie spi0.0 So I'm finished with names and successfully binded it as codecname==spi0.0
But for now, I have no sound anyway, it seems that something in SPI path is broken (but I suppose, not in my code, as it works on 2.6.36-rc6), I cannot see any communications going to codec with oscilloscope. So I'm trying to figure it out now...
Best regards, Alexander A. Sverdlin.
participants (3)
-
Alexander -
Dimitris Papastamos -
Fabio Estevam