Re: [PATCH 1/3] si2157: get chip id during probing

["Uwe Kleine-König" <uwe@kleine-koenig.org>]

[-- Attachment #1: Type: text/plain, Size: 2661 bytes --]

Hello Andreas,

On Tue, Jul 09, 2019 at 08:03:29PM +0200, Andreas Kemnade wrote:
> On Mon, 8 Jul 2019 10:43:08 +0200
> Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
> > On 7/7/19 11:01 PM, Uwe Kleine-König wrote:
> > > Hello,
> > > 
> > > On 7/7/19 10:58 PM, Uwe Kleine-König wrote:  
> > >> From: Andreas Kemnade <andreas@kemnade.info>
> > >>
> > >> If the si2157 is behind a e.g. si2168, the si2157 will
> > >> at least in some situations not be readable after the si268
> > >> got the command 0101. It still accepts commands but the answer
> > >> is just ffffff. So read the chip id before that so the
> > >> information is not lost.
> > >>
> > >> The following line in kernel output is a symptome
> > >> of that problem:
> > >> si2157 7-0063: unknown chip version Si21255-\xffffffff\xffffffff\xffffffff
> > >>
> > >> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>  
> > 
> > I wonder if you (or anyone else here reading this mail) has access to
> > the datasheets of the involved chips? (i.e. si2168, si2157)
> > I'd like to try understanding and eventually fix the addressed problem
> > here properly.

BTW, I tried to contact Silabs support asking for the datasheets. But
because this doesn't promise to generate a certain amount of selled
chips I won't get an NDA and so also won't get the datasheets. :-|

> I remember some rumors that there is a resistor on the board which needs to be
> changed, maybe some i2c pullup to properly fix it. Windows driver by chance
> does it in a order which works with the current setup, so engineers
> did not notice. I have not checked it myself.
> So the theory is that we do here some workaround for a hw problem.

Do you have some more details about these rumors?

You wrote in the commit log that the si2157 would still be writable but
not readable. Given how i2c works I wonder how this can be because both
directions use the same data line. Did you verify with a scope that the
revision query command makes it on the bus? Is the reply visible, or do
you see the 0xff bytes there, too?

Given that the transfer works before the si2168 chip is booted (this is
what the 0x01-0x01 command is about AFAIK), this doesn't sound like a
hardware issue to me.

There are still a few things I could check:

 - are there some (write only) i2c transfers later that (seem to) work?
 - is it really the 0x01 0x01 that makes reading the revision fail?

Not sure when I come around because this is my free time project and
there are more urgent things to do for me now. But if you have thoughts
about the matter, don't hesitate to tell me.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]