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? 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. > 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. Rob -- 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
