[Gta04-owner] hw routing audio patch removed in 3.7?
Dr. H. Nikolaus Schaller
hns at goldelico.com
Sat Jun 8 22:43:55 CEST 2013
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
More information about the Gta04-owner
mailing list