Interface between IIO driver and an input driver

Interface between IIO driver and an input driver

[Quentin Schulz]

Hi all,

The Allwinner SoCs all have an ADC that can also act as a touchscreen
controller and a thermal sensor. We currently have a driver for the two
latter functions in drivers/input/touchscreen/sun4i-ts.c, but we don't
have access to the ADC feature at all.

Hence, I've been working on an IIO driver for that IP, with the hope
that we could use iio-hwmon for the thermal sensor, and a
yet-to-be-developped driver for the touchscreen part.

The thermal sensor using iio_hwmon to communicate with the IIO driver is
working fine.

However, the touchscreen needs all the channels of the ADC to be able
to get the coordinates. Moreover, you need to poke a few bits in some
registers to switch the ADC mode and activate a few interrupts (pen-up
and pen-down) to be able to operate as a touchscreen controller.
Therefore, I need a way to ask the IIO driver to poke these bits from
the input driver. For now, I am calling a function defined in my IIO
driver from my input driver to ask to switch between modes. Is it how it
is supposed to be done?

Now that I switched to touchscreen mode, I need to get data from the IIO
driver. I already get hardware interrupts in the IIO driver when
something occurs with the touchscreen but now I need to notify the input
driver that I received an interrupt for the touchscreen and make  the
associated data available to the input driver. For now, I am using a
callback I set when probing the input driver and call this callback when
the correct interrupt is detected in the IIO driver's interrupt handler.
I pass the data through a parameter of this callback. However, I don't
think it is a good idea since the IIO driver has no idea on what the
callback is doing and it might just take too long to execute or even
freeze, which is definitely not what we want in an interrupt handler.
I've seen iio_channel_get_all_cb
(http://lxr.free-electrons.com/source/include/linux/iio/consumer.h#L79)
but I don't understand what it is doing or how to use it since there is
not a single driver using this function. Can someone explain what it is
supposed to do?
If that callback mechanism isn't really supposed to address my use-case,
do you have a suggestion on how to implement such a thing?

Thanks,

Quentin

Re: Interface between IIO driver and an input driver

[Marc Titinger]

Hi All,


(sorry Quentin, I here just share a related thought, not actually 
helping you much).

a nice feature would be to have some sort of "mixer" interface, similar 
to the one common with audio APIs. An IIO driver can already use a 
separate trigger device as an interrupt source and I believe there is 
some wip to allow for software trigger sources instantiated with 
configfs. Similarly, being able to link standard interfaces from 'input' 
or 'gpio' as an event source for (an) iio driver(s) would be great. 
Another benefit would be to use libiio and iiod as the unique connector 
to enumerate and control those interfaces, for instance with a product 
that can record some voltage (plain iio streaming) and switch on/off 
that power source using a standard gpio.

BR,
Mar.


On 03/06/2016 09:17, Quentin Schulz wrote:
> Hi all,
>
> The Allwinner SoCs all have an ADC that can also act as a touchscreen
> controller and a thermal sensor. We currently have a driver for the two
> latter functions in drivers/input/touchscreen/sun4i-ts.c, but we don't
> have access to the ADC feature at all.
>
> Hence, I've been working on an IIO driver for that IP, with the hope
> that we could use iio-hwmon for the thermal sensor, and a
> yet-to-be-developped driver for the touchscreen part.
>
> The thermal sensor using iio_hwmon to communicate with the IIO driver is
> working fine.
>
> However, the touchscreen needs all the channels of the ADC to be able
> to get the coordinates. Moreover, you need to poke a few bits in some
> registers to switch the ADC mode and activate a few interrupts (pen-up
> and pen-down) to be able to operate as a touchscreen controller.
> Therefore, I need a way to ask the IIO driver to poke these bits from
> the input driver. For now, I am calling a function defined in my IIO
> driver from my input driver to ask to switch between modes. Is it how it
> is supposed to be done?
>
> Now that I switched to touchscreen mode, I need to get data from the IIO
> driver. I already get hardware interrupts in the IIO driver when
> something occurs with the touchscreen but now I need to notify the input
> driver that I received an interrupt for the touchscreen and make  the
> associated data available to the input driver. For now, I am using a
> callback I set when probing the input driver and call this callback when
> the correct interrupt is detected in the IIO driver's interrupt handler.
> I pass the data through a parameter of this callback. However, I don't
> think it is a good idea since the IIO driver has no idea on what the
> callback is doing and it might just take too long to execute or even
> freeze, which is definitely not what we want in an interrupt handler.
> I've seen iio_channel_get_all_cb
> (http://lxr.free-electrons.com/source/include/linux/iio/consumer.h#L79)
> but I don't understand what it is doing or how to use it since there is
> not a single driver using this function. Can someone explain what it is
> supposed to do?
> If that callback mechanism isn't really supposed to address my use-case,
> do you have a suggestion on how to implement such a thing?
>
> Thanks,
>
> Quentin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Interface between IIO driver and an input driver

[Jonathan Cameron]

On 03/06/16 08:17, Quentin Schulz wrote:
> Hi all,
Hi Quentin,
> 
> The Allwinner SoCs all have an ADC that can also act as a touchscreen
> controller and a thermal sensor. We currently have a driver for the two
> latter functions in drivers/input/touchscreen/sun4i-ts.c, but we don't
> have access to the ADC feature at all.
A common situation unfortunately.
> 
> Hence, I've been working on an IIO driver for that IP, with the hope
> that we could use iio-hwmon for the thermal sensor, and a
> yet-to-be-developped driver for the touchscreen part.
Cool.
> 
> The thermal sensor using iio_hwmon to communicate with the IIO driver is
> working fine.
> 
> However, the touchscreen needs all the channels of the ADC to be able
> to get the coordinates. Moreover, you need to poke a few bits in some
> registers to switch the ADC mode and activate a few interrupts (pen-up
> and pen-down) to be able to operate as a touchscreen controller.
These corner elements are what has led to slightly different handling in
every combined driver that exists so far.  I'm not particularly a touchscreen
expert (all my boards are headless!) but have hit this a few time in
reviewing previous drivers.

> Therefore, I need a way to ask the IIO driver to poke these bits from
> the input driver. For now, I am calling a function defined in my IIO
> driver from my input driver to ask to switch between modes. Is it how it
> is supposed to be done?
So we have two data interfaces in IIO for inkernel use at the moment. Both
are related to 'in band data' - basically reading adc data.
1) Pull - iio-hwmon type polling when it wants to know.
2) Push - see below, but they basically hook in a callback where data passes
into buffers.

What we are definitely missing (though it doesn't solve all your problems)
is a means of passing on what we term 'events' - i.e. out of band data.
Whether pen up and down are really out of bound or not I'm not sure - they
could just be considered a 1bit channel or similar.

>From IIO point of view, to poke these they need to be either info-mask
elements of extended elements (though we don't have nice wrappers for
extended elements yet). If we treat these interrupts as events, then
we also need a way of requesting events from a touch screen driver.
(Adding this is more a question of figuring out sensible ish APIs than
anything else - as it's in kernel we can evolve them as necessary anyway)
> 
> Now that I switched to touchscreen mode, I need to get data from the IIO
> driver. I already get hardware interrupts in the IIO driver when
> something occurs with the touchscreen but now I need to notify the input
> driver that I received an interrupt for the touchscreen and make  the
> associated data available to the input driver. For now, I am using a
> callback I set when probing the input driver and call this callback when
> the correct interrupt is detected in the IIO driver's interrupt handler.
Basically you are running as an MFD by the sound of it.  A valid approach
though I'd suggest it may make sense to formalise it a bit more and do
an interrupt chip etc as per a modern MFD.  Leads to nicer driver separation
etc.
> I pass the data through a parameter of this callback. However, I don't
> think it is a good idea since the IIO driver has no idea on what the
> callback is doing and it might just take too long to execute or even
> freeze, which is definitely not what we want in an interrupt handler.
I'd certainly suggest this needs to be in threaded context at the very
least.  If it hangs, it hangs - that's a bug in the touch screen driver that
simply needs to be fixed.  
> I've seen iio_channel_get_all_cb
> (http://lxr.free-electrons.com/source/include/linux/iio/consumer.h#L79)
> but I don't understand what it is doing or how to use it since there is
> not a single driver using this function. Can someone explain what it is
> supposed to do?
See the input bridge mentioned below. There are also I think some out of
tree users (analog devices tree) largely because I get the odd fix from
them for this code.

> If that callback mechanism isn't really supposed to address my use-case,
> do you have a suggestion on how to implement such a thing?
The basic approaches that have been taken before are:
1) Monolithic driver (we don't really like this one) which registers
both IIO and input devices.
2) MFD layer underneath - this allows low level arbitration of access to
the data.  This works just fine and gives a nice split but never feels
as generic as it might be.. (which I think is where you are coming from).
Something like the am335x driver would be an example of this (there are
several).
3) Using a similar strategy to the iio-hwmon interface. I did write
an iio-input bridge a long time ago that gives some idea of how this
might work, but never got the time to finish it.
http://www.spinics.net/lists/linux-iio/msg06879.html 
specifically patch 4 http://www.spinics.net/lists/linux-iio/msg06881.html
(I'm a little - *very* embarrassed at how long this one has taken -
if anyone wants to pick it up and run with it I'd be most grateful!)

There are some 'sticky' issues with that still from what I recall
* It is typically an either or with many drivers as they will either
operate in the push mode (buffered within IIO) or the polled mode
used by iio-hwmon.   This can be fixed by playing games within
individual drivers, but a more general layer providing registered
clients with cached readings when in push mode would be a great
addition.
* It was really targeted at the simpler accelerometer usecase.
* We don't have support for passing what are considered 'events' by
IIO - out of band data.  In your case the pen touch events.
Passing them over is easy enough, but working out the correlation
with the main data flow is going to be a little trickier.
Meta data channels are possible, but we don't have a well defined
interface for them yet.

Now I'd love to see a generic touch screen driver, but as you no
doubt know there are some fiddly hooks in many of these where semi
manual switching of feed voltages are needed.  A nice controller
wrapping up a scheduled pass over the relevant combinations would
be easier to handle I guess.  

Perhaps there are classes of device that are similar enough to
allow a single simple driver?  I never learnt enough about these
to be sure either way on that.  It comes up every time this
question gets raised and yet no one has yet had time to do all that
much about it :(

So as ever which way makes sense for you might be more a question
of how much time you have available than anything else.
Best is of course to make everything magic for everyone in the
future and put together a generic touch screen driver ;) 
Good is MFD.
Anything else is worse.

Jonathan
> 
> Thanks,
> 
> Quentin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Interface between IIO driver and an input driver

[Jonathan Cameron]

On 03/06/16 10:21, Jonathan Cameron wrote:
> On 03/06/16 08:17, Quentin Schulz wrote:
>> Hi all,
> Hi Quentin,
>>
>> The Allwinner SoCs all have an ADC that can also act as a touchscreen
>> controller and a thermal sensor. We currently have a driver for the two
>> latter functions in drivers/input/touchscreen/sun4i-ts.c, but we don't
>> have access to the ADC feature at all.
> A common situation unfortunately.
>>
>> Hence, I've been working on an IIO driver for that IP, with the hope
>> that we could use iio-hwmon for the thermal sensor, and a
>> yet-to-be-developped driver for the touchscreen part.
> Cool.
>>
>> The thermal sensor using iio_hwmon to communicate with the IIO driver is
>> working fine.
>>
>> However, the touchscreen needs all the channels of the ADC to be able
>> to get the coordinates. Moreover, you need to poke a few bits in some
>> registers to switch the ADC mode and activate a few interrupts (pen-up
>> and pen-down) to be able to operate as a touchscreen controller.
> These corner elements are what has led to slightly different handling in
> every combined driver that exists so far.  I'm not particularly a touchscreen
> expert (all my boards are headless!) but have hit this a few time in
> reviewing previous drivers.
> 
>> Therefore, I need a way to ask the IIO driver to poke these bits from
>> the input driver. For now, I am calling a function defined in my IIO
>> driver from my input driver to ask to switch between modes. Is it how it
>> is supposed to be done?
> So we have two data interfaces in IIO for inkernel use at the moment. Both
> are related to 'in band data' - basically reading adc data.
> 1) Pull - iio-hwmon type polling when it wants to know.
> 2) Push - see below, but they basically hook in a callback where data passes
> into buffers.
> 
> What we are definitely missing (though it doesn't solve all your problems)
> is a means of passing on what we term 'events' - i.e. out of band data.
> Whether pen up and down are really out of bound or not I'm not sure - they
> could just be considered a 1bit channel or similar.
> 
> From IIO point of view, to poke these they need to be either info-mask
> elements of extended elements (though we don't have nice wrappers for
> extended elements yet). If we treat these interrupts as events, then
> we also need a way of requesting events from a touch screen driver.
> (Adding this is more a question of figuring out sensible ish APIs than
> anything else - as it's in kernel we can evolve them as necessary anyway)
>>
>> Now that I switched to touchscreen mode, I need to get data from the IIO
>> driver. I already get hardware interrupts in the IIO driver when
>> something occurs with the touchscreen but now I need to notify the input
>> driver that I received an interrupt for the touchscreen and make  the
>> associated data available to the input driver. For now, I am using a
>> callback I set when probing the input driver and call this callback when
>> the correct interrupt is detected in the IIO driver's interrupt handler.
> Basically you are running as an MFD by the sound of it.  A valid approach
> though I'd suggest it may make sense to formalise it a bit more and do
> an interrupt chip etc as per a modern MFD.  Leads to nicer driver separation
> etc.
>> I pass the data through a parameter of this callback. However, I don't
>> think it is a good idea since the IIO driver has no idea on what the
>> callback is doing and it might just take too long to execute or even
>> freeze, which is definitely not what we want in an interrupt handler.
> I'd certainly suggest this needs to be in threaded context at the very
> least.  If it hangs, it hangs - that's a bug in the touch screen driver that
> simply needs to be fixed.  
>> I've seen iio_channel_get_all_cb
>> (http://lxr.free-electrons.com/source/include/linux/iio/consumer.h#L79)
>> but I don't understand what it is doing or how to use it since there is
>> not a single driver using this function. Can someone explain what it is
>> supposed to do?
> See the input bridge mentioned below. There are also I think some out of
> tree users (analog devices tree) largely because I get the odd fix from
> them for this code.
Looking at their latest tree, this might just be Lars having been reviewing
code as they don't seem to have any users (though they run a lot of branches)
so might be one somewhere.  Lots of magic in that tree I never get
enough time to read through!
> 
>> If that callback mechanism isn't really supposed to address my use-case,
>> do you have a suggestion on how to implement such a thing?
> The basic approaches that have been taken before are:
> 1) Monolithic driver (we don't really like this one) which registers
> both IIO and input devices.
> 2) MFD layer underneath - this allows low level arbitration of access to
> the data.  This works just fine and gives a nice split but never feels
> as generic as it might be.. (which I think is where you are coming from).
> Something like the am335x driver would be an example of this (there are
> several).
> 3) Using a similar strategy to the iio-hwmon interface. I did write
> an iio-input bridge a long time ago that gives some idea of how this
> might work, but never got the time to finish it.
> http://www.spinics.net/lists/linux-iio/msg06879.html 
> specifically patch 4 http://www.spinics.net/lists/linux-iio/msg06881.html
> (I'm a little - *very* embarrassed at how long this one has taken -
> if anyone wants to pick it up and run with it I'd be most grateful!)
> 
> There are some 'sticky' issues with that still from what I recall
> * It is typically an either or with many drivers as they will either
> operate in the push mode (buffered within IIO) or the polled mode
> used by iio-hwmon.   This can be fixed by playing games within
> individual drivers, but a more general layer providing registered
> clients with cached readings when in push mode would be a great
> addition.
> * It was really targeted at the simpler accelerometer usecase.
> * We don't have support for passing what are considered 'events' by
> IIO - out of band data.  In your case the pen touch events.
> Passing them over is easy enough, but working out the correlation
> with the main data flow is going to be a little trickier.
> Meta data channels are possible, but we don't have a well defined
> interface for them yet.
> 
> Now I'd love to see a generic touch screen driver, but as you no
> doubt know there are some fiddly hooks in many of these where semi
> manual switching of feed voltages are needed.  A nice controller
> wrapping up a scheduled pass over the relevant combinations would
> be easier to handle I guess.  
> 
> Perhaps there are classes of device that are similar enough to
> allow a single simple driver?  I never learnt enough about these
> to be sure either way on that.  It comes up every time this
> question gets raised and yet no one has yet had time to do all that
> much about it :(
> 
> So as ever which way makes sense for you might be more a question
> of how much time you have available than anything else.
> Best is of course to make everything magic for everyone in the
> future and put together a generic touch screen driver ;) 
> Good is MFD.
> Anything else is worse.
> 
> Jonathan
>>
>> Thanks,
>>
>> Quentin
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Interface between IIO driver and an input driver

[Jonathan Cameron]

On 03/06/16 09:12, Marc Titinger wrote:
> 
> Hi All,
> 
> 
> (sorry Quentin, I here just share a related thought, not actually
> helping you much).
> 
> a nice feature would be to have some sort of "mixer" interface,
> similar to the one common with audio APIs. 
Lars in particular has been looking at extending the media controller
interface somewhat in this direction (and into audio ;) This is
the big hammer solution. It'll be cool in the long run but I don't
get the impression it'll come terribly quickly.
> An IIO driver can already
> use a separate trigger device as an interrupt source and I believe
> there is some wip to allow for software trigger sources instantiated
> with configfs.
Some are already supported (high resolution timers and after today 
a spin as fast as you can threaded trigger)
Others need the interface adding.
> Similarly, being able to link standard interfaces from
> 'input' or 'gpio' as an event source for (an) iio driver(s) would be
> great.
Indeed.  The input one kind of faded away back in 2012 (usual case
of lots of interest but no one did the last bit of work needed)
but then at the time it was all board files still and needed hard
coding.  We've recently been talking about doing configfs based binding
setup recently for iio-hwmon and similar but no code or ABI defined
yet.  See the thread Matt Ranostay started called 
[RFC] dynamic iio consumer channel mapping

GPIO one came up recently as well. 
http://marc.info/?l=linux-iio&m=145621588017248&w=2
Upshot is you need a way of saying 'this gpio might be used as a source
for triggering so make it available'.  In much the same way IIRC
the userspace gpio interfaces require the pin in question to be
made available by device tree or similar.
> Another benefit would be to use libiio and iiod as the unique
> connector to enumerate and control those interfaces, for instance
> with a product that can record some voltage (plain iio streaming) and
> switch on/off that power source using a standard gpio.
Sure, the more complex case of this is driving an external mux which
we also talked about recently.
Right now I can't find the thread - but upshot is it's 'interesting'
to do, though there are various possible approaches.
We were really talking blue sky stuff for that though - earlier steps
include output buffers etc (Lars!)

Jonathan
> BR,
> Mar.
> 
> 
> On 03/06/2016 09:17, Quentin Schulz wrote:
>> Hi all,
>>
>> The Allwinner SoCs all have an ADC that can also act as a touchscreen
>> controller and a thermal sensor. We currently have a driver for the two
>> latter functions in drivers/input/touchscreen/sun4i-ts.c, but we don't
>> have access to the ADC feature at all.
>>
>> Hence, I've been working on an IIO driver for that IP, with the hope
>> that we could use iio-hwmon for the thermal sensor, and a
>> yet-to-be-developped driver for the touchscreen part.
>>
>> The thermal sensor using iio_hwmon to communicate with the IIO driver is
>> working fine.
>>
>> However, the touchscreen needs all the channels of the ADC to be able
>> to get the coordinates. Moreover, you need to poke a few bits in some
>> registers to switch the ADC mode and activate a few interrupts (pen-up
>> and pen-down) to be able to operate as a touchscreen controller.
>> Therefore, I need a way to ask the IIO driver to poke these bits from
>> the input driver. For now, I am calling a function defined in my IIO
>> driver from my input driver to ask to switch between modes. Is it how it
>> is supposed to be done?
>>
>> Now that I switched to touchscreen mode, I need to get data from the IIO
>> driver. I already get hardware interrupts in the IIO driver when
>> something occurs with the touchscreen but now I need to notify the input
>> driver that I received an interrupt for the touchscreen and make  the
>> associated data available to the input driver. For now, I am using a
>> callback I set when probing the input driver and call this callback when
>> the correct interrupt is detected in the IIO driver's interrupt handler.
>> I pass the data through a parameter of this callback. However, I don't
>> think it is a good idea since the IIO driver has no idea on what the
>> callback is doing and it might just take too long to execute or even
>> freeze, which is definitely not what we want in an interrupt handler.
>> I've seen iio_channel_get_all_cb
>> (http://lxr.free-electrons.com/source/include/linux/iio/consumer.h#L79)
>> but I don't understand what it is doing or how to use it since there is
>> not a single driver using this function. Can someone explain what it is
>> supposed to do?
>> If that callback mechanism isn't really supposed to address my use-case,
>> do you have a suggestion on how to implement such a thing?
>>
>> Thanks,
>>
>> Quentin
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Interface between IIO driver and an input driver

[Lars-Peter Clausen]

On 06/03/2016 11:39 AM, Jonathan Cameron wrote:
> On 03/06/16 09:12, Marc Titinger wrote:
>>
>> Hi All,
>>
>>
>> (sorry Quentin, I here just share a related thought, not actually
>> helping you much).
>>
>> a nice feature would be to have some sort of "mixer" interface,
>> similar to the one common with audio APIs. 
> Lars in particular has been looking at extending the media controller
> interface somewhat in this direction (and into audio ;) This is
> the big hammer solution. It'll be cool in the long run but I don't
> get the impression it'll come terribly quickly.


That's primarily for describing the flow between different hardware modules
in hardware. I think in this case we only have software flow and in my
opinion this hardware is a classical case of multi-function device and
should be implemented as such. The MFD would take care of things like
interrupt multiplexing and resource allocation while each function gets its
own driver making use of the facilities provided by the MFD.

Re: Interface between IIO driver and an input driver

[Jonathan Cameron]

On 09/06/16 08:59, Lars-Peter Clausen wrote:
> On 06/03/2016 11:39 AM, Jonathan Cameron wrote:
>> On 03/06/16 09:12, Marc Titinger wrote:
>>>
>>> Hi All,
>>>
>>>
>>> (sorry Quentin, I here just share a related thought, not actually
>>> helping you much).
>>>
>>> a nice feature would be to have some sort of "mixer" interface,
>>> similar to the one common with audio APIs. 
>> Lars in particular has been looking at extending the media controller
>> interface somewhat in this direction (and into audio ;) This is
>> the big hammer solution. It'll be cool in the long run but I don't
>> get the impression it'll come terribly quickly.
> 
> 
> That's primarily for describing the flow between different hardware modules
> in hardware. I think in this case we only have software flow and in my
> opinion this hardware is a classical case of multi-function device and
> should be implemented as such. The MFD would take care of things like
> interrupt multiplexing and resource allocation while each function gets its
> own driver making use of the facilities provided by the MFD.
Fair enough, I think I agree that unfortunately there is too much touch
screen specific hardware handling to make a generic solution work.

I really ought to catch up with the media controller stuff ;)

> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>