On 03/03/17 09:32, Fabrice Gasnier wrote:

On 03/03/2017 07:21 AM, Rob Herring wrote:

quoted

On Tue, Feb 28, 2017 at 05:51:14PM +0100, Fabrice Gasnier wrote:

quoted

Document iio provider and consumer bindings.

Signed-off-by: Fabrice Gasnier <redacted>
---
 .../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

Hi Rob,

Thanks for reviewing.

I hope I don't miss your point here... However, if I correctly
understand it:
Yes, this can be one way to get interrupt(s) directly from consumer node. Then, I understand consumer has to do exact same as what is being done in "iio_interrupt_trigger" for instance, basically:
- request irq, alloc and register trigger, do irq handling to call
trigger poll routine.

With current patchset, consumer is able to use standard trigger like
"interrupt-trigger" from DT. Please note I propose to add OF support
for it in current patchset (e.g. PATCHs 2 & 3). Currently only platform
data is supported.

-> And, please refer to PATCHs 5 & 6, I need to have some way to identify interrupt line (connected in HW to STM32 ADC IP). Currently,
this is best I came up with, trying to re-use, be generic, and to describe this HW in DT.

Of course, the other way is still valid. Also, I want to highlight,
STM32 has other IP, e.g. DAC, where same can be re-used then. This
will avoid having duplicates.

Just to jump back a stage.  The binding here isn't stm32 specific
at all.  In general this binding allows for triggering anything
(currently IIO) from an interrupt. Nothing more - so that is the
level at which it should be considered.

quoted

interrupt name. So the question is whether this extra level of
indirection is needed?

Purpose is to be able to get one or more named trigger(s) on consumer
side. Idea is to adopt similar 'philosophy' as in other bindings like
pinctrl, clk... where consumer has possibility to get them by name.
I hope this clarifies.

Again, taking this in the general sense rather than on the stm32:
flexibility - if it makes sense to expose something to userspace we
do.  We could in theory list all the possible interrupt sources that
might drive each device in a system and then expose that to userspace
but that is hideous!

Please advise,
Best Regards,
Fabrice

quoted

Rob

-- 
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html