From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752549AbdCELpd (ORCPT ); Sun, 5 Mar 2017 06:45:33 -0500 Received: from saturn.retrosnub.co.uk ([178.18.118.26]:59849 "EHLO saturn.retrosnub.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752362AbdCELpc (ORCPT ); Sun, 5 Mar 2017 06:45:32 -0500 Subject: Re: [PATCH v3 1/6] dt-bindings: iio: introduce trigger providers, consumers To: Fabrice Gasnier , Rob Herring 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: <46a15539-6297-46d1-e923-712b82fa4a7f@kernel.org> Date: Sun, 5 Mar 2017 11:45:28 +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: 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 09:32, Fabrice Gasnier wrote: > On 03/03/2017 07:21 AM, 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 > 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. > >> 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 > >> >> 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:45:28 +0000 Message-ID: <46a15539-6297-46d1-e923-712b82fa4a7f@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: Sender: linux-iio-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Fabrice Gasnier , Rob Herring 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 09:32, Fabrice Gasnier wrote: > On 03/03/2017 07:21 AM, 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 > 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. > >> 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 > >> >> 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:45:28 +0000 Subject: [PATCH v3 1/6] dt-bindings: iio: introduce trigger providers, consumers In-Reply-To: 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: <46a15539-6297-46d1-e923-712b82fa4a7f@kernel.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 03/03/17 09:32, Fabrice Gasnier wrote: > On 03/03/2017 07:21 AM, 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 > 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. > >> 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 > >> >> 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