On Fri, Jun 21, 2013 at 09:16:16AM -0700, Nick Dyer wrote:

Mark Brown wrote:

quoted

Yes, to be honest.  I'd hope it wouldn't be increasing the number of
read/write operations...

For some operations it does. For example updating the whole chip config
(which is a common thing to want to do), it would turn a couple of write
operations into ~20 on recent chips.

Is that really happening on peformance critical paths other than initial
power up (which could be handled more neatly anyway).

quoted

That still sounds like something the driver can handle (for example, by
eating the first error silently if it knows the chip is powered down)

We've tried to implement this idea of tracking the chip power state in
the driver and only eating the first error silently when necessary. But
there are various entertaining corner cases (for example, it may or may
not be in sleep on probe, how do you deal with intermittent i2c glitch). It
would end up either being very brittle or an extremely complex mechanism
involving tracking state and timers, the result of which is only to
suppress a dmesg debug output saying "i2c retry", and to fail very slightly
earlier in the normal i2c failure case. The normal fast path through
this code is exactly the same.

It seems very suspicous that this device has all these problems but
others don't...

quoted

and of course a system integrator may choose not to copy the reference
design in this respect, it does seem a bit odd after all.

You're being a bit optimistic there. Examples of devices that require
this are Samsung Galaxy Tab 10.1, Asus Transformer TF101.

If absoluely nobody has used the separate wakeup pin then the hardware
designers are wasting a pin there...  my point isn't that nobody would
use the reference design it's that some boards will have the separate
signal.