FS#11714 - tea5767 tuner detection

Attached to Project: Rockbox
Opened by Bertrik Sikken (bertrik) - Tuesday, 02 November 2010, 19:35 GMT
Last edited by Bertrik Sikken (bertrik) - Friday, 05 November 2010, 17:05 GMT
Task Type Patches
Category FM Tuner
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Release 3.6
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Currently the TEA5767 tuner driver does not support detection of the presence of the tuner chip, it simply assumes that it's always present. For some targets (HDD16x0 / HDD63x0 for example) this means that the radio can be "detected" even when not present.

This patch adds detection support for the tea5767. Detection is done by looking if there is an i2c device responding at all during initialisation and by checking the chipid field in the data read back from the tuner (should be 0).

If you have a target with a tea5767 tuner chip (see, please try if the radio is still detected.
This task depends upon

Closed by  Bertrik Sikken (bertrik)
Friday, 05 November 2010, 17:05 GMT
Reason for closing:  Accepted
Additional comments about closing:  Variant of last patch committed as SVN r28493.
Comment by Bertrik Sikken (bertrik) - Tuesday, 02 November 2010, 23:04 GMT
Updated patch:
* considers bit 0 to also be part of the chip id, the datasheet says this should always be 0
* pre-init the i2c read buffer with a 0xFF value so it will NOT be recognised as a tea5767 in case fmradio_i2c_read fails silently (it seems to do so on PP targets)

Hopefully this improves detection.
Comment by Robert Menes (RMenes379) - Wednesday, 03 November 2010, 12:33 GMT
Tested and works on my GoGear HDD6330.
Comment by Alex Parker (BigBambi) - Thursday, 04 November 2010, 20:04 GMT
H100 still thinks it has a radio with the batch :)
Comment by Szymon Dziok (b0hoon) - Thursday, 04 November 2010, 21:52 GMT
It works now for the PP I2C target (Philips HDD6320). I suppose it's because of considering bit 0 as a part of chip ID (readouts were 01 01 01 '01' 2C or 02 02 02 '02' 2C before).
Edit: Readouts are really random - fourth byte can be: 0x01, 0x02, 0xA7, 0xE7, but it is good enough.
Comment by Bertrik Sikken (bertrik) - Friday, 05 November 2010, 07:34 GMT
Thanks all for testing! I think this can be committed soon.

Curiously, all read values being the same (as seen by Szymon in some cases) is one of the methods the linux tea5767 driver uses to exclude the presence of the tea5767.