[Letux-kernel] mcbsp 1

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


> 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.
> 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.

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

-------------- 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/1afb3d1c/attachment.asc>


More information about the Letux-kernel mailing list