From: Marc Zyngier <maz@kernel.org> To: Alexandre TORGUE <alexandre.torgue@foss.st.com> Cc: Rob Herring <robh@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <linux-stm32@st-md-mailman.stormreply.com>, <devicetree@vger.kernel.org> Subject: Re: [PATCH v2 1/5] dt-bindings: interrupt-controller: Update STM32 EXTI interrupt controller Date: Mon, 20 Dec 2021 12:34:44 +0000 [thread overview] Message-ID: <87bl1bwj2z.wl-maz@kernel.org> (raw) In-Reply-To: <3f8acbb8-0b7e-2f47-eefc-67e5a7632445@foss.st.com> On Fri, 17 Dec 2021 13:39:11 +0000, Alexandre TORGUE <alexandre.torgue@foss.st.com> wrote: > > On 12/16/21 9:15 PM, Rob Herring wrote: > > On Wed, Dec 15, 2021 at 11:58:43AM +0100, Alexandre Torgue wrote: > >> Document new entry "st,exti-mapping" which links EXTI lines with GIC > >> interrupt lines and add an include file to define EXTI interrupt type. > >> > >> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> > >> > >> diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml > >> index d19c881b4abc..e08bb51e97a8 100644 > >> --- a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml > >> +++ b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml > >> @@ -41,6 +41,17 @@ properties: > >> description: > >> Interrupts references to primary interrupt controller > >> + st,exti-mapping: > >> + $ref: "/schemas/types.yaml#/definitions/uint32-matrix" > >> + description: | > >> + Define mapping between EXTI lines and GIC irq lines. Should be: > >> + st,exti-mapping = <EXTI_LINE GIC_IRQ EXTI_TYPE>, ...; > >> + With: > >> + - EXTI_LINE: EXTI line number. > >> + - GIC_IRQ: GIC IRQ associated to the EXTI line. > >> + - EXTI_TYPE: STM32_EXTI_TYPE_CONFIGURABLE or STM32_EXTI_TYPE_DIRECT. > >> + Defined in include/dt-bindings/interrupt-controller/stm32-exti.h > > > > No custom properties for this. See[1][2][3]. > > > > Thanks for inputs. In my case the mapping consists to map an EXTI line > with a GIC irq line which could be done using interrupt-map (avoiding > to parse it in my driver). The problem is that 'interrupt-map' defines an interrupt mapping between an input and an output, and that mentioning the GIC in such a table will only result in your EXTI to be bypassed. 'interrupt-map' really is a dispatch table for targeting an interrupt controller (or multiple controllers, even), but really isn't the correct tool to carry configuration informations to an interrupt controller driver. > But for each EXTI/GIC association I would > like also to describe the EXTI_TYPE (which actually describe the well > irqchip to use inside my exti driver) . This property is not generic > and so I assume I can't use a generic binding such "interrupt-map". > > If the solution consists to use a common binding (i.e. interrupt-map) > plus a conversion table in exti driver to affect the well irq_chip to > the well EXTI line then we could envisage to keep the whole mapping > inside the driver (even if it's not the best solution). A possible solution would be to have: - A set of standard 'interrupts' properties describing the output signals - A set of properties describing the input to output mapping (if relevant) and additional configuration information that for the interrupt controller driver. M. -- Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org> To: Alexandre TORGUE <alexandre.torgue@foss.st.com> Cc: Rob Herring <robh@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <linux-stm32@st-md-mailman.stormreply.com>, <devicetree@vger.kernel.org> Subject: Re: [PATCH v2 1/5] dt-bindings: interrupt-controller: Update STM32 EXTI interrupt controller Date: Mon, 20 Dec 2021 12:34:44 +0000 [thread overview] Message-ID: <87bl1bwj2z.wl-maz@kernel.org> (raw) In-Reply-To: <3f8acbb8-0b7e-2f47-eefc-67e5a7632445@foss.st.com> On Fri, 17 Dec 2021 13:39:11 +0000, Alexandre TORGUE <alexandre.torgue@foss.st.com> wrote: > > On 12/16/21 9:15 PM, Rob Herring wrote: > > On Wed, Dec 15, 2021 at 11:58:43AM +0100, Alexandre Torgue wrote: > >> Document new entry "st,exti-mapping" which links EXTI lines with GIC > >> interrupt lines and add an include file to define EXTI interrupt type. > >> > >> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> > >> > >> diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml > >> index d19c881b4abc..e08bb51e97a8 100644 > >> --- a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml > >> +++ b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml > >> @@ -41,6 +41,17 @@ properties: > >> description: > >> Interrupts references to primary interrupt controller > >> + st,exti-mapping: > >> + $ref: "/schemas/types.yaml#/definitions/uint32-matrix" > >> + description: | > >> + Define mapping between EXTI lines and GIC irq lines. Should be: > >> + st,exti-mapping = <EXTI_LINE GIC_IRQ EXTI_TYPE>, ...; > >> + With: > >> + - EXTI_LINE: EXTI line number. > >> + - GIC_IRQ: GIC IRQ associated to the EXTI line. > >> + - EXTI_TYPE: STM32_EXTI_TYPE_CONFIGURABLE or STM32_EXTI_TYPE_DIRECT. > >> + Defined in include/dt-bindings/interrupt-controller/stm32-exti.h > > > > No custom properties for this. See[1][2][3]. > > > > Thanks for inputs. In my case the mapping consists to map an EXTI line > with a GIC irq line which could be done using interrupt-map (avoiding > to parse it in my driver). The problem is that 'interrupt-map' defines an interrupt mapping between an input and an output, and that mentioning the GIC in such a table will only result in your EXTI to be bypassed. 'interrupt-map' really is a dispatch table for targeting an interrupt controller (or multiple controllers, even), but really isn't the correct tool to carry configuration informations to an interrupt controller driver. > But for each EXTI/GIC association I would > like also to describe the EXTI_TYPE (which actually describe the well > irqchip to use inside my exti driver) . This property is not generic > and so I assume I can't use a generic binding such "interrupt-map". > > If the solution consists to use a common binding (i.e. interrupt-map) > plus a conversion table in exti driver to affect the well irq_chip to > the well EXTI line then we could envisage to keep the whole mapping > inside the driver (even if it's not the best solution). A possible solution would be to have: - A set of standard 'interrupts' properties describing the output signals - A set of properties describing the input to output mapping (if relevant) and additional configuration information that for the interrupt controller driver. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-12-20 12:34 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-15 10:58 [PATCH v2 0/5] Add STM32MP13 EXTI support Alexandre Torgue 2021-12-15 10:58 ` Alexandre Torgue 2021-12-15 10:58 ` [PATCH v2 1/5] dt-bindings: interrupt-controller: Update STM32 EXTI interrupt controller Alexandre Torgue 2021-12-15 10:58 ` Alexandre Torgue 2021-12-16 20:15 ` Rob Herring 2021-12-16 20:15 ` Rob Herring 2021-12-17 13:39 ` Alexandre TORGUE 2021-12-17 13:39 ` Alexandre TORGUE 2021-12-20 12:34 ` Marc Zyngier [this message] 2021-12-20 12:34 ` Marc Zyngier 2022-01-04 17:14 ` Alexandre TORGUE 2022-01-04 17:14 ` Alexandre TORGUE 2021-12-15 10:58 ` [PATCH v2 2/5] irqchip/stm32: use device tree to define EXTI-GIC mapping Alexandre Torgue 2021-12-15 10:58 ` Alexandre Torgue 2021-12-15 10:58 ` [PATCH v2 3/5] dt-bindings: interrupt-controller: stm32-exti: document st,stm32mp13-exti Alexandre Torgue 2021-12-15 10:58 ` [PATCH v2 3/5] dt-bindings: interrupt-controller: stm32-exti: document st, stm32mp13-exti Alexandre Torgue 2021-12-16 20:15 ` [PATCH v2 3/5] dt-bindings: interrupt-controller: stm32-exti: document st,stm32mp13-exti Rob Herring 2021-12-16 20:15 ` Rob Herring 2021-12-15 10:58 ` [PATCH v2 4/5] irqchip/stm32-exti: add STM32MP13 support Alexandre Torgue 2021-12-15 10:58 ` Alexandre Torgue 2021-12-15 10:58 ` [PATCH v2 5/5] ARM: dts: stm32: Enable EXTI on stm32mp13 Alexandre Torgue 2021-12-15 10:58 ` Alexandre Torgue
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87bl1bwj2z.wl-maz@kernel.org \ --to=maz@kernel.org \ --cc=alexandre.torgue@foss.st.com \ --cc=devicetree@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-stm32@st-md-mailman.stormreply.com \ --cc=robh@kernel.org \ --cc=tglx@linutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.