Hi Eric,
On 01/31/2015 12:02 AM, Eric Nelson wrote:
Hi Nikolay,
On 01/30/2015 02:50 PM, Nikolay Dimitrov wrote:
Hi Eric,
On 01/30/2015 11:31 PM, Fabio Estevam wrote:
Hi Eric,
On Fri, Jan 30, 2015 at 7:07 PM, Eric Nelson eric.nelson@boundarydevices.com wrote:
To quote from section 1.3.1 of the data sheet: The SGTL5000 has an internal reset that is deasserted 8 SYS_MCLK cycles after all power rails have been brought up. After this time, communication can start
... 1.0uS represents 8 SYS_MCLK cycles at the minimum 8.0 MHzSYS_MCLK.
Small detail: Should be us instead of uS.
FYI - If you're observing issues with communicating with SGTL5000 I2C, please make sure also that the chip has a valid clock signal on SYS_MCLK, otherwise it won't respond on I2C transactions (I2C will work with any SYS_MCLK in the range 8-27MHz).
Thanks for that, but the issue we're seeing and that made me spot this was a very intermittent problem (1 in many 1000's of boots) reported by a customer on our 3.10.17 code base.
We haven't been able to repeat the issue, but the failure is in the initial read of the CHIP_ID register (i.e. the first I2C access) and the docs clearly state that a 1us delay is needed.
I haven't found the commit that removed it, but earlier versions of sgtl5000.c had a udelay(10) before the first I2C access.
I see. Had similar issue with 3.10.17 (fsl), when sometimes on hot-reset the (imx6) I2C controller was somehow locked-up on boot and prevented the driver from reading CHIP_ID, and thus no sound at all. But on 3.17x/3.18x mainline kernels + riotboard, this initial SGTL5000 configuration is much much better, haven't seen cases when it doesn't detect the codec.
If you can reproduce the defect, you can try to exercise the I2C channel and see whether it still works at all.
I'm mentioning this because it's a different root-cause that has quite similar observable effect. Otherwise I truly agree that reset timings as per datasheet are very good to be followed.
Kind regards, Nikolay