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

[Jonathan Cameron <jic23@cam.ac.uk>]

On 10/20/11 09:49, Thomas Petazzoni wrote:
> Le Thu, 20 Oct 2011 09:33:29 +0100,
> Jonathan Cameron <jic23@cam.ac.uk> a =C3=A9crit :
>=20
>>>  * 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 ev=
erything
>> that looks like a driver out of the arch directories. An equivalent =
somewhere
>> else might work though.
>=20
> 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).
>=20
>> 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 fo=
r IIO
>> we want to control the triggering of the push at a far finer scale t=
han
>> makes sense for input. I'm not yet clear how these two will play tog=
ether.
>=20
> My IIO knowledge is still too limited to understand what's the proble=
m
> 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 tr=
iggers
may be supplied by a dataready signal or from somewhere entirely differ=
ent.
Also multiple devices can be triggered by the same signal.  Thus the da=
taready
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 t=
hen registered
to receive the data the trigger cannot be changed anyway so that will w=
ork 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.  No=
te
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 driv=
ers
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 re=
al
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).

>=20
>> 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.
>=20
> I am not sure it's possible to make the touchscreen driver generic. O=
n
> 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 AD=
C
> 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.
>=20
>> For example are the switches on the G45's adc (from datasheet) somet=
hing that
>> all/many similar touch screen controllers have?
>=20
> I have no idea.
>=20
> However, I have also seen a platform (SuperH 2A) where ADC channels a=
re
> used for keypad handling. 4 ADCs channels, each connected to 4 keys,
> each having a different resistor. Depending on the voltage measured a=
t
> 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 b=
e
> 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 ;)
>=20
> Regards,
>=20
> Thomas