Re: [PATCH v1 1/2] iio:iio-interrupt-trigger: device-tree support

[Jonathan Cameron <jic23@kernel.org>]

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@parrot.com>
>>>
>>> Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com>
>> 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