[Gta04-owner] hw routing audio patch removed in 3.7?

Dr. H. Nikolaus Schaller hns at goldelico.com
Sat Jun 8 18:43:49 CEST 2013

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.

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 [1].
> 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.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.

> But using a tristate function is a step forward.

I will have a look if I can find more about this issue on the McBSP side.


More information about the Gta04-owner mailing list