From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752474AbdCELnM (ORCPT ); Sun, 5 Mar 2017 06:43:12 -0500 Received: from saturn.retrosnub.co.uk ([178.18.118.26]:59826 "EHLO saturn.retrosnub.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752362AbdCELnK (ORCPT ); Sun, 5 Mar 2017 06:43:10 -0500 Subject: Re: [PATCH v3 1/6] dt-bindings: iio: introduce trigger providers, consumers To: Rob Herring , Fabrice Gasnier References: <1488300679-3259-1-git-send-email-fabrice.gasnier@st.com> <1488300679-3259-2-git-send-email-fabrice.gasnier@st.com> <20170303062126.5bewa5u6o7wu7sy4@rob-hp-laptop> Cc: linux@armlinux.org.uk, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org, mark.rutland@arm.com, mcoquelin.stm32@gmail.com, alexandre.torgue@st.com, lars@metafoo.de, knaack.h@gmx.de, pmeerw@pmeerw.net, benjamin.gaignard@linaro.org, benjamin.gaignard@st.com, linus.walleij@linaro.org From: Jonathan Cameron Message-ID: <948e5b96-7a8f-406d-6d03-d129d1b2ce54@kernel.org> Date: Sun, 5 Mar 2017 11:43:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170303062126.5bewa5u6o7wu7sy4@rob-hp-laptop> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> --- >> .../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. Jonathan > > Rob > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Cameron Subject: Re: [PATCH v3 1/6] dt-bindings: iio: introduce trigger providers, consumers Date: Sun, 5 Mar 2017 11:43:02 +0000 Message-ID: <948e5b96-7a8f-406d-6d03-d129d1b2ce54@kernel.org> References: <1488300679-3259-1-git-send-email-fabrice.gasnier@st.com> <1488300679-3259-2-git-send-email-fabrice.gasnier@st.com> <20170303062126.5bewa5u6o7wu7sy4@rob-hp-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20170303062126.5bewa5u6o7wu7sy4@rob-hp-laptop> Sender: linux-iio-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rob Herring , Fabrice Gasnier Cc: linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, mark.rutland-5wv7dgnIgG8@public.gmane.org, mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, alexandre.torgue-qxv4g6HH51o@public.gmane.org, lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org, knaack.h-Mmb7MZpHnFY@public.gmane.org, pmeerw-jW+XmwGofnusTnJN9+BGXg@public.gmane.org, benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, benjamin.gaignard-qxv4g6HH51o@public.gmane.org, linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org List-Id: devicetree@vger.kernel.org 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 >> --- >> .../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. Jonathan > > Rob > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > From mboxrd@z Thu Jan 1 00:00:00 1970 From: jic23@kernel.org (Jonathan Cameron) Date: Sun, 5 Mar 2017 11:43:02 +0000 Subject: [PATCH v3 1/6] dt-bindings: iio: introduce trigger providers, consumers In-Reply-To: <20170303062126.5bewa5u6o7wu7sy4@rob-hp-laptop> References: <1488300679-3259-1-git-send-email-fabrice.gasnier@st.com> <1488300679-3259-2-git-send-email-fabrice.gasnier@st.com> <20170303062126.5bewa5u6o7wu7sy4@rob-hp-laptop> Message-ID: <948e5b96-7a8f-406d-6d03-d129d1b2ce54@kernel.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 >> --- >> .../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. Jonathan > > 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 >