Message-ID: <ec89dfda-a321-6ec7-9da0-b4949f1f28b5@alliedtelesis.co.nz>
Date:   Sun, 14 Mar 2021 21:26:15 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     David Laight <David.Laight@...LAB.COM>,
        'Guenter Roeck' <linux@...ck-us.net>,
        Wolfram Sang <wsa@...nel.org>
CC:     "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
        "jdelvare@...e.com" <jdelvare@...e.com>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Subject: Re: Errant readings on LM81 with T2080 SoC

On 12/03/21 10:25 pm, David Laight wrote:
> From: Linuxppc-dev Guenter Roeck
>> Sent: 11 March 2021 21:35
>>
>> On 3/11/21 1:17 PM, Chris Packham wrote:
>>> On 11/03/21 9:18 pm, Wolfram Sang wrote:
>>>>> Bummer. What is really weird is that you see clock stretching under
>>>>> CPU load. Normally clock stretching is triggered by the device, not
>>>>> by the host.
>>>> One example: Some hosts need an interrupt per byte to know if they
>>>> should send ACK or NACK. If that interrupt is delayed, they stretch the
>>>> clock.
>>>>
>>> It feels like something like that is happening. Looking at the T2080
>>> Reference manual there is an interesting timing diagram (Figure 14-2 if
>>> someone feels like looking it up). It shows SCL low between the ACK for
>>> the address and the data byte. I think if we're delayed in sending the
>>> next byte we could violate Ttimeout or Tlow:mext from the SMBUS spec.
>>>
>> I think that really leaves you only two options that I can see:
>> Rework the driver to handle critical actions (such as setting TXAK,
>> and everything else that might result in clock stretching) in the
>> interrupt handler, or rework the driver to handle everything in
>> a high priority kernel thread.
> I'm not sure a high priority kernel thread will help.
> Without CONFIG_PREEMPT (which has its own set of nasties)
> a RT process won't be scheduled until the processor it last
> ran on does a reschedule.
> I don't think a kernel thread will be any different from a
> user process running under the RT scheduler.
>
> I'm trying to remember the smbus spec (without remembering the I2C one).
For those following along the spec is available here[0]. I know there's 
a 3.0 version[1] as well but the devices I'm dealing with are from a 2.0 
vintage.
> While basically a clock+data bit-bang the slave is allowed to drive
> the clock low to extend a cycle.
> It may be allowed to do this at any point?
 From what I can see it's actually the master extending the clock. Or 
more accurately holding it low between the address and data bytes (which 
from the T2080 reference manual looks expected). I think this may cause 
a strictly compliant SMBUS device to determine that Tlow:mext has been 
violated.
> The master can generate the data at almost any rate (below the maximum)
> but I don't think it can go down to zero.
> But I do remember one of the specs having a timeout.
>
> But I'd have thought the slave should answer the cycle correctly
> regardless of any 'random' delays the master adds in.
Probably depends on the device implementation. I've got multiple other 
I2C/SMBUS devices and the LM81 seems to be the one that objects.
> Unless you are getting away with de-asserting chipselect?
>
> The only implementation I've done is one an FPGA so doesn't have
> worry about interrupt latencies.
> It doesn't actually support clock stretching; it wasn't in the
> code I started from and none of the slaves we need to connect to
> ever does it.
>
> 	David

[0] - http://www.smbus.org/specs/smbus20.pdf
[1] - https://pmbus.org/Assets/PDFS/Public/SMBus_3_0_20141220.pdf

>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>

Powered by blists - more mailing lists