Hi Mark

I found a few issues with the changes you have made to sound/soc/codecs/alc5623.c which is currently in linus master branch.

The patch causing the trouble seems to be:

commit 0cd257bf9b9b0cbb4fa1a5c988a232506997867c Author: Mark Brown broonie@linaro.org Date: Thu Feb 20 09:04:06 2014 +0900

ASoC: alc5623: Convert to direct regmap API usage

Convert to directly use the regmap API, allowing us to eliminate the last user of the ASoC level I/O implementations (there are still open coded I/O implementations in drivers), avoiding duplicating code in regmap.

We no longer cache the entire CODEC register map on probe since the more advanced cache infrastructure in regmap is able to fill the cache on demand.

Signed-off-by: Mark Brown broonie@linaro.org

At boot i see:

alc562x-codec 0-001a: unknown or wrong codec alc562x-codec 0-001a: Expected 10ec:21, got ec10:2103

There are two issues here:

- vid1 = i2c_smbus_read_word_data(client, ALC5623_VENDOR_ID1); + ret = regmap_read(alc5623->regmap, ALC5623_VENDOR_ID1, &vid1);

It looks like these are returning different endianness. This explains the 10ec vs ec10.

Can the regmap flip the endianness?

The second is:

- vid2 = i2c_smbus_read_byte_data(client, ALC5623_VENDOR_ID2); - if (vid2 < 0) { - dev_err(&client->dev, "failed to read I2C\n"); - return -EIO; + ret = regmap_read(alc5623->regmap, ALC5623_VENDOR_ID2, &vid2); + if (ret < 0) { + dev_err(&client->dev, "failed to read vendor ID2: %d\n", ret); + return ret;

It was reading a byte, but now it seems to get a word. Hence 21 vs 2103. Once the endianness is sorted out, we can mask for the lower byte.

Thanks Andrew