Re: [PATCH 10/53] Input: atmel_mxt_ts - Add memory access interfacevia sysfs
From: Mark Brown
Date: Tue Jul 02 2013 - 06:12:13 EST
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