[Gta04-owner] hw routing audio patch removed in 3.7?
andreas at kemnade.info
Sat Jun 8 21:09:44 CEST 2013
On Sat, 2013-06-08 at 18:43 +0200, Dr. H. Nikolaus Schaller wrote:
> Am 08.06.2013 um 17:14 schrieb Andreas Kemnade:
> > Hi,
> > On Sat, 2013-06-08 at 14:30 +0200, Dr. H. Nikolaus Schaller wrote:
> >> Hi,
> >> Am 08.06.2013 um 14:13 schrieb Andreas Kemnade:
> >>> Hi,
> >>> i am looking through the commit logs and see that Benjamin Deering has
> >>> sent my hardware routing patch again (that is for example here:
> >>> https://github.com/radekp/linux-2.6/commit/f43ce5c444de7db988ad214257f4a6ac0e49308d )
> >>> in January and it was applied to 3.7. Then it was removed due to white
> >>> noise.
> >> Yes, I tried and removed it again.
> >>> Under which circumstances there was white noise?
> >> It simply played white noise on the handsfree speaker after using the
> >> speaker through aplayer for the first time and I did not find any alsa
> >> control that influenced it.
> >> If I remember correctly, it did not disappear until reboot.
> > I added it again, and... i had white noise.
> >> Removing the patch completely made it work again.
> > looking at my mixer settings, i found the AVADC clock priority setting
> > not set to hifi. Changing that disables the white noise. But that is
> > nothing new and the reason is quite obvious.
> > Do you have still your mixer settings causing the trouble?
> Hm. I think I had a fresh installation with default settings, i.e. no state file.
I removed my state file, then rebooted, and most is muted, i hear
nothing. I tried then to unmute stuff and then even with wrong AVADC
everything was fine.
> Is this AVADC priority new?
> >>> So maybe i can
> >>> fix things.
> >> That would be great!
> >> One thing we should fix in this step as well is that there is a dai function
> >> to set the McBSP to tristate .
> > That seems not to be implemented for the McBSP. So it has first to be
> > implemented there.
> Is it really missing or hidden deeply in the OMAP2/3 code? If yes, then we
> should add it for the McBSP since it is IMHO the canonical way to do it.
I searched for a struct snd_soc_dai_ops with a .set_tristate entry.
> >> I.e. we should not work directly with Pinmux in this patch. This
> >> may even be the reason for the white noise (there are differences
> >> in the pinmux system in different kernel versions).
> > Hmm, so put the conflicting McBSP into the platform data and calling the
> > tristate function instead of the pinmux thing? That is no twl4030
> > specific code, so somehow it still feels a bit strange to have it there.
> Yes, it is difficult to pinpoint the correct location of such code since
> it involves three DAI links... And only the platform file should know it.
> But since we have such a switching features anyways, I think (optionally)
> adding a "conflicting" DAI link to the platform data of the twl4030 would be
> the most appropriate way.
I think about two possibilities:
1.reflect every link with a corresponding link structure (the twl<->gsm
link has no structure at the moment). If something is not linked, it
should shut up aka be tristated.
Add infrastructure to switch link connection. The board file should know
about possible connections.
2. make it a boot-time setting, just in the board file, controlled by a
kernel parameter (for A3 compatibility testing) and hardware revision
More information about the Gta04-owner