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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
