Thread (16 messages) flat view 16 messages, 4 authors, 2021-05-27

Re: [PATCH v3 0/4] P2040/P2041 i2c recovery erratum

From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Date: 2021-05-20 03:37:04
Also in: linux-devicetree, linux-i2c, lkml

On 13/05/21 3:01 am, wsa@kernel.org wrote:
quoted
quoted
I've been doing my recent work with a P2040 and prior to that I did test
out the recovery on a T2081 (which isn't documented to have this
erratum) when I was re-working the driver. The "new" recovery actually
seems better but I don't have a reliably faulty i2c device so that's
only based on me writing some code to manually trigger the recovery
(using the snippet below) and observing it with an oscilloscope.
You don't need a faulty device, just an aborted I2C read/write op.
If you can wire GPIOs to the bus, you can use the I2C fault injector:

	Documentation/i2c/gpio-fault-injection.rst

There are already two "incomplete transfer" injectors.
Just giving this thread a poke. I have been looking at my options for 
triggering an i2c recovery but haven't really had time to do much. I 
think the best option given what I've got access to is a modified SFP 
that grounds the SDA line but I need to find a system where I can attach 
an oscilloscope (should be a few of these in the office when I can get 
on-site).

I can confirm that when manually triggered the existing recovery and the 
new erratum workaround produce what I'd expect to observe on an 
oscilloscope.

I haven't explored Joakim's alternative recovery but I don't think that 
should hold up these changes, any improvement to the existing recovery 
can be done later as a follow-up.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help