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

[Dr. H. Nikolaus Schaller]

Am 23.10.2013 um 18:52 schrieb Andreas Kemnade:

> On Wed, 2013-10-23 at 15:25 +0200, Christoph Mair wrote: 
>> On Wed, Oct 23, 2013 at 1:06 PM, Andreas Kemnade <andreas at kemnade.info> wrote:
>>> On Mon, 2013-06-24 at 11:38 +0200, Dr. H. Nikolaus Schaller wrote:
>>>> Hi,
>>>> fm-radio appears to work. At least on one board (the one where I did solder some wires to measure the clocks and PCM signals).
>>>> [...]
>>>> Now comes the bad news: it works only on one GTA04 board and I don't
>>>> know why it fails on the others I have tested. Since they have no wires I
>>>> can't check if the clocks are available and the Si47xx is sending PCM
>>>> to the CPU or not. Or if there is something unreliable in the McBSP config.
>>>> 
>>>> It could also be some hardware issue. If you look into the schematics, there
>>>> are series resistors for the McBSP1 interface. Their values are choosen
>>>> based on the recommendations of a reference design we had found.
>>>> 
>>>> But 2k2 appears a little high value, taking into account that we have a 2.5 MHz
>>>> clock. I.e. the signals may be damped and too slow so that e.g. the clocks
>>>> are not recognized correctly.
>>>> 
>>> I do not understand the connection here. The McBSP sends out its clocks.
>>> It should look at the data pin at the right times and interpret whatever
>>> is avilable there at sampling time if i understand the I2S stuff
>>> correctly. So we should be able to read some suff and arecord should
>>> spit out something.

Yes, it should. If the pinmux and signal levels are ok.

>> 
>> One thing which comes to my mind: did you mux the clock output pin as
>> input? While this seems wrong, the McBSP needs this configuration to
>> use its own clock as receive clock. The pin works as output
>> nonetheless.
>> 
> Ehm,.. I should have followed the link about uboot in the mail. As
> pinmux settings in uboot are of course right (everything to output I
> thought, I have checked that often), I thought hns has accidently run an
> ancient uboot instead of an old one...

Yes, pinmux has an influence. And some more or less hidden stuff in the kernel
for correctly setting the McBSP clocks.

I have just booted the test device where the wires are connected to the McBSP
interface - and I have no sound on this one, although it did work earlier...

tuned to 98500khz RSSI 17dBuV SNR 0dB weak
Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
RSSI 19dBuV SNR 0dB offset 5kHz weak
RSSI 19dBuV SNR 0dB offset 6kHz weak
RSSI 18dBuV SNR 0dB offset 6kHz weak
RSSI 18dBuV SNR 0dB offset 5kHz weak
RSSI 19dBuV SNR 0dB offset 5kHz weak
RSSI 19dBuV SNR 0dB offset 5kHz weak
RSSI 19dBuV SNR 0dB offset 5kHz weak
RSSI 18dBuV SNR 0dB offset 5kHz weak
arecord: pcm_read:1801: read error: Input/output error
RSSI 18dBuV SNR 0dB offset 5kHz weak
RSSI 18dBuV SNR 0dB offset 5kHz weak
 
Have to look deeper.

So your conjecture might be right that there still is an interference with U-Boot.
The version I have currently in the test board is compiled (Sep 03 2013 - 17:42:22),
i.e. the HEAD source code.

The last changes to U-Boot pinmux were:

http://git.goldelico.com/?p=gta04-uboot.git;a=history;f=u-boot/board/goldelico/gta04/gta04.h;h=5749bcee81fd6097614e9ddc4cede17d7cc51bf3;hb=HEAD

Just 5 modifications in total.

This one should have fixed it:

http://git.goldelico.com/?p=gta04-uboot.git;a=commitdiff;h=05bdeba3ec58bb69677caa0fb274070e60ec3b69

> So I did not update my uboot. Ok, that seems to be the missing part of
> information I needed all the time when I was experimenting with that.
> At least I now get something out of the McBSP1. Now I am searching my
> headphone.

Great.

BR,
Nikolaus