[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 11:06:14 CEST 2013


Am 12.06.2013 um 10:34 schrieb Dr. H. Nikolaus Schaller:

> 
> 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):
> 
> <http://git.goldelico.com/?p=gta04-rootfs.git;a=commit;h=7bbf278ec168bdf14dbdfa940f82ae3831b4a691>
> 
> Next I will check if I can see any PCM...

Interesting note from the data sheet:

Failure to provide DCLK and DFS prior to setting the sample rate property may cause the chip to go into an unknown
state and user must reset the chip.

This means the arecord command must be run before ./si4721 or we need a separate command to set the sample
rate to 0 before turning on/off arecord.

Nikolaus






More information about the Gta04-owner mailing list