From: David Lechner <david@lechnology.com> To: Suman Anna <s-anna@ti.com>, Marc Zyngier <marc.zyngier@arm.com>, Rob Herring <robh+dt@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Jason Cooper <jason@lakedaemon.net> Cc: Tony Lindgren <tony@atomide.com>, "Andrew F. Davis" <afd@ti.com>, Roger Quadros <rogerq@ti.com>, Lokesh Vutla <lokeshvutla@ti.com>, Grygorii Strashko <grygorii.strashko@ti.com>, Sekhar Nori <nsekhar@ti.com>, Murali Karicheri <m-karicheri2@ti.com>, devicetree@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/6] irqchip/irq-pruss-intc: Add helper functions to configure internal mapping Date: Wed, 17 Jul 2019 12:57:29 -0500 [thread overview] Message-ID: <22825f06-d968-03a7-585b-8cbf4123915c@lechnology.com> (raw) In-Reply-To: <23ae1767-3531-ea57-2c82-f2657baa123f@ti.com> On 7/16/19 6:29 PM, Suman Anna wrote: > Hi David, > > On 7/10/19 10:10 PM, David Lechner wrote: >> On 7/7/19 10:52 PM, Suman Anna wrote: >>> The PRUSS INTC receives a number of system input interrupt source events >>> and supports individual control configuration and hardware >>> prioritization. >>> These input events can be mapped to some output host interrupts through 2 >>> levels of many-to-one mapping i.e. events to channel mapping and channels >>> to host interrupts. >>> >>> This mapping information is provided through the PRU firmware that is >>> loaded onto a PRU core/s or through the device tree node of the PRU >> > > Thanks for the thorough review and alternate solutions/suggestions. > >> What will the device tree bindings for this look like? > > They would be as in the below patch you already figured. Ah, makes sense now: the mapping is defined in the remoteproc node rather than in the interrupt controller node. > >> >> Looking back at Rob's comment on the initial series [1], I still think >> that increasing the #interrupt-cells sounds like a reasonable solution. >> >> [1]: https://patchwork.kernel.org/patch/10697705/#22375155 > > So, there are couple of reasons why I did not use an extended > #interrupt-cells: > > 1. There is only one irq descriptor associated with each event, and the > usage of events is typically per application. And the descriptor mapping > is done once. We can have two different applications use the same event > with different mappings. So we want this programming done at > application's usage of PRU (so done when a consumer driver acquires a > PRU processor(s) which are treated as an exclusive resource). All the > different application properties that you saw in [1] are configured at > the time of acquiring a PRU and reset when they release a PRU. > > 2. The configuration is performed by Linux for all host interrupts and > channels, and this was primarily done to save the very limited IRAM > space for those needed by the PRUs. From firmware's point of view, this > was offloaded to the ARM OS driver/infrastructure, but in general it is > a design by contract between a PRU client driver and its firmware. Also, > the DT binding semantics using interrupts property and request_irq() > typically limits these to interrupts only being requested by MPU, and so > will leave out those needed by PRUs. > Hmm... case 1. is a tricky one indeed. If there are going to be times where an event requires multiple mappings, I agree that this doesn't seem to fit into any existing device tree bindings.
WARNING: multiple messages have this Message-ID (diff)
From: David Lechner <david@lechnology.com> To: Suman Anna <s-anna@ti.com>, Marc Zyngier <marc.zyngier@arm.com>, Rob Herring <robh+dt@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Jason Cooper <jason@lakedaemon.net> Cc: devicetree@vger.kernel.org, Grygorii Strashko <grygorii.strashko@ti.com>, Tony Lindgren <tony@atomide.com>, Sekhar Nori <nsekhar@ti.com>, linux-kernel@vger.kernel.org, "Andrew F. Davis" <afd@ti.com>, Lokesh Vutla <lokeshvutla@ti.com>, Murali Karicheri <m-karicheri2@ti.com>, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Roger Quadros <rogerq@ti.com> Subject: Re: [PATCH 4/6] irqchip/irq-pruss-intc: Add helper functions to configure internal mapping Date: Wed, 17 Jul 2019 12:57:29 -0500 [thread overview] Message-ID: <22825f06-d968-03a7-585b-8cbf4123915c@lechnology.com> (raw) In-Reply-To: <23ae1767-3531-ea57-2c82-f2657baa123f@ti.com> On 7/16/19 6:29 PM, Suman Anna wrote: > Hi David, > > On 7/10/19 10:10 PM, David Lechner wrote: >> On 7/7/19 10:52 PM, Suman Anna wrote: >>> The PRUSS INTC receives a number of system input interrupt source events >>> and supports individual control configuration and hardware >>> prioritization. >>> These input events can be mapped to some output host interrupts through 2 >>> levels of many-to-one mapping i.e. events to channel mapping and channels >>> to host interrupts. >>> >>> This mapping information is provided through the PRU firmware that is >>> loaded onto a PRU core/s or through the device tree node of the PRU >> > > Thanks for the thorough review and alternate solutions/suggestions. > >> What will the device tree bindings for this look like? > > They would be as in the below patch you already figured. Ah, makes sense now: the mapping is defined in the remoteproc node rather than in the interrupt controller node. > >> >> Looking back at Rob's comment on the initial series [1], I still think >> that increasing the #interrupt-cells sounds like a reasonable solution. >> >> [1]: https://patchwork.kernel.org/patch/10697705/#22375155 > > So, there are couple of reasons why I did not use an extended > #interrupt-cells: > > 1. There is only one irq descriptor associated with each event, and the > usage of events is typically per application. And the descriptor mapping > is done once. We can have two different applications use the same event > with different mappings. So we want this programming done at > application's usage of PRU (so done when a consumer driver acquires a > PRU processor(s) which are treated as an exclusive resource). All the > different application properties that you saw in [1] are configured at > the time of acquiring a PRU and reset when they release a PRU. > > 2. The configuration is performed by Linux for all host interrupts and > channels, and this was primarily done to save the very limited IRAM > space for those needed by the PRUs. From firmware's point of view, this > was offloaded to the ARM OS driver/infrastructure, but in general it is > a design by contract between a PRU client driver and its firmware. Also, > the DT binding semantics using interrupts property and request_irq() > typically limits these to interrupts only being requested by MPU, and so > will leave out those needed by PRUs. > Hmm... case 1. is a tricky one indeed. If there are going to be times where an event requires multiple mappings, I agree that this doesn't seem to fit into any existing device tree bindings. _______________________________________________ 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:[~2019-07-17 17:57 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-08 3:52 [PATCH 0/6] Add TI PRUSS Local Interrupt Controller IRQChip driver Suman Anna 2019-07-08 3:52 ` Suman Anna 2019-07-08 3:52 ` Suman Anna 2019-07-08 3:52 ` [PATCH 1/6] dt-bindings: irqchip: Add PRUSS interrupt controller bindings Suman Anna 2019-07-08 3:52 ` Suman Anna 2019-07-08 3:52 ` Suman Anna 2019-07-08 14:34 ` Andrew F. Davis 2019-07-08 14:34 ` Andrew F. Davis 2019-07-08 14:34 ` Andrew F. Davis 2019-07-08 15:59 ` Suman Anna 2019-07-08 15:59 ` Suman Anna 2019-07-08 15:59 ` Suman Anna 2019-07-10 17:08 ` David Lechner 2019-07-10 17:08 ` David Lechner 2019-07-10 17:08 ` David Lechner 2019-07-16 17:07 ` Suman Anna 2019-07-16 17:07 ` Suman Anna 2019-07-24 16:34 ` Rob Herring 2019-07-24 16:34 ` Rob Herring 2019-07-24 16:34 ` Rob Herring 2019-07-24 19:42 ` Suman Anna 2019-07-24 19:42 ` Suman Anna 2019-07-24 19:42 ` Suman Anna 2019-07-25 22:27 ` Rob Herring 2019-07-25 22:27 ` Rob Herring 2019-07-25 22:27 ` Rob Herring 2019-07-08 3:52 ` [PATCH 2/6] irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS interrupts Suman Anna 2019-07-08 3:52 ` Suman Anna 2019-07-08 3:52 ` Suman Anna 2019-07-11 16:45 ` David Lechner 2019-07-11 16:45 ` David Lechner 2019-07-16 17:21 ` Suman Anna 2019-07-16 17:21 ` Suman Anna 2019-07-16 17:21 ` Suman Anna 2019-07-17 17:21 ` David Lechner 2019-07-17 17:21 ` David Lechner 2019-07-17 18:56 ` Suman Anna 2019-07-17 18:56 ` Suman Anna 2019-07-17 18:56 ` Suman Anna 2019-07-08 3:52 ` [PATCH 3/6] irqchip/irq-pruss-intc: Add support for shared and invalid interrupts Suman Anna 2019-07-08 3:52 ` Suman Anna 2019-07-08 3:52 ` Suman Anna 2019-07-08 3:52 ` [PATCH 4/6] irqchip/irq-pruss-intc: Add helper functions to configure internal mapping Suman Anna 2019-07-08 3:52 ` Suman Anna 2019-07-08 3:52 ` Suman Anna 2019-07-11 3:10 ` David Lechner 2019-07-11 3:10 ` David Lechner 2019-07-11 22:09 ` David Lechner 2019-07-11 22:09 ` David Lechner 2019-07-16 23:29 ` Suman Anna 2019-07-16 23:29 ` Suman Anna 2019-07-16 23:29 ` Suman Anna 2019-07-17 17:57 ` David Lechner [this message] 2019-07-17 17:57 ` David Lechner 2019-07-17 19:04 ` Suman Anna 2019-07-17 19:04 ` Suman Anna 2019-07-17 19:04 ` Suman Anna 2019-07-08 3:52 ` [PATCH 5/6] irqchip/irq-pruss-intc: Add API to trigger a PRU sysevent Suman Anna 2019-07-08 3:52 ` Suman Anna 2019-07-08 3:52 ` Suman Anna 2019-07-11 20:40 ` David Lechner 2019-07-11 20:40 ` David Lechner 2019-07-08 3:52 ` [PATCH 6/6] irqchip/irq-pruss-intc: Add support for ICSSG INTC on K3 SoCs Suman Anna 2019-07-08 3:52 ` Suman Anna 2019-07-08 3:52 ` Suman Anna
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=22825f06-d968-03a7-585b-8cbf4123915c@lechnology.com \ --to=david@lechnology.com \ --cc=afd@ti.com \ --cc=devicetree@vger.kernel.org \ --cc=grygorii.strashko@ti.com \ --cc=jason@lakedaemon.net \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=lokeshvutla@ti.com \ --cc=m-karicheri2@ti.com \ --cc=marc.zyngier@arm.com \ --cc=nsekhar@ti.com \ --cc=robh+dt@kernel.org \ --cc=rogerq@ti.com \ --cc=s-anna@ti.com \ --cc=tglx@linutronix.de \ --cc=tony@atomide.com \ /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.