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

Dr. H. Nikolaus Schaller hns at goldelico.com
Sat Jun 8 19:12:44 CEST 2013

Am 08.06.2013 um 18:43 schrieb Dr. H. Nikolaus Schaller:

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

1. although the McBSP pins can be programmed as GPIOs through the McBSP
controller (i.e. independently of the PinxMux), the DX pin is output only.
(section and Table 21-34.). If it were possible to switch it to GPIO input
it would be high impedance.

2. this is controlled by the the MCBSPLP_PCR_REG register bit XIOEN:

	Transmit General Purpose I/O Mode only when XRST=0 in SPCR[1,2] (legacy)
	0x0: DX, FSX and CLKX are configured as serial port pins and do not function as general-purpose I/Os.
	0x1: DX pin is a general purpose output. FSX and CLKX are general purpose I/Os. These serial port pins do not perform serial port operation.


	DX pin status. Reflects value driven on to DX pin when 0x0 selected as a general purpose output. (legacy)
	0x0: Drive the signal on the DX pin low
	0x1: Drive the signal on the DX pin high

3. the mcbsp driver and registers are here:


So I think we have to stick with the PinMux approach.

But to improve it and make it more general/better separated, I would suggest to
provide a callback function written in the platform code and provided by the platform
data. Either some "make_me_DX_master()" or "stop_anyone_else_on_DX".

Someone please come up with a better idea :)


More information about the Gta04-owner mailing list