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

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

[Jonathan Cameron]

On 19/02/16 19:18, Gregor Boirie wrote:
> From: Grégor Boirie <gregor.boirie-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org>
> 
> Signed-off-by: Gregor Boirie <gregor.boirie-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org>
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.

Any suggestions on appropriate naming?

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).

Jonathan
> ---
>  drivers/iio/trigger/iio-trig-interrupt.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/trigger/iio-trig-interrupt.c b/drivers/iio/trigger/iio-trig-interrupt.c
> index 572bc6f..3c4e18f 100644
> --- a/drivers/iio/trigger/iio-trig-interrupt.c
> +++ b/drivers/iio/trigger/iio-trig-interrupt.c
> @@ -104,11 +104,20 @@ static int iio_interrupt_trigger_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +#if defined(CONFIG_OF)
> +static const struct of_device_id iio_interrupt_trigger_of_match[] = {
> +	{ .compatible = "iio-interrupt-trigger" },
> +	{}
> +};
> +#endif
> +
>  static struct platform_driver iio_interrupt_trigger_driver = {
>  	.probe = iio_interrupt_trigger_probe,
>  	.remove = iio_interrupt_trigger_remove,
>  	.driver = {
> -		.name = "iio_interrupt_trigger",
> +		.name           = "iio_interrupt_trigger",
> +		.owner          = THIS_MODULE,
> +		.of_match_table = of_match_ptr(iio_interrupt_trigger_of_match)
>  	},
>  };
>  
> 

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

[Rob Herring]

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-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org>
> > 
> > Signed-off-by: Gregor Boirie <gregor.boirie-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org>
> 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

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

[Gregor Boirie]

On 02/22/2016 08:05 PM, 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-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org>
>>>
>>> Signed-off-by: Gregor Boirie <gregor.boirie-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org>
>> 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?
Our setup uses an ARM software generated interrupt coming from an 
alternate core
running a custom OS. Usage is however quite similar to GPIO irqs.

[snip]

Grégor.

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

[Jonathan Cameron]

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-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org>
>>>
>>> Signed-off-by: Gregor Boirie <gregor.boirie-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org>
>> 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