SGTL5000 hangs I2C bus after reset

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SGTL5000 hangs I2C bus after reset

Jump to solution
5,342 Views
PeterBergin
Contributor III

We have a custom board with i.MX6D and a SGTL5000 chip. On that board we are running Linux built with Yocto (1.6) and kernel 3.10.17. Recently we have experienced an issue when we play sound on SGTL5000 and after that do a reboot/reset (no power cycle). After that sequence the whole I2C bus is hanged because SGTL5000 holds the SDA low until next power cycle.

We have read the errata for the SGTL5000 that recommends the usage of external regulator for VDDD. In our design we have that design, VDDIO/VDDA is 3.3V and VDDD is 1.5V provided externally.

In Linux at boot time we see the trace:

sgtl5000 0-000a: Failed to get supply 'VDDD': -19

sgtl5000 0-000a: Using internal LDO instead of VDDD

The conclusion is that there is a missconfiguration in our system. Linux uses the internal LDO but we have external regulator for VDDD. To fix this issue we tried to change the DTB and added VDDD-supply but with no luck. To fix this issue we had to comment code in the driver to not use the internal LDO and then we get rid of the problem.

In the sgtl5000 driver (3.10.17_1.0.1_ga) on line 1064 we see this comment:

* 3. chip revision >=0x11 or not. If >=0x11, not use external vddd.

We have chip version 0x11 and because of this the driver (unpatched) will always use internal VDO for VDDD. That was the cause that our device tree change did not take effect and we had to patch the code to use external regulator for VDDD.

We see a glitch in the communication from Freescale. The errata and manual for SGTL5000 recommends to use external regulator for VDDD but the driver code force us to use the internal LDO for VDDD. We need to use the external regulator in our design otherwise we can not reset the board without hanging the I2C bus. How should we handle this? Comments on this?

Best regards,

/Peter

1 Solution
2,467 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Peter,

1. If I generate a patch against 3.19, are you able to test it?

2. If I recall correctly, John Weber backported my patch to 3.10.17:

https://github.com/wandboard-org/linux/commit/55d6dfb45481533ff1f5fe7a69a8fb7114d8fb1a

Regards,

Fabio Estevam

View solution in original post

0 Kudos
8 Replies
2,466 Views
reyes
NXP TechSupport
NXP TechSupport

Hi Peter,

The reason of why the driver code is not align with the mentioned in the reference manual and the errata document is because we recently discovered the errata related to the need of the external VDDD, the driver code is not yet updated with this issue, but I’m glad that you find out what was the cause of the issue and fix it for our application.


Have a great day,
Jose Reyes

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
2,466 Views
PeterBergin
Contributor III

Hi Jose,

after more work around this issue whe have got some more information and there seems to be two separate issues.

1) The driver is not using the external regulator for VDDD. I got your message that this is not yet implemented. (Errata for SGTL5000 was created 2013/06.)

2) The real issue we see is that the driver assumes that all registers are in their default state when starting and is not taking care of the warm reset case. This is a problem when the chip has switched over to the internal PLL for generating the clock and  the resulting behavior is that SGTL5000 chip holds the I2C data signal low, blocking all other communication on that I2C bus. The driver initialization will change the VDDD to the internal regulator and will overwrite the CHIP_ANA_POWER register and power down the PLL providing the clock.

Any ideas around the warm reset behaviour in the driver? Can anyone suggest the best patch to get rid of this faulty behaviour? We are using kernel 3.10.17_1.0.2.

Regards,

/Peter

0 Kudos
2,466 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Peter,

1) I will try to see if I can find any board here that provides an external power supply to sgtl500 VDDD, so that I can fix the driver.

2) For the reset case: I have sent the following fix to the mainline driver, which seems to fix the reset issue you describe:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/sound/soc/codecs/sgtl5000.c?i...

Regards,

Fabio Estevam

2,466 Views
PeterBergin
Contributor III

Hi Fabio,

thanks for your reply!

1) Great! Please let me know if we can help you. We have a custom board with external VDDD.

2) I have looked into your patch that solves the problem. Unfortunately the patch do not apply on 3.10.17.

In the patch you have called the sgtl5000_fill_defaults from sgtl5000_i2c_probe. As I could not see an easy way to do that in the 3.10.17 driver my suggestion is to put it in the sgtl5000_probe instead.

static int sgtl5000_probe(struct snd_soc_codec *codec)

{

  int ret;

  struct sgtl5000_priv *sgtl5000 = snd_soc_codec_get_drvdata(codec);

  /* setup i2c data ops */

  ret = snd_soc_codec_set_cache_io(codec, 16, 16, SND_SOC_I2C);

  if (ret < 0) {

  dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret);

  return ret;

  }

  /* Ensure sgtl5000 will start with sane register values */

  ret = sgtl5000_fill_defaults(codec);

  if (ret)

  return ret;

  ret = sgtl5000_enable_regulators(codec);

  if (ret)

  return ret;

What do you think of this suggestion? I also had to do some tweaks on the sgtl5000_fill_defaults function in order to get it working. I have tried this solution and it seems to work.

Regards,

/Peter

0 Kudos
2,468 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Peter,

1. If I generate a patch against 3.19, are you able to test it?

2. If I recall correctly, John Weber backported my patch to 3.10.17:

https://github.com/wandboard-org/linux/commit/55d6dfb45481533ff1f5fe7a69a8fb7114d8fb1a

Regards,

Fabio Estevam

0 Kudos
2,466 Views
PeterBergin
Contributor III

Hi Fabio,

1) Unfortunately we are not able to test against 3.19 kernel at the moment.

2) Thanks, that was really helpfull!

Best regards,

/Peter

0 Kudos
2,466 Views
fabio_estevam
NXP Employee
NXP Employee
2,466 Views
Danube
Contributor IV

Hi Fabio,

Does any Linux3.0.35_4.1.0_ga patch code to fixed this issue ?

0 Kudos