[PATCH 2/3] ARM: AT91: IIO: Add AT91 ADC driver.

[Jonathan Cameron]

On 10/20/11 09:49, Thomas Petazzoni wrote:
> Le Thu, 20 Oct 2011 09:33:29 +0100,
> Jonathan Cameron <jic23 at cam.ac.uk> a écrit :
> 
>>>  * Should we have some low-level ADC driver in arch/arm/mach-at91/ that
>>>    allows to request/release/access the ADC channels, this driver
>>>    providing an internal kernel API used by the IIO ADC driver and the
>>>    touchscreen driver ?
>> That's definitely not going to go down well against moves to move everything
>> that looks like a driver out of the arch directories. An equivalent somewhere
>> else might work though.
> 
> Yes, of course if this needs to be implemented, it should be in some
> other location than arch/arm, but not sure where (which is basically
> the discussion that was started some time ago).
> 
>> Agreed.  This is currently up in the air. The current state of those IIO
>> hooks is that they do pull only.  Push based capture is tricky as for IIO
>> we want to control the triggering of the push at a far finer scale than
>> makes sense for input. I'm not yet clear how these two will play together.
> 
> My IIO knowledge is still too limited to understand what's the problem
> with exposing an API for push-based capture.
I'll give a quick summary:

Push in IIO is done from a trigger (imagine an oscilloscope).  Those triggers
may be supplied by a dataready signal or from somewhere entirely different.
Also multiple devices can be triggered by the same signal.  Thus the dataready
from one chip can trigger a whole load of others.

Right now filtering functions prevent some devices from using anything other than
their own trigger.  Setting defaults is also possible. If anything is then registered
to receive the data the trigger cannot be changed anyway so that will work here.

The other bit that makes it complex is the data flow.
This is done in the form of scans of a set of channels. The description of these
are more or less available to the core.  Note the scan you get may well have
more channels in it than you explicitly requested.

These scans are then pushed into one of a set of different buffers.  Note
All of the scan is currently pushed.  That makes sense if you only have one
user of the data.  Right now the pushing is done by the individual drivers
but this could pass through the core.

So things that stand in the way of more general use:

1) Userspace controlled triggers (apply to whole ADC) - can lock these down if
say a touchscreen driver is using the device.
2) Single output stream of data.
3) Note there is deliberately no metadata in the stream. It is all out of band.

Push to one driver is easy.  Anything else needs a demux that is aware of the
stream contents.  This bit doesn't exist and looks non trivial.  The real
trick is going to be keeping it light and fast (or entirely out of the
way when not needed.)

At some point I'll have a play with rerouting the data so such a demux
can sit in the current flow (can use it to kill off unwanted channels).

> 
>> If we sit something underneath the IIO and input drivers (or use the lower
>> portions of IIO to do this) then the intent would be to have a fully generic
>> input touchscreen driver on top.  I'm not sure that's possible.
> 
> I am not sure it's possible to make the touchscreen driver generic. On
> the G45, the ADC IP has some generic ADC registers, but also some
> touchscreen-specific registers. So the touchscreen driver probably
> cannot be completely generic and some cooperation between the AT91 ADC
> driver and the AT91 touchscreen driver might be needed. I'd have to
> look into more details on how the AT91 touchscreen thing works to
> provide some more details here.
> 
>> For example are the switches on the G45's adc (from datasheet) something that
>> all/many similar touch screen controllers have?
> 
> I have no idea.
> 
> However, I have also seen a platform (SuperH 2A) where ADC channels are
> used for keypad handling. 4 ADCs channels, each connected to 4 keys,
> each having a different resistor. Depending on the voltage measured at
> the ADC, you're capable of knowing which key of the 4x4 keypad is
> pressed. This is a different situation where the ADC values need to be
> used by another in-kernel driver.
That one is much easier to handle and indeed not that uncommon a hack.
It really is just using the ADCs to get a value.  Hence with suitable
descriptive map it's easy to write a generic driver for it.
Even easier if it's simply polled ;)
> 
> Regards,
> 
> Thomas