On 22/02/16 19:05, Rob Herring wrote: > On Sun, Feb 21, 2016 at 07:55:24PM +0000, Jonathan Cameron wrote: >> On 19/02/16 19:18, Gregor Boirie wrote: >>> From: Grégor Boirie <gregor.boirie@xxxxxxxxxx> >>> >>> Signed-off-by: Gregor Boirie <gregor.boirie@xxxxxxxxxx> >> Snag here is that iio_interrupt_trigger is a very linux specific >> name and device tree bindings should be just about the hardware. >> >> Not entirely sure how we avoid this though as the use is rather >> hard to describe generically. >> >> cc'd device tree list and bindings maintainers. >> >> As a brief summary - this IIO trigger driver takes a generic >> interrupt (from whatever) and uses it to drive sampling of IIO devices. >> The interrupt might be associated with particularly simple sensors directly >> but is more commonly a gpio interrupt line used cause samples to be captured >> from unrelated devices. Sometimes the source of that interrupt can be a convoluted >> external mux setup over which linux has no control for example. > > If linux has no control of the setup, then do we care? It's just some > blackbox driving a signal. > >> Any suggestions on appropriate naming? > > I would think of it outside of IIO perhaps. We already have gpio-keys > which is kind of similar. Maybe just "external interrupt"? Is it always > a GPIO interrupt or could be polled GPIO or some other mechanism? The challenge is that we need to be able to capture it's use. > > Could you add "trigger-gpios" to every device that uses it and allow for > it to appear multiple times? It somewhat depends on how static setting > the trigger source is whether that would be appropriate. Right now we don't have a device - the interrupt trigger is only soft associated (via sysfs) with it's users at a later date. I think we just have 'make up a device' for this to represent the use case so we can probe the interrupt trigger driver in iio. sensor sampling trigger perhaps? > >> We aren't really describing hardware here, rather a policy decision on what >> a given interrupt is to be used for. >> >> I suppose ultimately we could take the view this should be handled via another >> route (from userspace via an appropriate configfs interface for example). > > You would still need to know which GPIOs you could use or assign, so I > think we need something in DT. Absolutely. Short of allowing completely generic grabbing from a configfs call of an interrupt, definitely need to specify which interrupts are suitable for use like this. I think a 'fictional' device is going to have to exist to allow this.. Jonathan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
