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

Dr. H. Nikolaus Schaller hns at goldelico.com
Sat Jun 8 22:00:39 CEST 2013


Am 08.06.2013 um 21:09 schrieb Andreas Kemnade:

> Hi,
> 
> 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.

Hm. I will try again. I can't completely exclude some interference with some
other code changes.

> 
>> Is this AVADC priority new?
>> 
> 
> no.
> 
>>> 
>>>>> 
>>>>> 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 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. 

Sounds good.

> 
> Add infrastructure to switch link connection. The board file should know
> about possible connections. 

Yes. Would be probably the best thing.

But if it needs some special user-space code like the OMAP3 ISP
needing media-ctl it becomes a quite complex solution just for our problem
and likelihood to get it upstream is very low.

> 
> 2. make it a  boot-time setting, just in the board file, controlled by a
> kernel parameter (for A3 compatibility testing) and hardware revision
> info.

Hm. If it can't be switched by user space we get difficulties in testing
the McBSP connection. And - there are applications that want to have
software routing (e.g. digital answering machine or text2speech).

So what about 

3. a "simple" solution. Just keep it almost as it is but only move the
board dependent pinmux code to the board file and pass the address
of that function in the platform data?

Or 

4. we could implement the missing set_tristate for OMAP3 McBSPs...
This would benefit many other OMAP3 users and I would assume it
has the highest likelihood for upstream acceptance.

For the TWL it may already be there (or lost over time):

http://git.opencores.org/?a=commit&p=linux&h=6814044324e745e7c55aaf4bd47bdfd9a51d842a

Nikolaus



More information about the Gta04-owner mailing list