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

[Dr. H. Nikolaus Schaller]

Am 08.06.2013 um 22:00 schrieb Dr. H. Nikolaus Schaller:

> 
> 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

Code idea foor this approach:

a) insert

	.set_tristate = omap_mcbsp_dai_set_tristate

here:

<http://lxr.free-electrons.com/source/sound/soc/omap/omap-mcbsp.c?v=3.7;a=arm#L543>

b) implement something similar to

static int omap_mcbsp_dai_set_tristate(struct snd_soc_dai *dai, int tristate) {
int val = tristate?OMAP_MUX_MODE7: (OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT);
// check for OMAP3 (no need to support OMAP1/2 any more - and for OMAP4 we don't care yet)
switch(dai->id) {
// FIXME: check if the mux was successful
  case 0: omap_mux_set_gpio(val, ...); break;
  case 1: omap_mux_set_gpio(val, ...); break;
  case 2: omap_mux_set_gpio(val, ...); break;
  case 3: omap_mux_set_gpio(val, ...); break;
  case 4: omap_mux_set_gpio(val, 154); break;
  default: -EIO;
}
return 0;
}

Then we just have to know the right dai in twl4030.c (if not NULL) and use the official tristate mechanism.

Nikolaus