[Letux-kernel] mcbsp 1

H. Nikolaus Schaller hns at goldelico.com
Fri Apr 28 21:28:46 CEST 2017


> Am 28.04.2017 um 21:12 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> Am 28.04.2017 um 21:05 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>> Hi,
>> 
>>> Am 28.04.2017 um 19:57 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> 
>>> Hi,
>>> 
>>> On Fri, 28 Apr 2017 08:44:04 +0200
>>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>> 
>>> 
>>>> 
>>>> Essentially the same task could be to find out why the Si4721 is not working any more.
>>>> 
>>>> It responds a little to I2C commands but not reliably. Maybe, it is missing the McBSP1
>>>> clock for some operations.
>>>> 
>>> Well, it has several clocks (I2C clock, 32khz clock and the I2S clocks).
>>> I remember being reliably able to tune to a station without mcbsp set
>>> up. only for the command which actually enables the i2s interface, the
>>> mcbsp clocks are required.
>>> 
>>> So I think the other clocks are more interesting at first. The 32khz
>>> stuff: hmm. the also not-so-stable bluetooth has that also...
>>> But it should be rarely switched off.
>>> Hmm, I2C. maybe frequency too high for the si4721. Or it does some
>>> clock stretching the master is not properly acting upon.
>> 
>> I have checked with the data sheet and I2C can do 400kHz.

https://www.silabs.com/documents/public/data-sheets/Si4720-21-B20.pdf

>> It also seems to work without other clocks.
>> 
>> The main difference is that it does not have the usual "register+value"
>> model like many other I2C chips.
>> 
>> It has a command + parameters + optional response.
>> 
>> This explains why a simple i2cdump does not return reliable values.
>> Because it triggers commands 0x00, 0x01, 0x02 etc. with missing parameters
>> and expects responses.
>> 
>> So maybe the first attempt already mixes up the chip. And trying to i2cdump
>> register 0x11 issues a POWER_DOWN command.
>> 
>> This means that it is quite difficult to check if the chip is working
>> properly by i2cget and i2cset.
>> 
>> The only thing that could work is to read "register" 0x10 (GET_REV)
>> which should return the chip version number.
>> 
>> So why does our ./si4721 tool [1] not work any more?
>> Maybe something in the /dev/i2c ioctls has changed... Or the usleep is too
>> long or too short?
>> 
>> And we should also modify the hw-test [2] to do an i2cget from bus 1,
>> address 0x11 command 0x10 since a simple i2cdetect may fail.

root at letux:~# i2cget -y 1 0x11 0x10 w
0x0080
root at letux:~#

which seems to be 2 bytes of the chip revision.

https://www.silabs.com/documents/public/application-notes/AN332.pdf (page 14)

> 
> or restore the old test which did call the ./si4721 tool.
> 
> In summary, the general problem is less likely the kernel but the tool.
> And then if we can identify the chip and tune, we can and have to fix
> the McBSP1 (I have changed the subject :).
> 
>> 
>> BR,
>> Nikolaus
>> 
>> [1] http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/si4721.c;h=410bb33b5a13698dc9d6c1948ada1e3e77580297;hb=refs/heads/letux-4.11-rc8
>> [2] http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/hw-test;h=f442d02eb6c4d9aa9c7dfbb2d5c8ae9e7740e90f;hb=refs/heads/letux-4.11-rc8#l514
>> _______________________________________________
>> http://projects.goldelico.com/p/gta04-kernel/
>> Letux-kernel mailing list
>> Letux-kernel at openphoenux.org
>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20170428/adb03270/attachment-0001.asc>


More information about the Letux-kernel mailing list