SGTL5000: external VDDD with linux codec driver

[alexanderstein]

The datasheet and the errata say the SGTL5000 should be connected to an external VDDD supply.

The linux driver (both mainline and the one in the QorIQ-SDK 1.7) try to use it. But with codec revision >= 0x11 it falls back to internal LDO.

It seems that the sgtl5000 driver did this from the first version integrated into linux mainline. But I could not find any documentation why this should be done (starting from this specific revision).

This topic seems to be referred by others too: e.g. Re: SGTL5000 hangs I2C bus after reset

So my questions:

• For which reason the internal LDO instead of external VDDD should be used on revisions >=0x11?
• What is the correct codec configuration regarding VDDD?
• Are there any driver patches available? Especially regarding QorIQ-SDK. Maybe I can also backport them from mainline.

Thanks,

Alexander Stein

[EricNelson]

Hi Alexander,

I posted some patches in late February to fix regulator support:

     The Alsa-devel February 2015 Archive by thread

They're also available in a more convenient form here:

     https://patchwork.kernel.org/project/alsa-devel/list/?submitter=48031

Changes were requested, and I haven't yet addressed them all, but something like this is needed if you'll be controlling the VDDIO and/or VDDA rails dynamically. Otherwise, the regulators will only be enabled in the codec portion of the driver and I2C accesses will fail.

If you're only supplying VDDD externally, the regulator re-work isn't really needed, since this rail isn't needed for initial I2C access.

[andrewparlane]

Hi Eric,

I've been trying to use your patches, but as Alexander said, they don't apply to older kernels. Could you show my a commit log for the relevant files, so I can work out what needs to be cherry picked in first. I'm based off boundary devices 3.10.17 kernel.

Thanks,

Andrew

[alexanderstein]

Hi Eric,

with the answer of igor in mind I tried (some of) your patches and it seems to me that they are required when using external Vddd on chip revisions >= 0x11. As I'm stuck on an older kernel, 3.12 from QorIQ SDK :smileysad:, I had to cherry-pick some patches from upstream until I could pick your patches.

[andreascian]

I'm still wondering why when chip revision >=0x11 the VDDD internal LDO in enabled anyway.

All official confirmation I have from FSL is ALWAYS to use an external VDDD power supply/regulator, independently from the chip revision.

Does anybody here (  igorpadykov​ alexanderstein​ EricNelson​) know the reason why of this special handling for rev >=0x11 that we find on ALL kernel (official FSL, community, mainline) around the world?

Kind Regards,

Andrea

[falstaff]

FWIW, I am also wondering what the Linux code is doing here. It really seems completely contradicting to what the errata is saying. This is still part of the official NXP GA 2.0.0 BSP for i.MX 6.

Anyway, given that EricNelson changed it now in mainline, I can only guess that the code is/was just wrong?

[timjaacks]

The special revision handling is in the driver since the very first version, at least on the mainline kernel:

linux/sound/soc/codecs/sgtl5000.c at master · torvalds/linux · GitHub

[timjaacks]

Hi Andrea,

I just stumbled upon this code section and asked myself the same question. Have you found out why the code uses the internal LDO for revision >= 0x11?

If not, can anybody from Freescale comment on this, please?

Regards,

Tim

[alexanderstein]

Hi Eric,

thanks for your reply. I don't need to control any VDD* dynamically. Our board has them connected statically. But I'll keep your patches in mind.

But I am currently wondering what is correct: Use external VDDD on newer designs or use internal LDO (and disable external VDDD usage) for revisions >=0x11? And is there any official documentation for that?

It is contradictory to me to use external VDDD for newer designs and disable this external power supply for all revisions >=0x11 which seem to be the newer ones. My Revision here is 0x11. Am I'm missing something?

[igorpadykov]

Hi Alexander

recommended to use external VDDD as describes ER1

SGTL5000ER - this is official documentation and confirmed by Jose on

Re: SGTL5000 hangs I2C bus after reset

Best regards

igor