[Gta04-owner] fm-tuner - was Re: hw routing audio patch removed in 3.7?

Dr. H. Nikolaus Schaller hns at goldelico.com
Wed Jun 12 10:34:29 CEST 2013

Am 11.06.2013 um 20:39 schrieb Dr. H. Nikolaus Schaller:

> Am 11.06.2013 um 14:26 schrieb Dr. H. Nikolaus Schaller:
>> Am 10.06.2013 um 23:04 schrieb Andreas Kemnade:
>>> On Mon, 2013-06-10 at 15:45 +0200, Dr. H. Nikolaus Schaller wrote: 
>>>> Am 10.06.2013 um 15:27 schrieb Andreas Kemnade:
>>>>>>> it should not be taken (no UU at 0x11). PCM clocks need not be active at
>>>>>>> that moment (it can also give analog output). I am using 3.7.+a bunch of
>>>>>>> usb-hacks. I am not sure at the moment about maybe other
>>>>>>> clocks/voltages.
>>>>>> Hm. I rather suspect some header/library issue now. I have installed
>>>>>> gcc-4.6 (build-essentials) on the GTA04 and compiled directly
>>>>>> "on target". But I am not sure which linux headers and library headers
>>>>>> this will use.
>>>>> I have uploaded a statically compiled version now for comparision at the
>>>>> same location.
>>>> Hm. No difference (except that the binary is much bigger):
>>> Have you checked RCLK? I had done the tests with a lot of stuff on
>>> (wifi, umts, usb host).
>>> RCLK is something the RF circuits in the Si4721 need (not the sound
>>> stuff). A 32 khz clock. Maybe it was on for some reasons here.
>> From hardware side it is difficult to stop the clock since it is hard wired
>> to the TPS65950 output. So either it is broken on my boards or the
>> TPS has some special mode to disable/enable the 32kclkout.
>> So I have to set up the scope to verify...
> Well, 32kHz appears to be available, at least on the solder ball I can
> access from the outside (but I can't exclude that it is connected to the PCB
> only but not to the chip although that is quite unlikely).
> So my guess is that access of the I2C from users space is kernel dependent.
> I think I will try to configure / tune through i2c-tools and a shell script :)

Well, i2c tools are not able to read the multi-byte response.

But I have found the issue. It is the way the code writes a command and
reads back the response. There is no time delay in between.

To explain what happens:
* there appears to be some MCU inside the Si4721 with ROM firmware
* the chip has an autonomous I2C slave controller
* when the OMAP sends a command this wakes up the MCU to handle
the command
* the MCU code e.g. "tunes" and writes back its status to the I2C slave
controller response registers
* and it issues an interrupt (on line GPO2/INT
* the OMAP should then read back from the I2C response registers

But by using ioctl(fd,I2C_RDWR,&iod) the OMAP immediately reads
the I2C-slave response registers before the MCU has completed its
tasks. This appears to return all the 00 values we see. So if the OMAP
I2C driver is too fast, communication will not work.

I have changed the code to separate the write and read command
and - voilà - it works.

Here is the patch (I have also added some -d for debugging mode
and -s for initiating the status loop):


Next I will check if I can see any PCM...


More information about the Gta04-owner mailing list