* SGTL5000 misc @ 2016-02-03 13:42 Erik Friesen 2016-02-03 14:23 ` Fabio Estevam 0 siblings, 1 reply; 14+ messages in thread From: Erik Friesen @ 2016-02-03 13:42 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* SGTL5000 misc 2016-02-03 13:42 SGTL5000 misc Erik Friesen @ 2016-02-03 14:23 ` Fabio Estevam 2016-02-03 14:33 ` Erik Friesen 0 siblings, 1 reply; 14+ messages in thread From: Fabio Estevam @ 2016-02-03 14:23 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 14+ messages in thread
* SGTL5000 misc 2016-02-03 14:23 ` Fabio Estevam @ 2016-02-03 14:33 ` Erik Friesen 2016-02-03 14:38 ` Fabio Estevam 0 siblings, 1 reply; 14+ messages in thread From: Erik Friesen @ 2016-02-03 14:33 UTC (permalink / raw) To: linux-arm-kernel [ 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? ^ permalink raw reply [flat|nested] 14+ messages in thread
* SGTL5000 misc 2016-02-03 14:33 ` Erik Friesen @ 2016-02-03 14:38 ` Fabio Estevam 2016-02-03 14:46 ` Erik Friesen 0 siblings, 1 reply; 14+ messages in thread From: Fabio Estevam @ 2016-02-03 14:38 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* SGTL5000 misc 2016-02-03 14:38 ` Fabio Estevam @ 2016-02-03 14:46 ` Erik Friesen 2016-02-03 14:51 ` Fabio Estevam 0 siblings, 1 reply; 14+ messages in thread From: Erik Friesen @ 2016-02-03 14:46 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* SGTL5000 misc 2016-02-03 14:46 ` Erik Friesen @ 2016-02-03 14:51 ` Fabio Estevam 2016-02-03 15:11 ` Erik Friesen 0 siblings, 1 reply; 14+ messages in thread From: Fabio Estevam @ 2016-02-03 14:51 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* SGTL5000 misc 2016-02-03 14:51 ` Fabio Estevam @ 2016-02-03 15:11 ` Erik Friesen 2016-02-03 22:05 ` Erik Friesen 0 siblings, 1 reply; 14+ messages in thread From: Erik Friesen @ 2016-02-03 15:11 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* SGTL5000 misc 2016-02-03 15:11 ` Erik Friesen @ 2016-02-03 22:05 ` Erik Friesen 2016-02-03 22:20 ` Fabio Estevam 0 siblings, 1 reply; 14+ messages in thread From: Erik Friesen @ 2016-02-03 22:05 UTC (permalink / raw) To: linux-arm-kernel 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, ®); 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* SGTL5000 misc 2016-02-03 22:05 ` Erik Friesen @ 2016-02-03 22:20 ` Fabio Estevam 2016-02-05 3:08 ` Erik Friesen 0 siblings, 1 reply; 14+ messages in thread From: Fabio Estevam @ 2016-02-03 22:20 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* SGTL5000 misc 2016-02-03 22:20 ` Fabio Estevam @ 2016-02-05 3:08 ` Erik Friesen 2016-02-05 10:00 ` Fabio Estevam 0 siblings, 1 reply; 14+ messages in thread From: Erik Friesen @ 2016-02-05 3:08 UTC (permalink / raw) To: linux-arm-kernel 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, ®); 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* SGTL5000 misc 2016-02-05 3:08 ` Erik Friesen @ 2016-02-05 10:00 ` Fabio Estevam 2016-02-06 17:22 ` Erik Friesen 0 siblings, 1 reply; 14+ messages in thread From: Fabio Estevam @ 2016-02-05 10:00 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* SGTL5000 misc 2016-02-05 10:00 ` Fabio Estevam @ 2016-02-06 17:22 ` Erik Friesen 2016-02-06 17:33 ` Fabio Estevam 0 siblings, 1 reply; 14+ messages in thread From: Erik Friesen @ 2016-02-06 17:22 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* SGTL5000 misc 2016-02-06 17:22 ` Erik Friesen @ 2016-02-06 17:33 ` Fabio Estevam 2016-02-06 19:29 ` Erik Friesen 0 siblings, 1 reply; 14+ messages in thread From: Fabio Estevam @ 2016-02-06 17:33 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* SGTL5000 misc 2016-02-06 17:33 ` Fabio Estevam @ 2016-02-06 19:29 ` Erik Friesen 0 siblings, 0 replies; 14+ messages in thread From: Erik Friesen @ 2016-02-06 19:29 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-02-06 19:29 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-02-03 13:42 SGTL5000 misc Erik Friesen 2016-02-03 14:23 ` Fabio Estevam 2016-02-03 14:33 ` Erik Friesen 2016-02-03 14:38 ` Fabio Estevam 2016-02-03 14:46 ` Erik Friesen 2016-02-03 14:51 ` Fabio Estevam 2016-02-03 15:11 ` Erik Friesen 2016-02-03 22:05 ` Erik Friesen 2016-02-03 22:20 ` Fabio Estevam 2016-02-05 3:08 ` Erik Friesen 2016-02-05 10:00 ` Fabio Estevam 2016-02-06 17:22 ` Erik Friesen 2016-02-06 17:33 ` Fabio Estevam 2016-02-06 19:29 ` Erik Friesen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.