Re: entering the error case of i2c-designware with a timeout at probe

[Oliver Neukum <oneukum@suse.com>]

Am Dienstag, den 21.03.2017, 14:01 +0100 schrieb Hans de Goede:
> Hi,
> 
> On 21-03-17 13:57, Max Staudt wrote:
> > 
> > On 03/21/2017 01:52 PM, Oliver Neukum wrote:
> > > 
> > > Hi Hans,
> > > 
> > > we found on our test systems with a bit of experimentation,
> > > that actually running into the timeout is bound to hang the whole
> > > system within only a few seconds.
> > > I was wondering whether the error handling needs to be changed.
> > 
> > In other words, whether we should rather wait for lock acquisition,
> > unconditionally. No timeout, just wait. That's what our hardware
> > seems to need.
> > 
> > It feels like once the lock has been requested by the Linux driver,
> > we can't cancel that request and have to actually follow through
> > with accepting the lock and only giving it back after that.
> > Resetting the "request" bit to 0 as it is done now doesn't work as
> > it leads to the hung system sometime soon after that.
> 
> Hmm, interesting theory. I would say give it a test and if it
> helps then maybe increase the timeouts to say 10 seconds or
> such, so that e.g. on poweroff we at least report an error
> rather then just sitting there ?

I did some testing. Unconditionally taking the error path without waiting
for the semaphore crashes or freezes the machine in about 3/4 of all
tests.
As I said, with a timeout of 500ms, this issue is not seen.
Do you have reliable information that the error handling works
on BayTrail?

	Regards
		Oliver