SGTL5000

SGTL5000

[Erik Friesen]

I was sort of directed to this list from linux-arm.

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 gets 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 initialize routine?

I am using the embeddedarm repo as a base kernel.  sgtl5000.c has been
updated to include
ret = sgtl5000_fill_defaults(sgtl5000);
but the base kernel is 3.10.53.  However, the riotboard runs 4.3 with
similar results.

Re: SGTL5000

[Erik Friesen]

Is this list active?  Can someone at least confirm the alsa-devel
filter isn't kicking my emails out?

I have a couple suggested changes to sgtl5000.c.

On Wed, Feb 3, 2016 at 12:06 PM, Erik Friesen <friesendrywall@gmail.com> wrote:
> I was sort of directed to this list from linux-arm.
>
> 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 gets 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 initialize routine?
>
> I am using the embeddedarm repo as a base kernel.  sgtl5000.c has been
> updated to include
> ret = sgtl5000_fill_defaults(sgtl5000);
> but the base kernel is 3.10.53.  However, the riotboard runs 4.3 with
> similar results.

Re: SGTL5000

[Erik Friesen]

Test email
On Feb 6, 2016 8:52 AM, "Erik Friesen" <friesendrywall@gmail.com> wrote:

> Is this list active?  Can someone at least confirm the alsa-devel
> filter isn't kicking my emails out?
>
> I have a couple suggested changes to sgtl5000.c.
>
> On Wed, Feb 3, 2016 at 12:06 PM, Erik Friesen <friesendrywall@gmail.com>
> wrote:
> > I was sort of directed to this list from linux-arm.
> >
> > 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 gets 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 initialize routine?
> >
> > I am using the embeddedarm repo as a base kernel.  sgtl5000.c has been
> > updated to include
> > ret = sgtl5000_fill_defaults(sgtl5000);
> > but the base kernel is 3.10.53.  However, the riotboard runs 4.3 with
> > similar results.
>