SGTL5000 misc

SGTL5000 misc

[Erik Friesen]

First post on the list here..

I have been working with an embeddedarm ts4900 and built a baseboard
that uses the sgtl5000.  I also have worked with the RiotBoard, which
uses the same chip, both using the i.mx6 arm.  I find that
occasionally the sgtl5000 is resetting, and there is no way to bring
it back online.  As near as I can tell, the i2c bus comes back alive,
for example alsamixer communicates fine, coms happen on the i2c bus
per scope.  However, its obvious the chip never got re initialized by
how it acts.

I know the thing shouldn't reset, that is the primary problem, but I
still want some backup method.  Its probably due to ground bounce from
a non earth grounded setup.  It could be that using the external
regulator will help, we will see.

Is there a suggestion on a way the sgtl5000.c could be extended to
support some sort of re init routine?

I am using the embeddedarm repo as a base.

SGTL5000 misc

[Fabio Estevam]

On Wed, Feb 3, 2016 at 11:42 AM, Erik Friesen <friesendrywall@gmail.com> wrote:
> First post on the list here..
>
> I have been working with an embeddedarm ts4900 and built a baseboard
> that uses the sgtl5000.  I also have worked with the RiotBoard, which
> uses the same chip, both using the i.mx6 arm.  I find that
> occasionally the sgtl5000 is resetting, and there is no way to bring
> it back online.  As near as I can tell, the i2c bus comes back alive,
> for example alsamixer communicates fine, coms happen on the i2c bus
> per scope.  However, its obvious the chip never got re initialized by
> how it acts.
>
> I know the thing shouldn't reset, that is the primary problem, but I
> still want some backup method.  Its probably due to ground bounce from
> a non earth grounded setup.  It could be that using the external
> regulator will help, we will see.
>
> Is there a suggestion on a way the sgtl5000.c could be extended to
> support some sort of re init routine?
>
> I am using the embeddedarm repo as a base.

Which kernel version do you use?

SGTL5000 misc

[Erik Friesen]

[    0.000000] Linux version 3.10.53-gf3f6648-dirty (root at friesen-nas)
(gcc version 4.8.2 (GCC) ) #163 SMP PREEMPT Mon Feb 1 18:12:31 EST
2016

Its a bit unclear here, am I supposed to reply only to
linux-arm-kernel at list.infraread.org?

On Wed, Feb 3, 2016 at 9:23 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Wed, Feb 3, 2016 at 11:42 AM, Erik Friesen <friesendrywall@gmail.com> wrote:
>> First post on the list here..
>>
>> I have been working with an embeddedarm ts4900 and built a baseboard
>> that uses the sgtl5000.  I also have worked with the RiotBoard, which
>> uses the same chip, both using the i.mx6 arm.  I find that
>> occasionally the sgtl5000 is resetting, and there is no way to bring
>> it back online.  As near as I can tell, the i2c bus comes back alive,
>> for example alsamixer communicates fine, coms happen on the i2c bus
>> per scope.  However, its obvious the chip never got re initialized by
>> how it acts.
>>
>> I know the thing shouldn't reset, that is the primary problem, but I
>> still want some backup method.  Its probably due to ground bounce from
>> a non earth grounded setup.  It could be that using the external
>> regulator will help, we will see.
>>
>> Is there a suggestion on a way the sgtl5000.c could be extended to
>> support some sort of re init routine?
>>
>> I am using the embeddedarm repo as a base.
>
> Which kernel version do you use?

SGTL5000 misc

[Fabio Estevam]

On Wed, Feb 3, 2016 at 12:33 PM, Erik Friesen <friesendrywall@gmail.com> wrote:
> [    0.000000] Linux version 3.10.53-gf3f6648-dirty (root at friesen-nas)

That's a very old kernel. You should try something newer like 4.4.

We had issues with sgtl5000 codec that were fixed with this commit:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/sound/soc/codecs/sgtl5000.c?id=af8ee11209e749c75eabf32b2a4ca631f396acf8

> Its a bit unclear here, am I supposed to reply only to
> linux-arm-kernel at list.infraread.org?

It is fine to reply to all.

SGTL5000 misc

[Erik Friesen]

It appears sgtl5000.c is patched the same in my kernel as the commit mentioned.

The problem the way I see it, is that there is no mechanism to deal
with a reboot on the codec itself.

This alsa stuff has too many layers.  At least coming from a non os
embedded angle it seems that way.

On Wed, Feb 3, 2016 at 9:38 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Wed, Feb 3, 2016 at 12:33 PM, Erik Friesen <friesendrywall@gmail.com> wrote:
>> [    0.000000] Linux version 3.10.53-gf3f6648-dirty (root at friesen-nas)
>
> That's a very old kernel. You should try something newer like 4.4.
>
> We had issues with sgtl5000 codec that were fixed with this commit:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/sound/soc/codecs/sgtl5000.c?id=af8ee11209e749c75eabf32b2a4ca631f396acf8
>
>> Its a bit unclear here, am I supposed to reply only to
>> linux-arm-kernel at list.infraread.org?
>
> It is fine to reply to all.

SGTL5000 misc

[Fabio Estevam]

On Wed, Feb 3, 2016 at 12:46 PM, Erik Friesen <friesendrywall@gmail.com> wrote:
> It appears sgtl5000.c is patched the same in my kernel as the commit mentioned.
>
> The problem the way I see it, is that there is no mechanism to deal
> with a reboot on the codec itself.

There is no reset line nor reset command on the sgtl5000.

> This alsa stuff has too many layers.  At least coming from a non os
> embedded angle it seems that way.

I would suggest you to try 4.4.1 and if you still see an issue with
the codec, then report it back to the alsa-devel at alsa-project.org
list.

SGTL5000 misc

[Erik Friesen]

There is no difference in code that I can tell between the two.  I am
not asking to have this fixed, rather just some ideas on how I can
implement this. If alsa-devel list is the preferred asking place, I'll
go there.

The riotboard used kernel 4.3.0-rc2-00019-gbcee19f with the same results.

On Wed, Feb 3, 2016 at 9:51 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Wed, Feb 3, 2016 at 12:46 PM, Erik Friesen <friesendrywall@gmail.com> wrote:
>> It appears sgtl5000.c is patched the same in my kernel as the commit mentioned.
>>
>> The problem the way I see it, is that there is no mechanism to deal
>> with a reboot on the codec itself.
>
> There is no reset line nor reset command on the sgtl5000.
>
>> This alsa stuff has too many layers.  At least coming from a non os
>> embedded angle it seems that way.
>
> I would suggest you to try 4.4.1 and if you still see an issue with
> the codec, then report it back to the alsa-devel at alsa-project.org
> list.

SGTL5000 misc

[Erik Friesen]

Anyway, I think something like this should be added to sgtl5000.c

static int sgtl5000_enable_regulators(struct snd_soc_codec *codec) {
 int reg;
 int ret;
 int rev;
 int i;
 const u32 *property;
 int external_vddd = 0;
 int use_ext_vdd = 0;
 struct sgtl5000_priv *sgtl5000 = snd_soc_codec_get_drvdata(codec);

 for (i = 0; i < ARRAY_SIZE(sgtl5000->supplies); i++)
  sgtl5000->supplies[i].supply = supply_names[i];

 //allow dtb to select option to use vddd external per errata
 //VDDD-external = <1>;
 ++ property = of_get_property(codec->dev->of_node, "VDDD-external", NULL);
 ++ if(property != NULL){
 ++ dev_info(codec->dev, "DTB = use VDDD %x\n", *property);
 ++ use_ext_vdd = 1;
 ++ }
 ret = regulator_bulk_get(codec->dev, ARRAY_SIZE(sgtl5000->supplies),
sgtl5000->supplies);
 if (!ret) {
  external_vddd = 1;
 } else {
  ret = sgtl5000_replace_vddd_with_ldo(codec);
 if (ret)
 return ret;
 }

 ret = regulator_bulk_enable(ARRAY_SIZE(sgtl5000->supplies),
  sgtl5000->supplies);
if (ret)
goto err_regulator_free;

/* 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, &reg);
if (ret)
goto err_regulator_disable;

rev = (reg & SGTL5000_REVID_MASK) >> SGTL5000_REVID_SHIFT;

--if (external_vddd && rev >= 0x11)
++if (external_vddd && rev >= 0x11 && !use_ext_vdd) {
/* disable all regulator first */

On Wed, Feb 3, 2016 at 10:11 AM, Erik Friesen <friesendrywall@gmail.com> wrote:
> There is no difference in code that I can tell between the two.  I am
> not asking to have this fixed, rather just some ideas on how I can
> implement this. If alsa-devel list is the preferred asking place, I'll
> go there.
>
> The riotboard used kernel 4.3.0-rc2-00019-gbcee19f with the same results.
>
> On Wed, Feb 3, 2016 at 9:51 AM, Fabio Estevam <festevam@gmail.com> wrote:
>> On Wed, Feb 3, 2016 at 12:46 PM, Erik Friesen <friesendrywall@gmail.com> wrote:
>>> It appears sgtl5000.c is patched the same in my kernel as the commit mentioned.
>>>
>>> The problem the way I see it, is that there is no mechanism to deal
>>> with a reboot on the codec itself.
>>
>> There is no reset line nor reset command on the sgtl5000.
>>
>>> This alsa stuff has too many layers.  At least coming from a non os
>>> embedded angle it seems that way.
>>
>> I would suggest you to try 4.4.1 and if you still see an issue with
>> the codec, then report it back to the alsa-devel at alsa-project.org
>> list.

SGTL5000 misc

[Fabio Estevam]

On Wed, Feb 3, 2016 at 8:05 PM, Erik Friesen <friesendrywall@gmail.com> wrote:
> Anyway, I think something like this should be added to sgtl5000.c

Yes, please send a formal patch for it.

SGTL5000 misc

[Erik Friesen]

There is another issue here, but when I have this connected to
external power, it won't start the card on every other boot.

With the code below, it seems to start every time.  If I don't skip,
it dies on #8, which is the write of 0x7060 to CHIP_ANA_POWER

This embeddedarm board supposedly power cycles the regulators, don't
know if that is a factor or not.  The board finishes powerup 0x4060,
but comes back on reboot at the reset value of 0x7060

static int sgtl5000_fill_defaults(struct sgtl5000_priv *sgtl5000)
{
  int i, ret, val, index;
  int reg;
  for (i = 0; i < ARRAY_SIZE(sgtl5000_reg_defaults); i++) {
    val = sgtl5000_reg_defaults[i].def;
    index = sgtl5000_reg_defaults[i].reg;
    ret = regmap_read(sgtl5000->regmap, index, &reg);
    if (reg != val) {
      ret = regmap_write(sgtl5000->regmap, index, val);
    } else {
     printk(KERN_INFO "SGTL5000 probe skipped at %i with OE val of
%x\n", i, reg);
    }
  if (ret) {
    printk(KERN_WARNING "SGTL5000 probe failed at %i with OE val of
%x\n", i, reg);
    return ret;
    }
  }

  return 0;
}

On Wed, Feb 3, 2016 at 5:20 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Wed, Feb 3, 2016 at 8:05 PM, Erik Friesen <friesendrywall@gmail.com> wrote:
>> Anyway, I think something like this should be added to sgtl5000.c
>
> Yes, please send a formal patch for it.

SGTL5000 misc

[Fabio Estevam]

On Fri, Feb 5, 2016 at 1:08 AM, Erik Friesen <friesendrywall@gmail.com> wrote:
> There is another issue here, but when I have this connected to
> external power, it won't start the card on every other boot.
>
> With the code below, it seems to start every time.  If I don't skip,
> it dies on #8, which is the write of 0x7060 to CHIP_ANA_POWER
>
> This embeddedarm board supposedly power cycles the regulators, don't
> know if that is a factor or not.  The board finishes powerup 0x4060,
> but comes back on reboot at the reset value of 0x7060

It would be nice if you could send a patch to alsa-devel mailing list,
so that this can be properly reviewed there.

SGTL5000 misc

[Erik Friesen]

Well, I have posted a thing or two there, not sure if the mailing list
is even working, as I haven't received any replies.

On Fri, Feb 5, 2016 at 5:00 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Fri, Feb 5, 2016 at 1:08 AM, Erik Friesen <friesendrywall@gmail.com> wrote:
>> There is another issue here, but when I have this connected to
>> external power, it won't start the card on every other boot.
>>
>> With the code below, it seems to start every time.  If I don't skip,
>> it dies on #8, which is the write of 0x7060 to CHIP_ANA_POWER
>>
>> This embeddedarm board supposedly power cycles the regulators, don't
>> know if that is a factor or not.  The board finishes powerup 0x4060,
>> but comes back on reboot at the reset value of 0x7060
>
> It would be nice if you could send a patch to alsa-devel mailing list,
> so that this can be properly reviewed there.

SGTL5000 misc

[Fabio Estevam]

On Sat, Feb 6, 2016 at 3:22 PM, Erik Friesen <friesendrywall@gmail.com> wrote:
> Well, I have posted a thing or two there, not sure if the mailing list
> is even working, as I haven't received any replies.

I haven't seen your patches there. You need to subscribe to alsa-devel first.

SGTL5000 misc

[Erik Friesen]

I am subscribed and getting emails from the list, not sure what is up.

On Sat, Feb 6, 2016 at 12:33 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Sat, Feb 6, 2016 at 3:22 PM, Erik Friesen <friesendrywall@gmail.com> wrote:
>> Well, I have posted a thing or two there, not sure if the mailing list
>> is even working, as I haven't received any replies.
>
> I haven't seen your patches there. You need to subscribe to alsa-devel first.