On Fri, Jun 21, 2013 at 09:16:16AM -0700, Nick Dyer wrote: > Mark Brown wrote: > > 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). > > 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... > > 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.
Attachment:
signature.asc
Description: Digital signature
