ASoC: cs4271: init/timing problem

ASoC: cs4271: init/timing problem

[Pascal Huerst]

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

Re: ASoC: cs4271: init/timing problem

[Brian Austin]

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 

Re: ASoC: cs4271: init/timing problem

[Pascal Huerst]

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.

Re: ASoC: cs4271: init/timing problem

[Pascal Huerst]

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.

Re: ASoC: cs4271: init/timing problem

[Austin, Brian]

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

Re: ASoC: cs4271: init/timing problem

[Pascal Huerst]

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.

Re: ASoC: cs4271: init/timing problem

[Brian Austin]

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

Re: ASoC: cs4271: init/timing problem

[Pascal Huerst]

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.