Hi, (when replying, can you add some blank lines around your reply and the previous mail, it's quite difficult to find your replies with so many quote marks (>) around) On Tue, Jul 16, 2013 at 03:08:04PM +0300, Grygorii Strashko wrote: > Hi Felipe, > On 07/16/2013 02:27 PM, Felipe Balbi wrote: > >Hi, > > > >On Tue, Jul 16, 2013 at 02:01:11PM +0300, Grygorii Strashko wrote: > >>>>>>On a OMAP4460, i2c-bus-3: > >>>>>> > >>>>>>A driver (lm75) is causing many 'timeout waiting for bus ready' errors. > >>>>>>SDA remains high (as it should), but SCL remains low after a NACK. > >>>>>>The bus becomes _unusable for other clients_. > >>>>>> > >>>>>>While probing, "lm75" writes a command, followed by a read + stop, > >>>>>>but the write command is NACK'd. The chip does accept other writes/reads, > >>>>>>it just refuses to ack invalid commands. > >>>>>> > >>>>>>Can you tell me if the patch below would make any sense? Or is it the > >>>>>>responsibility of the client to reset the i2c_smbus? > >>>>>patch below breaks repeated start. > >>Felipe, I'd very appreciate if you'd be able to provide the use case > >>which will fail with such solution? > > > >can't you see how this would fail ? > > > >assume omap_i2c_xfer() is called with its last argument (num) being > >greater than one and you get the NAK before the last transfer. > That's our case - NACK from slave before last transfer with one difference, your device requires a STP condition because it's SMBus, right ? Not all devices act like that :-) But now I noticed, because of your reply, something I have been overlooking for quite some time. As you said below, in case of NAK we break out of the loop and don't even try the following messages. Which means your original patch starts to make a lot more sense. I wonder is this is really what we should be doing though - breaking out of the loop, I mean. It'd be cool to get an answer from I2C maintainers if we're doing the right thing here. -- balbi
Attachment:
signature.asc
Description: Digital signature
