[alsa-devel] ASoC: cs4271: init/timing problem
Hey all,
We have a custom built hw, based on am335x and from time to time we need to rmmod/modprobe the ASoC machine driver. Depending on the hw, the first call to regmap_update_bits(..) in cs4271_codec_probe(..) fails with -EREMOTEIO.
The error is originated in:
drivers/i2c/busses/i2c-omap.c
and happens if no i2c package acknowledge is received by the host.
I think this is a timing issue and on some devices, the codec is just not ready yet, for communication.
What is the right way to fix that? My attempt would be something like this:
const int retries = 5;
while (retries) { ret = regmap_update_bits(cs4271->regmap, CS4271_MODE2, CS4271_MODE2_PDN | CS4271_MODE2_CPEN, CS4271_MODE2_PDN | CS4271_MODE2_CPEN);
if (ret == -EREMOTEIO) { retries--; udelay(1); continue;
} else if (ret) return ret;
break; }
But I might also just add a proper delay before the first call to regmap_update_bits(..)
So what is the proper way to handle this?
Thanks Pascal
On Tue, 31 Mar 2015, Pascal Huerst wrote:
Hey all,
We have a custom built hw, based on am335x and from time to time we need to rmmod/modprobe the ASoC machine driver. Depending on the hw, the first call to regmap_update_bits(..) in cs4271_codec_probe(..) fails with -EREMOTEIO.
The error is originated in:
drivers/i2c/busses/i2c-omap.c
and happens if no i2c package acknowledge is received by the host.
I think this is a timing issue and on some devices, the codec is just not ready yet, for communication.
What is the right way to fix that? My attempt would be something like this:
The error you are referring to is a NACK from a device (CODEC). That is usually seen when you dont have it hooked up correctly. Could also be that the I2C bus is too fast. How fast are you running the bus?
-Brian
Hey Brian,
On 31.03.2015 23:01, Brian Austin wrote:
On Tue, 31 Mar 2015, Pascal Huerst wrote:
Hey all,
We have a custom built hw, based on am335x and from time to time we need to rmmod/modprobe the ASoC machine driver. Depending on the hw, the first call to regmap_update_bits(..) in cs4271_codec_probe(..) fails with -EREMOTEIO.
The error is originated in:
drivers/i2c/busses/i2c-omap.c
and happens if no i2c package acknowledge is received by the host.
I think this is a timing issue and on some devices, the codec is just not ready yet, for communication.
What is the right way to fix that? My attempt would be something like this:
The error you are referring to is a NACK from a device (CODEC). That is usually seen when you dont have it hooked up correctly. Could also be that the I2C bus is too fast. How fast are you running the bus?
clock-frequency is set to 100000, hence 100 kHz, which should be ok, according to the datasheet.
Hey Brian,
On 01.04.2015 11:57, Pascal Huerst wrote:
Hey Brian,
On 31.03.2015 23:01, Brian Austin wrote:
On Tue, 31 Mar 2015, Pascal Huerst wrote:
Hey all,
We have a custom built hw, based on am335x and from time to time we need to rmmod/modprobe the ASoC machine driver. Depending on the hw, the first call to regmap_update_bits(..) in cs4271_codec_probe(..) fails with -EREMOTEIO.
The error is originated in:
drivers/i2c/busses/i2c-omap.c
and happens if no i2c package acknowledge is received by the host.
I think this is a timing issue and on some devices, the codec is just not ready yet, for communication.
What is the right way to fix that? My attempt would be something like this:
The error you are referring to is a NACK from a device (CODEC). That is usually seen when you dont have it hooked up correctly. Could also be that the I2C bus is too fast. How fast are you running the bus?
clock-frequency is set to 100000, hence 100 kHz, which should be ok, according to the datasheet.
I just lowered the clock-frequency to 50 kHz and I face the same problem, but it very much depends on the hardware. On some devices I don't face the problem at all and on others I can reproduce it very reliable. If I add a mdelay(20), or use the loop I postet earlier, the issue is gone on all devices.
On Apr 1, 2015, at 5:52 AM, Pascal Huerst pascal.huerst@gmail.com wrote:
Hey Brian,
On 01.04.2015 11:57, Pascal Huerst wrote:
Hey Brian,
On 31.03.2015 23:01, Brian Austin wrote:
On Tue, 31 Mar 2015, Pascal Huerst wrote:
Hey all,
We have a custom built hw, based on am335x and from time to time we need to rmmod/modprobe the ASoC machine driver. Depending on the hw, the first call to regmap_update_bits(..) in cs4271_codec_probe(..) fails with -EREMOTEIO.
The error is originated in:
drivers/i2c/busses/i2c-omap.c
and happens if no i2c package acknowledge is received by the host.
I think this is a timing issue and on some devices, the codec is just not ready yet, for communication.
What is the right way to fix that? My attempt would be something like this:
The error you are referring to is a NACK from a device (CODEC). That is usually seen when you dont have it hooked up correctly. Could also be that the I2C bus is too fast. How fast are you running the bus?
clock-frequency is set to 100000, hence 100 kHz, which should be ok, according to the datasheet.
I just lowered the clock-frequency to 50 kHz and I face the same problem, but it very much depends on the hardware. On some devices I don't face the problem at all and on others I can reproduce it very reliable. If I add a mdelay(20), or use the loop I postet earlier, the issue is gone on all devices.
Are there any other devices on the I2C bus? Lets take this off the ALSA list until there is a determination that it is an ASoC issue which it does not appear to be right now. OK?
Thanks, Brian
On 01.04.2015 16:47, Austin, Brian wrote:
On Apr 1, 2015, at 5:52 AM, Pascal Huerst pascal.huerst@gmail.com wrote:
Hey Brian,
On 01.04.2015 11:57, Pascal Huerst wrote:
Hey Brian,
On 31.03.2015 23:01, Brian Austin wrote:
On Tue, 31 Mar 2015, Pascal Huerst wrote:
Hey all,
We have a custom built hw, based on am335x and from time to time we need to rmmod/modprobe the ASoC machine driver. Depending on the hw, the first call to regmap_update_bits(..) in cs4271_codec_probe(..) fails with -EREMOTEIO.
The error is originated in:
drivers/i2c/busses/i2c-omap.c
and happens if no i2c package acknowledge is received by the host.
I think this is a timing issue and on some devices, the codec is just not ready yet, for communication.
What is the right way to fix that? My attempt would be something like this:
The error you are referring to is a NACK from a device (CODEC). That is usually seen when you dont have it hooked up correctly. Could also be that the I2C bus is too fast. How fast are you running the bus?
clock-frequency is set to 100000, hence 100 kHz, which should be ok, according to the datasheet.
I just lowered the clock-frequency to 50 kHz and I face the same problem, but it very much depends on the hardware. On some devices I don't face the problem at all and on others I can reproduce it very reliable. If I add a mdelay(20), or use the loop I postet earlier, the issue is gone on all devices.
Are there any other devices on the I2C bus? Lets take this off the ALSA list until there is a determination that it is an ASoC issue which it does not appear to be right now.
Well I think it is. There is a delay needed in sound/soc/codec/cs4271.c at line 569, in certain cases, because the call to regmap_update_bits on line 570 fails sometimes. If I add a delay of a few us on line 569, the call never fails.
But let me just send in a patch so we really know what we are talking about, then.
I just lowered the clock-frequency to 50 kHz and I face the same problem, but it very much depends on the hardware. On some devices I don't face the problem at all and on others I can reproduce it very reliable. If I add a mdelay(20), or use the loop I postet earlier, the issue is gone on all devices.
Are there any other devices on the I2C bus? Lets take this off the ALSA list until there is a determination that it is an ASoC issue which it does not appear to be right now.
Well I think it is. There is a delay needed in sound/soc/codec/cs4271.c at line 569, in certain cases, because the call to regmap_update_bits on line 570 fails sometimes. If I add a delay of a few us on line 569, the call never fails.
But let me just send in a patch so we really know what we are talking about, then.
can you try something like this?
gpio_direction_output(cs4271->gpio_nreset, 0); -udelay(1); gpio_set_value(cs4271->gpio_nreset, 1); /* Give the codec time to wake up */ -udelay(1);
gpio_direction_output(cs4271->gpio_nreset, 0); +mdelay(1); gpio_set_value(cs4271->gpio_nreset, 1); /* Give the codec time to wake up */ +mdelay(1);
See if that helps instead of adding another delay.
On 01.04.2015 19:08, Brian Austin wrote:
I just lowered the clock-frequency to 50 kHz and I face the same problem, but it very much depends on the hardware. On some devices I don't face the problem at all and on others I can reproduce it very reliable. If I add a mdelay(20), or use the loop I postet earlier, the issue is gone on all devices.
Are there any other devices on the I2C bus? Lets take this off the ALSA list until there is a determination that it is an ASoC issue which it does not appear to be right now.
Well I think it is. There is a delay needed in sound/soc/codec/cs4271.c at line 569, in certain cases, because the call to regmap_update_bits on line 570 fails sometimes. If I add a delay of a few us on line 569, the call never fails.
But let me just send in a patch so we really know what we are talking about, then.
can you try something like this?
gpio_direction_output(cs4271->gpio_nreset, 0); -udelay(1); gpio_set_value(cs4271->gpio_nreset, 1); /* Give the codec time to wake up */ -udelay(1);
gpio_direction_output(cs4271->gpio_nreset, 0); +mdelay(1); gpio_set_value(cs4271->gpio_nreset, 1); /* Give the codec time to wake up */ +mdelay(1);
See if that helps instead of adding another delay.
Works perfect for me. Tested on different devices without any problems. If you agree on that, I'll send in a patch.
participants (3)
-
Austin, Brian -
Brian Austin
-
Pascal Huerst