Re: [PATCH 10/53] Input: atmel_mxt_ts - Add memory access interfacevia sysfs

[Mark Brown]

On Tue, Jun 11, 2013 at 11:39:37AM +0100, Nick Dyer wrote:
> Mark Brown wrote:

> > I don't think you're using the usual definition of "register map" here.
> > You seem to be switching between talking about this object model the
> > device has and device registers - perhaps the objects are also registers
> > sometimes?

> Yes, in Atmel Object Protocol "instances" of "objects" do each have an
> assigned register range (they do also correspond to modules of code in the
> firmware).

OK, so you're talking about the objects which happen to be implemented
in terms of the register map here.  I think this is confusing to me
because you are moving between the abstraction levels.

> Essentially, the device is designed (and tested) on the assumption that
> touch processing can be going on whilst various parameters are changed in a
> live fashion. If poking around in the register map caused it to lock up or
> behave oddly then that would be considered a firmware bug. In general it
> will fail gracefully - for example if you write a configuration that is
> invalid it will just stop and emit a CFGERR message.

That's not really it, it's the fact that this is being done with no
abstraction - exposing the entire device register map directly to
application layer so the application can totally ignore what's going on
in the kernel doesn't seem like awesome design.

> The absolute worst thing that I can think of is that you can try to beat
> the interrupt handler to reading the "message processor" registers, which
> would possibly leave touches stuck on screen. But even that operation is
> useful in debugging interrupt line issues.

Well, there's also the potential issues with standard application layer
code either not being able to do things that the hardware supports or
getting into a fight with the magic custom stuff.

> > Won't the driver end up getting into a fight with the magic userspace
> > stuff if the driver has no idea what the magic userspace is doing?  How
> > would suspend and resume work?

> On suspend the driver puts chip into "deep sleep" where touch acquisition
> is halted and minimal power consumed. But it will still come out of its
> sleep state temporarily to service I2C comms if necessary (although one
> particular family requires that I2C retry for this case).

So these errors are just part of waking the chip up - in that case
shouldn't the driver be waking the chip up automatically?

Attachment: signature.asc
Description: Digital signature