[alsa-devel] [PATCH] ASoC: sgtl5000: Do not read registers prior to turning on the supplies
Commit b871f1ad (ASoC: sgtl5000: Read SGTL5000_CHIP_ID in i2c_probe()) placed the code for reading the codec revision prior to turning on the power supplies.
Even though this works on some systems that always have the codec power supplies enabled, this is not correct, so revert this commit.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- sound/soc/codecs/sgtl5000.c | 39 +++++++++++++++------------------------ 1 file changed, 15 insertions(+), 24 deletions(-)
diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c index 1c3b20f..788af6c 100644 --- a/sound/soc/codecs/sgtl5000.c +++ b/sound/soc/codecs/sgtl5000.c @@ -1275,7 +1275,7 @@ static int sgtl5000_replace_vddd_with_ldo(struct snd_soc_codec *codec)
static int sgtl5000_enable_regulators(struct snd_soc_codec *codec) { - int reg; + u16 reg; int ret; int rev; int i; @@ -1303,17 +1303,23 @@ static int sgtl5000_enable_regulators(struct snd_soc_codec *codec) /* wait for all power rails bring up */ udelay(10);
- /* - * workaround for revision 0x11 and later, - * roll back to use internal LDO - */ - - ret = regmap_read(sgtl5000->regmap, SGTL5000_CHIP_ID, ®); - if (ret) + /* read chip information */ + reg = snd_soc_read(codec, SGTL5000_CHIP_ID); + if (((reg & SGTL5000_PARTID_MASK) >> SGTL5000_PARTID_SHIFT) != + SGTL5000_PARTID_PART_ID) { + dev_err(codec->dev, + "Device with ID register %x is not a sgtl5000\n", reg); + ret = -ENODEV; goto err_regulator_disable; + }
rev = (reg & SGTL5000_REVID_MASK) >> SGTL5000_REVID_SHIFT; + dev_info(codec->dev, "sgtl5000 revision 0x%x\n", rev);
+ /* + * workaround for revision 0x11 and later, + * roll back to use internal LDO + */ if (external_vddd && rev >= 0x11) { /* disable all regulator first */ regulator_bulk_disable(ARRAY_SIZE(sgtl5000->supplies), @@ -1497,7 +1503,7 @@ static int sgtl5000_i2c_probe(struct i2c_client *client, const struct i2c_device_id *id) { struct sgtl5000_priv *sgtl5000; - int ret, reg, rev; + int ret;
sgtl5000 = devm_kzalloc(&client->dev, sizeof(struct sgtl5000_priv), GFP_KERNEL); @@ -1511,21 +1517,6 @@ static int sgtl5000_i2c_probe(struct i2c_client *client, return ret; }
- /* read chip information */ - ret = regmap_read(sgtl5000->regmap, SGTL5000_CHIP_ID, ®); - if (ret) - return ret; - - if (((reg & SGTL5000_PARTID_MASK) >> SGTL5000_PARTID_SHIFT) != - SGTL5000_PARTID_PART_ID) { - dev_err(&client->dev, - "Device with ID register %x is not a sgtl5000\n", reg); - return -ENODEV; - } - - rev = (reg & SGTL5000_REVID_MASK) >> SGTL5000_REVID_SHIFT; - dev_info(&client->dev, "sgtl5000 revision 0x%x\n", rev); - i2c_set_clientdata(client, sgtl5000);
/* Ensure sgtl5000 will start with sane register values */
On Tue, May 28, 2013 at 11:04:18AM -0300, Fabio Estevam wrote:
Commit b871f1ad (ASoC: sgtl5000: Read SGTL5000_CHIP_ID in i2c_probe()) placed the code for reading the codec revision prior to turning on the power supplies.
Even though this works on some systems that always have the codec power supplies enabled, this is not correct, so revert this commit.
It seems like a better fix for this is to just enable the supplies while doing the device identification?
Hi Mark, Fabio,
On Tue, May 28, 2013 at 11:04:18AM -0300, Fabio Estevam wrote:
Commit b871f1ad (ASoC: sgtl5000: Read SGTL5000_CHIP_ID in i2c_probe()) placed the code for reading the codec revision prior to turning on the power supplies.
Even though this works on some systems that always have the codec power supplies enabled, this is not correct, so revert this commit.
It seems like a better fix for this is to just enable the supplies while doing the device identification?
This patch does kinda fix it for me, but the system takes quite some time to init the soundcard now (a few seconds). After reverting these two patches, the soundcard works just fine (like before):
ASoC: sgtl5000: Fix driver probe after reset ASoC: sgtl5000: Read SGTL5000_CHIP_ID in i2c_probe()
Best regards, Marek Vasut
Hi Marek,
(Sorry for the top-posting here)
There is a delay of 23 seconds, which is 1 second for each sgtl500- register write.
This is an I2C issue and we have already talked about this on the linux-arm-kernel list.
Alexandre Belloni also sees this 1 second on another I2C device connected to mx28.
Regards,
Fabio Estevam ________________________________________ From: Marek Vasut [marex@denx.de] Sent: Thursday, May 30, 2013 5:36 PM To: alsa-devel@alsa-project.org Cc: Mark Brown; Estevam Fabio-R49496 Subject: Re: [alsa-devel] [PATCH] ASoC: sgtl5000: Do not read registers prior to turning on the supplies
Hi Mark, Fabio,
On Tue, May 28, 2013 at 11:04:18AM -0300, Fabio Estevam wrote:
Commit b871f1ad (ASoC: sgtl5000: Read SGTL5000_CHIP_ID in i2c_probe()) placed the code for reading the codec revision prior to turning on the power supplies.
Even though this works on some systems that always have the codec power supplies enabled, this is not correct, so revert this commit.
It seems like a better fix for this is to just enable the supplies while doing the device identification?
This patch does kinda fix it for me, but the system takes quite some time to init the soundcard now (a few seconds). After reverting these two patches, the soundcard works just fine (like before):
ASoC: sgtl5000: Fix driver probe after reset ASoC: sgtl5000: Read SGTL5000_CHIP_ID in i2c_probe()
Best regards, Marek Vasut
Hello Fabio,
Hi Marek,
(Sorry for the top-posting here)
There is a delay of 23 seconds, which is 1 second for each sgtl500- register write.
This is an I2C issue and we have already talked about this on the linux-arm-kernel list.
Alexandre Belloni also sees this 1 second on another I2C device connected to mx28.
There was no problem without these patches though. With your patches, I see NAK happening on the I2C lines upon first 2-byte write.
Regards,
Fabio Estevam ________________________________________ From: Marek Vasut [marex@denx.de] Sent: Thursday, May 30, 2013 5:36 PM To: alsa-devel@alsa-project.org Cc: Mark Brown; Estevam Fabio-R49496 Subject: Re: [alsa-devel] [PATCH] ASoC: sgtl5000: Do not read registers prior to turning on the supplies
Hi Mark, Fabio,
On Tue, May 28, 2013 at 11:04:18AM -0300, Fabio Estevam wrote:
Commit b871f1ad (ASoC: sgtl5000: Read SGTL5000_CHIP_ID in i2c_probe()) placed the code for reading the codec revision prior to turning on the power supplies.
Even though this works on some systems that always have the codec power supplies enabled, this is not correct, so revert this commit.
It seems like a better fix for this is to just enable the supplies while doing the device identification?
This patch does kinda fix it for me, but the system takes quite some time to init the soundcard now (a few seconds). After reverting these two patches, the soundcard works just fine (like before):
ASoC: sgtl5000: Fix driver probe after reset ASoC: sgtl5000: Read SGTL5000_CHIP_ID in i2c_probe()Best regards, Marek Vasut
Best regards, Marek Vasut
On Fri, May 31, 2013 at 12:32 PM, Marek Vasut marex@denx.de wrote:
There was no problem without these patches though. With your patches, I see NAK happening on the I2C lines upon first 2-byte write.
Yes, but prior to these patches there were no register writes in sgtl5000.
These addditional writes does work and solve the reset issues on mx6qsabrelite/mx51evk.
It is only on mx28evk that we have this timeout issue.
I think we need to turn on the SAIF clock (that connects to the sgtl5000 MCLK) prior to doing the I2C writes.
Regards,
Fabio Estevam
Hi Fabio,
On Fri, May 31, 2013 at 12:32 PM, Marek Vasut marex@denx.de wrote:
There was no problem without these patches though. With your patches, I see NAK happening on the I2C lines upon first 2-byte write.
Yes, but prior to these patches there were no register writes in sgtl5000.
How would volume adjustment work with no writes ? ;-)
These addditional writes does work and solve the reset issues on mx6qsabrelite/mx51evk.
It is only on mx28evk that we have this timeout issue.
I think we need to turn on the SAIF clock (that connects to the sgtl5000 MCLK) prior to doing the I2C writes.
Ah, that's _very_ likely. I think the chip will NAK I2C communication without having clock supplied to it. I did look into this stuff with an LA yesterday night and I saw the 2-byte write followed by I2C NAK.
Best regards, Marek Vasut
On Fri, May 31, 2013 at 12:45 PM, Marek Vasut marex@denx.de wrote:
Ah, that's _very_ likely. I think the chip will NAK I2C communication without having clock supplied to it. I did look into this stuff with an LA yesterday night and I saw the 2-byte write followed by I2C NAK.
Yes, I haven't had a chance to try enabling the saif clock earlier and I am currently out of office.
Thanks,
Fabio Estevam
Hi Fabio,
On Fri, May 31, 2013 at 12:45 PM, Marek Vasut marex@denx.de wrote:
Ah, that's _very_ likely. I think the chip will NAK I2C communication without having clock supplied to it. I did look into this stuff with an LA yesterday night and I saw the 2-byte write followed by I2C NAK.
Yes, I haven't had a chance to try enabling the saif clock earlier and I am currently out of office.
Send me a patch if you have time and I'll test it.
Best regards, Marek Vasut
participants (5)
-
Estevam Fabio-R49496 -
Fabio Estevam -
Fabio Estevam -
Marek Vasut -
Mark Brown