[PATCH v3 1/6] dt-bindings: iio: introduce trigger providers, consumers

[Rob Herring]

On Sun, Mar 05, 2017 at 12:13:36PM +0000, Jonathan Cameron wrote:
> On 05/03/17 11:43, Jonathan Cameron wrote:
> > On 03/03/17 06:21, Rob Herring wrote:
> >> On Tue, Feb 28, 2017 at 05:51:14PM +0100, Fabrice Gasnier wrote:
> >>> Document iio provider and consumer bindings.
> >>>
> >>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier at st.com>
> >>> ---
> >>>  .../devicetree/bindings/iio/iio-bindings.txt       | 38 ++++++++++++++++++++++
> >>>  1 file changed, 38 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> >>> index 68d6f8c..01765e9 100644
> >>> --- a/Documentation/devicetree/bindings/iio/iio-bindings.txt
> >>> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> >>> @@ -95,3 +95,41 @@ vdd channel is connected to output 0 of the &ref device.
> >>>  		io-channels = <&adc 10>, <&adc 11>;
> >>>  		io-channel-names = "adc1", "adc2";
> >>>  	};
> >>> +
> >>> +==IIO trigger providers==
> >>> +Sources of IIO triggers can be represented by any node in the device
> >>> +tree. Those nodes are designated as IIO trigger providers. IIO trigger
> >>> +consumer uses a phandle and an IIO trigger specifier to connect to an
> >>> +IIO trigger provider.
> >>> +An IIO trigger specifier is an array of one or more cells identifying
> >>> +the IIO trigger output on a device. The length of an IIO trigger
> >>> +specifier is defined by the value of a #io-trigger-cells property in
> >>> +the IIO trigger provider node.
> >>> +
> >>> +Required properties:
> >>> +#io-trigger-cells:
> >>> +		Number of cells in an IIO trigger specifier; Typically
> >>> +		0 for nodes with a simple IIO trigger output.
> >>> +
> >>> +Example:
> >>> +	trig0: interrupt-trigger0 {
> >>> +		#io-trigger-cells = <0>;
> >>> +		compatible = "interrupt-trigger";
> >>> +		interrupts = <11 0>;
> >>> +		interrupt-parent = <&gpioa>;
> >>> +	}
> >>> +
> >>> +==IIO trigger consumers==
> >>> +Required properties:
> >>> +- io-triggers:	List of phandle representing the IIO trigger specifier.
> >>> +
> >>> +Optional properties:
> >>> +- io-trigger-names :
> >>> +		List of IIO trigger name strings that matches elements
> >>> +		in 'io-triggers' list property.
> >>> +
> >>> +Example:
> >>> +	some_trigger_consumer {
> >>> +		io-triggers = <&trig0>;
> >>> +		io-trigger-names = "mytrig";
> >>> +	}
> >>
> >> I have some reservations about this. We could just as easily add the 
> >> interrupt directly to the consumer node and use "trigger" for a standard 
> >> interrupt name. So the question is whether this extra level of 
> >> indirection is needed? 
> > 
> > First thing to note here, is that Fabrice's use of the generic interrupt
> > trigger is an extremely 'unusual' one! Normal use case is that we have
> > a random gpio pin providing interrupts to driver triggering on random
> > devices - there need be no association between the two whatsoever.
> > So what we are doing here is 'allowing' an interrupt to provide a trigger.
> > It's not necessarily the one going to be used by any particular device
> > driver.  The decision of which trigger to use is definitely one for
> > userspace, not something that should be configured in to the device tree.
> > 
> > For this particular case you could in theory just do it by using an interrupt
> > as you describe.  Ultimately though we should be able to play more complex
> > games with this device and having it able to handle any trigger - which 
> > includes those not using the direct hardware route.  It'll be up to the
> > driver to figure out when it can use the fast method and when it can't.
> > 
> > Conversely, even when we are using this hardware route to drive the
> > triggering it should be possible to hang off a device to be triggered
> > by the interrupt via the kernel rather than directly. 
> > 
> > So from a device tree point of view we are just describing the fact that
> > there is a pin, which may be used to trigger something.  What that something
> > is, is a question for userspace not the device tree.
> > 
> Ah, I'm half asleep this morning.  Clearly there is a more general follow
> up question.  If we are arguing these are generic, why are we setting
> up the mapping in device tree?
> 
> My gut feeling is we shouldn't be.  So I think we need the first chunk
> above but the latter part should be a job for userspace not the devicetree.

So you mean keep the provider side, but get rid of the consumer? That 
makes sense to me.

Rob