[alsa-devel] SGTL5000
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.
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.
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.
participants (1)
-
Erik Friesen