On Sat, Feb 27, 2016 at 2:05 PM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > Hi Gregor and all, > > This patch was motivated by a proposal from Gregor to put a kthread in the > ms5611 driver to basically spin and grap data as fast as possible. > I can see the application is realistic but was unhappy with the per driver > code change approach. Hence I decided to test out another approach over > a couple of hours this morning. This is a good idea. > > Hence in brief the use case is: > 1) Read from a 'capture on demand' device as quickly as possible. For tests > I used a max1363 on an ancient stargate2 because I have a few lying around and > it is the right sort of device. > 2) Do it in a fashion that allows higher priority code to slow it down if > needed > 3) Allow lots of devices to run in the same fashion but without each one > having to wait for them all to finish. > > As a quick aside, configfs (or at least iio-trig-hrtimer) isn't working > on my platform right now so I'll need to follow that up when I get a bit more > time. Hence I based this off the sysfs trigger (which is an old friend :) > Which part of configfs support didn't work :). > So first some background on our 'non hardware' triggers. > > 1) First there were hardware triggers or things that looked very much like > hardware triggers (e.g. the periodic rtc driver that is on it's way out - > finally). These call 'real' interrupt handlers - they predated the > threaded interrupts stuff so everything used to have to have a top half > anyway to schedule the bottom half (which later became a thread) > 2) It made sense in some devices - dataready triggered ones typically - to > grab timestamps and sometimes some other state in the top half. > 3) Threaded interrupts came along getting rid of most of the top half code but > typically leaving some timestamping etc in there. > 4) Somewhere in this process we had the sysfs trigger come along as a really > handy test tool (initially). This first of all simply didn't run top halfs > but later jumped through some hoops to get into interrupt context to call > them so it looked like a hardware interrupt. This is now nicely wrapped up > in IRQ_WORK etc. One major advantage of this is that we have multiple > devices triggering off one interrupt they will run in their own threads. > > Anyhow so what we have here goes back to the bottom half (now thread) element > only as we can do that quick and dirty (as an aside iio_poll_chained is > really badly named - I suspect I either messed this up or the naming used > in the irq subsystem was clarified sometime later) > > So here we launch a kthread on the spin up of a buffer attached to this > trigger. That then calls all devices poll func (thread part) in the thread > one after another. > > So what are the issues with this: > 1) Multiple devices connected to this trigger will not have their thread > handlers potentially run in parallel. (do we care? - the usecase wouldn't > put more than on on given trigger anyway) > 2) We have no current way of identifying if a device needs a top half called > (say to get a timestamp). This should be easy enough to add as a flag in > struct iio_dev and enforce with the validate callbacks. > 3) For those devices that do something that doesn't need to be in the top half > (from a not hanging point of view - if not from a get the best answer point > of view) we have no way of knowing this or calling the top half if we did. > > I think the last two can be worked around (3 might be 'tricky!) > > Anyhow what do people think? > > For some numbers I ran this on a pxa270 with a max1363 hanging of the i2c > bus. generic_buffer into a ramdisk, watershed at 64 buffer length 128. Ran > happily at upwards of a kHz though with some 5msec pauses (presumably something > higher priority came along). > > Jonathan > > Jonathan Cameron (1): > iio:trigger: Experimental kthread tight loop trigger (thread only) > > drivers/iio/trigger/Kconfig | 5 + > drivers/iio/trigger/Makefile | 1 + > drivers/iio/trigger/iio-trig-loop.c | 245 ++++++++++++++++++++++++++++++++++++ > 3 files changed, 251 insertions(+) > create mode 100644 drivers/iio/trigger/iio-trig-loop.c > > -- > 2.7.1 > > -- > 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
