| Message ID | 1488300679-3259-2-git-send-email-fabrice.gasnier@st.com |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
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@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? Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <fabrice.gasnier@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 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. > 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. Please advise, Best Regards, Fabrice > > Rob > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@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. 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 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <fabrice.gasnier@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 > 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@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. Jonathan > 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 >> > > -- > 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 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/15/2017 08:25 PM, Rob Herring wrote: > 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@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 Hi Rob, Jonathan, Yes, I agree this is unusual. >>> 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. Agreed. Still, to benefit from hw capabilities, driver needs to have a way to identify a particular trigger as a direct hardware route, or not (and then default software handling, btw, that still needs to be addressed in stm32-adc). DT Provider/consumer may help to achieve this. >>> >>> 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. In case getting rid of the consumer part, I still need one way, on consumer side (stm32-adc) to specifically map EXTI signal in ADC hardware, do some checks on trigger to validate hardware route. I'm not sure how to handle this if I get rid of consumer part. Shall I use something else not mentioned here? (put trigger dt node as child node of stm32 adc, then use dev bus? ...) Another way is as suggested by Rob in earlier comment: directly use this interrupt in consumer dt node, e.g. in stm32-adc node. And register relevant trigger and so on, from stm32-adc driver. Please advise. Thanks for reviewing Best Regards, Fabrice > > Rob > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 17/03/17 15:59, Fabrice Gasnier wrote: > On 03/15/2017 08:25 PM, Rob Herring wrote: >> 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@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 > Hi Rob, Jonathan, > > Yes, I agree this is unusual. > >>>> 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. > Agreed. Still, to benefit from hw capabilities, driver needs to have a > way to identify a particular trigger as a direct hardware route, or not > (and then default software handling, btw, that still needs to be > addressed in stm32-adc). DT Provider/consumer may help to achieve this. A simple additional callback that has access to both provider and consumer should have sufficient data to figure this out somehow. > >>>> >>>> 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. > In case getting rid of the consumer part, I still need one way, on > consumer side (stm32-adc) to specifically map EXTI signal in ADC > hardware, do some checks on trigger to validate hardware route. > I'm not sure how to handle this if I get rid of consumer part. > Shall I use something else not mentioned here? (put trigger dt node as > child node of stm32 adc, then use dev bus? ...) Something along those lines might work. > > Another way is as suggested by Rob in earlier comment: directly use this > interrupt in consumer dt node, e.g. in stm32-adc node. And register > relevant trigger and so on, from stm32-adc driver. > Please advise. Also a possible option, be it a little restrictive given in theory at least we could have a situation where this trigger had hardware routes to more than one driver. So I don't have a answer right now. Would need to dig a little into the actual drivers in question... Run out of time this weekend, but might get some time during the week. Brief thoughts though: the interrupt trigger obviously knows the interrupt in question. Can we provide some access for the ADC to which interrupts are valid and then an optional callback like validate_trigger that is capable of discovering that there is a hardware route? Some sort of handle that the trigger provides would give the device scope to see if it knows it can do 'magic' or not, return value could indicate to the trigger whether it is going to be doing it with 'magic' or really providing interrupts. Jonathan > > Thanks for reviewing > 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 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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"; + }
Document iio provider and consumer bindings. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> --- .../devicetree/bindings/iio/iio-bindings.txt | 38 ++++++++++++++++++++++ 1 file changed, 38 insertions(+)