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

[Nick Dyer <nick.dyer@itdev.co.uk>]

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).

This document is a better description of it than I can give:
http://www.atmel.com/Images/Atmel-9626-AT42-QTouch-BSW-AT421085-Object-Protocol-Guide_Datasheet.pdf

That's a rather old chip now, but the same system is used throughout
maXTouch series chips, and also on some non-touch chips now.

> You appear to be assuming a great deal of familiarity with the specifics
> of this device here.  Where does all thi stuff about reinitialsing the
> device come from?  What are these dependencies and what does all this
> have to do with setting parameters?

I think you're uncomfortable with the idea of giving full access by
default. I'm not sure how I can convince you that that is OK by design, I
can only assert it.

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.

In my previous messages in this thread, I tried to answer some of the
particular cases in which you might expect the driver to have to cope with
the configuration changing "under it". It's difficult to be exhaustive
without having to impart a huge amount of domain knowledge first.

In the patch under discussion, the driver would have to trap writes to
particular registers and take appropriate action, or provide a mechanism to
be told that it needs to reinitialise itself. In practice (it's been widely
tested outside of mainline) I haven't found a case where doing this has
been essential, although there's nothing about this patch that stops us
adding them.

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.

>> OK. I think that the ABI offered to the application layer should also be
>> object protocol, implemented over a binary attribute, which is what the
>> patch under discussion does. Is the problem that I need to provide better
>> documentation of object protocol?
> 
> As Greg says you do need to document any new sysfs ABIs you're adding
> anyway.  However if this is some stateful protocol you're implementing
> then does it really map onto sysfs well, sysfs attributes are normally
> more just data values?

Perhaps it is a little unusual. There was an older ioctl-based
implementation, but I think that would be rejected for different reasons.

> 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).