From: Marc Zyngier <maz@kernel.org> To: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Cc: tglx@linutronix.de, jason@lakedaemon.net, s-anna@ti.com, robh+dt@kernel.org, lee.jones@linaro.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, david@lechnology.com, wmills@ti.com Subject: Re: [PATCHv3 4/6] irqchip/irq-pruss-intc: Implement irq_{get,set}_irqchip_state ops Date: Thu, 02 Jul 2020 18:54:26 +0100 [thread overview] Message-ID: <658e3a8d3374eca91387932a9a246add@kernel.org> (raw) In-Reply-To: <1593699479-1445-5-git-send-email-grzegorz.jaszczyk@linaro.org> On 2020-07-02 15:17, Grzegorz Jaszczyk wrote: > From: David Lechner <david@lechnology.com> > > This implements the irq_get_irqchip_state and irq_set_irqchip_state > callbacks for the TI PRUSS INTC driver. The set callback can be used > by drivers to "kick" a PRU by enabling a PRU system event. "enabling"? That'd be unmasking an interrupt, which isn't what this does. "injecting", maybe? > > Example: > irq_set_irqchip_state(irq, IRQCHIP_STATE_PENDING, true); Nice example. What this example does explain is how you are actually going to kick a PRU via this interface. For that to happen, you'd have to have on the Linux side an interrupt that is actually routed to a PRU. And from what I have understood of the previous patches, this can't be the case. What didi I miss? > > Signed-off-by: David Lechner <david@lechnology.com> > Signed-off-by: Suman Anna <s-anna@ti.com> > Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> > Reviewed-by: Lee Jones <lee.jones@linaro.org> > --- > v2->v3: > - Get rid of unnecessary pruss_intc_check_write() and use > pruss_intc_write_reg directly. > v1->v2: > - https://patchwork.kernel.org/patch/11069769/ > --- > drivers/irqchip/irq-pruss-intc.c | 43 > ++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 41 insertions(+), 2 deletions(-) > > diff --git a/drivers/irqchip/irq-pruss-intc.c > b/drivers/irqchip/irq-pruss-intc.c > index 49c936f..19b3d38 100644 > --- a/drivers/irqchip/irq-pruss-intc.c > +++ b/drivers/irqchip/irq-pruss-intc.c > @@ -7,6 +7,7 @@ > * Suman Anna <s-anna@ti.com> > */ > > +#include <linux/interrupt.h> > #include <linux/irq.h> > #include <linux/irqchip/chained_irq.h> > #include <linux/irqdomain.h> > @@ -39,8 +40,7 @@ > #define PRU_INTC_HIEISR 0x0034 > #define PRU_INTC_HIDISR 0x0038 > #define PRU_INTC_GPIR 0x0080 > -#define PRU_INTC_SRSR0 0x0200 > -#define PRU_INTC_SRSR1 0x0204 > +#define PRU_INTC_SRSR(x) (0x0200 + (x) * 4) > #define PRU_INTC_SECR0 0x0280 > #define PRU_INTC_SECR1 0x0284 > #define PRU_INTC_ESR0 0x0300 > @@ -145,6 +145,43 @@ static void pruss_intc_irq_relres(struct irq_data > *data) > module_put(THIS_MODULE); > } > > +static int pruss_intc_irq_get_irqchip_state(struct irq_data *data, > + enum irqchip_irq_state which, > + bool *state) > +{ > + struct pruss_intc *intc = irq_data_get_irq_chip_data(data); > + u32 reg, mask, srsr; > + > + if (which != IRQCHIP_STATE_PENDING) > + return -EINVAL; > + > + reg = PRU_INTC_SRSR(data->hwirq / 32); I assume the register file scales as more interrupts are added in the subsequent patch? > + mask = BIT(data->hwirq % 32); > + > + srsr = pruss_intc_read_reg(intc, reg); > + > + *state = !!(srsr & mask); > + > + return 0; > +} > + > +static int pruss_intc_irq_set_irqchip_state(struct irq_data *data, > + enum irqchip_irq_state which, > + bool state) > +{ > + struct pruss_intc *intc = irq_data_get_irq_chip_data(data); > + > + if (which != IRQCHIP_STATE_PENDING) > + return -EINVAL; > + > + if (state) > + pruss_intc_write_reg(intc, PRU_INTC_SISR, data->hwirq); > + else > + pruss_intc_write_reg(intc, PRU_INTC_SICR, data->hwirq); > + > + return 0; > +} > + > static struct irq_chip pruss_irqchip = { > .name = "pruss-intc", > .irq_ack = pruss_intc_irq_ack, > @@ -152,6 +189,8 @@ static struct irq_chip pruss_irqchip = { > .irq_unmask = pruss_intc_irq_unmask, > .irq_request_resources = pruss_intc_irq_reqres, > .irq_release_resources = pruss_intc_irq_relres, > + .irq_get_irqchip_state = pruss_intc_irq_get_irqchip_state, > + .irq_set_irqchip_state = pruss_intc_irq_set_irqchip_state, > }; > > static int pruss_intc_irq_domain_map(struct irq_domain *d, unsigned > int virq, Thanks, M. -- Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org> To: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Cc: devicetree@vger.kernel.org, linux-omap@vger.kernel.org, jason@lakedaemon.net, linux-kernel@vger.kernel.org, robh+dt@kernel.org, tglx@linutronix.de, lee.jones@linaro.org, wmills@ti.com, linux-arm-kernel@lists.infradead.org, david@lechnology.com Subject: Re: [PATCHv3 4/6] irqchip/irq-pruss-intc: Implement irq_{get,set}_irqchip_state ops Date: Thu, 02 Jul 2020 18:54:26 +0100 [thread overview] Message-ID: <658e3a8d3374eca91387932a9a246add@kernel.org> (raw) In-Reply-To: <1593699479-1445-5-git-send-email-grzegorz.jaszczyk@linaro.org> On 2020-07-02 15:17, Grzegorz Jaszczyk wrote: > From: David Lechner <david@lechnology.com> > > This implements the irq_get_irqchip_state and irq_set_irqchip_state > callbacks for the TI PRUSS INTC driver. The set callback can be used > by drivers to "kick" a PRU by enabling a PRU system event. "enabling"? That'd be unmasking an interrupt, which isn't what this does. "injecting", maybe? > > Example: > irq_set_irqchip_state(irq, IRQCHIP_STATE_PENDING, true); Nice example. What this example does explain is how you are actually going to kick a PRU via this interface. For that to happen, you'd have to have on the Linux side an interrupt that is actually routed to a PRU. And from what I have understood of the previous patches, this can't be the case. What didi I miss? > > Signed-off-by: David Lechner <david@lechnology.com> > Signed-off-by: Suman Anna <s-anna@ti.com> > Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> > Reviewed-by: Lee Jones <lee.jones@linaro.org> > --- > v2->v3: > - Get rid of unnecessary pruss_intc_check_write() and use > pruss_intc_write_reg directly. > v1->v2: > - https://patchwork.kernel.org/patch/11069769/ > --- > drivers/irqchip/irq-pruss-intc.c | 43 > ++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 41 insertions(+), 2 deletions(-) > > diff --git a/drivers/irqchip/irq-pruss-intc.c > b/drivers/irqchip/irq-pruss-intc.c > index 49c936f..19b3d38 100644 > --- a/drivers/irqchip/irq-pruss-intc.c > +++ b/drivers/irqchip/irq-pruss-intc.c > @@ -7,6 +7,7 @@ > * Suman Anna <s-anna@ti.com> > */ > > +#include <linux/interrupt.h> > #include <linux/irq.h> > #include <linux/irqchip/chained_irq.h> > #include <linux/irqdomain.h> > @@ -39,8 +40,7 @@ > #define PRU_INTC_HIEISR 0x0034 > #define PRU_INTC_HIDISR 0x0038 > #define PRU_INTC_GPIR 0x0080 > -#define PRU_INTC_SRSR0 0x0200 > -#define PRU_INTC_SRSR1 0x0204 > +#define PRU_INTC_SRSR(x) (0x0200 + (x) * 4) > #define PRU_INTC_SECR0 0x0280 > #define PRU_INTC_SECR1 0x0284 > #define PRU_INTC_ESR0 0x0300 > @@ -145,6 +145,43 @@ static void pruss_intc_irq_relres(struct irq_data > *data) > module_put(THIS_MODULE); > } > > +static int pruss_intc_irq_get_irqchip_state(struct irq_data *data, > + enum irqchip_irq_state which, > + bool *state) > +{ > + struct pruss_intc *intc = irq_data_get_irq_chip_data(data); > + u32 reg, mask, srsr; > + > + if (which != IRQCHIP_STATE_PENDING) > + return -EINVAL; > + > + reg = PRU_INTC_SRSR(data->hwirq / 32); I assume the register file scales as more interrupts are added in the subsequent patch? > + mask = BIT(data->hwirq % 32); > + > + srsr = pruss_intc_read_reg(intc, reg); > + > + *state = !!(srsr & mask); > + > + return 0; > +} > + > +static int pruss_intc_irq_set_irqchip_state(struct irq_data *data, > + enum irqchip_irq_state which, > + bool state) > +{ > + struct pruss_intc *intc = irq_data_get_irq_chip_data(data); > + > + if (which != IRQCHIP_STATE_PENDING) > + return -EINVAL; > + > + if (state) > + pruss_intc_write_reg(intc, PRU_INTC_SISR, data->hwirq); > + else > + pruss_intc_write_reg(intc, PRU_INTC_SICR, data->hwirq); > + > + return 0; > +} > + > static struct irq_chip pruss_irqchip = { > .name = "pruss-intc", > .irq_ack = pruss_intc_irq_ack, > @@ -152,6 +189,8 @@ static struct irq_chip pruss_irqchip = { > .irq_unmask = pruss_intc_irq_unmask, > .irq_request_resources = pruss_intc_irq_reqres, > .irq_release_resources = pruss_intc_irq_relres, > + .irq_get_irqchip_state = pruss_intc_irq_get_irqchip_state, > + .irq_set_irqchip_state = pruss_intc_irq_set_irqchip_state, > }; > > static int pruss_intc_irq_domain_map(struct irq_domain *d, unsigned > int virq, Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ 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:[~2020-07-02 17:54 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-02 14:17 [PATCHv3 0/6] Add TI PRUSS Local Interrupt Controller IRQChip driver Grzegorz Jaszczyk 2020-07-02 14:17 ` Grzegorz Jaszczyk 2020-07-02 14:17 ` [PATCHv3 1/6] dt-bindings: irqchip: Add PRU-ICSS interrupt controller bindings Grzegorz Jaszczyk 2020-07-02 14:17 ` Grzegorz Jaszczyk 2020-07-13 21:25 ` Rob Herring 2020-07-13 21:25 ` Rob Herring 2020-07-16 9:25 ` Grzegorz Jaszczyk 2020-07-16 9:25 ` Grzegorz Jaszczyk 2020-07-02 14:17 ` [PATCHv3 2/6] irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS interrupts Grzegorz Jaszczyk 2020-07-02 14:17 ` Grzegorz Jaszczyk 2020-07-02 17:24 ` Marc Zyngier 2020-07-02 17:24 ` Marc Zyngier 2020-07-03 14:28 ` Grzegorz Jaszczyk 2020-07-03 14:28 ` Grzegorz Jaszczyk 2020-07-04 9:39 ` Marc Zyngier 2020-07-04 9:39 ` Marc Zyngier 2020-07-05 13:26 ` Grzegorz Jaszczyk 2020-07-05 13:26 ` Grzegorz Jaszczyk 2020-07-05 20:45 ` Marc Zyngier 2020-07-05 20:45 ` Marc Zyngier 2020-07-08 7:04 ` Grzegorz Jaszczyk 2020-07-08 7:04 ` Grzegorz Jaszczyk 2020-07-08 10:47 ` Marc Zyngier 2020-07-08 10:47 ` Marc Zyngier 2020-07-10 23:03 ` Suman Anna 2020-07-10 23:03 ` Suman Anna 2020-07-15 13:38 ` Grzegorz Jaszczyk 2020-07-15 13:38 ` Grzegorz Jaszczyk 2020-07-17 12:36 ` Marc Zyngier 2020-07-17 12:36 ` Marc Zyngier 2020-07-21 9:27 ` Grzegorz Jaszczyk 2020-07-21 9:27 ` Grzegorz Jaszczyk 2020-07-21 10:10 ` Marc Zyngier 2020-07-21 10:10 ` Marc Zyngier 2020-07-21 13:59 ` Grzegorz Jaszczyk 2020-07-21 13:59 ` Grzegorz Jaszczyk 2020-07-02 14:17 ` [PATCHv3 3/6] irqchip/irq-pruss-intc: Add support for shared and invalid interrupts Grzegorz Jaszczyk 2020-07-02 14:17 ` Grzegorz Jaszczyk 2020-07-02 17:44 ` Marc Zyngier 2020-07-02 17:44 ` Marc Zyngier 2020-07-10 20:59 ` Suman Anna 2020-07-10 20:59 ` Suman Anna 2020-07-17 11:02 ` Marc Zyngier 2020-07-17 11:02 ` Marc Zyngier 2020-07-25 15:57 ` Suman Anna 2020-07-25 15:57 ` Suman Anna 2020-07-25 16:27 ` Marc Zyngier 2020-07-25 16:27 ` Marc Zyngier 2020-07-25 16:39 ` Suman Anna 2020-07-25 16:39 ` Suman Anna 2020-07-02 14:17 ` [PATCHv3 4/6] irqchip/irq-pruss-intc: Implement irq_{get,set}_irqchip_state ops Grzegorz Jaszczyk 2020-07-02 14:17 ` [PATCHv3 4/6] irqchip/irq-pruss-intc: Implement irq_{get, set}_irqchip_state ops Grzegorz Jaszczyk 2020-07-02 17:54 ` Marc Zyngier [this message] 2020-07-02 17:54 ` [PATCHv3 4/6] irqchip/irq-pruss-intc: Implement irq_{get,set}_irqchip_state ops Marc Zyngier 2020-07-03 17:04 ` Grzegorz Jaszczyk 2020-07-03 17:04 ` Grzegorz Jaszczyk 2020-07-10 21:04 ` Suman Anna 2020-07-10 21:04 ` Suman Anna 2020-07-02 14:17 ` [PATCHv3 5/6] irqchip/irq-pruss-intc: Add support for ICSSG INTC on K3 SoCs Grzegorz Jaszczyk 2020-07-02 14:17 ` Grzegorz Jaszczyk 2020-07-02 17:59 ` Marc Zyngier 2020-07-02 17:59 ` Marc Zyngier 2020-07-03 17:05 ` Grzegorz Jaszczyk 2020-07-03 17:05 ` Grzegorz Jaszczyk 2020-07-10 21:13 ` Suman Anna 2020-07-10 21:13 ` Suman Anna 2020-07-02 14:17 ` [PATCHv3 6/6] irqchip/irq-pruss-intc: Add event mapping support Grzegorz Jaszczyk 2020-07-02 14:17 ` Grzegorz Jaszczyk 2020-07-02 16:24 ` Suman Anna 2020-07-02 16:24 ` Suman Anna 2020-07-05 13:39 ` Grzegorz Jaszczyk 2020-07-05 13:39 ` Grzegorz Jaszczyk
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=658e3a8d3374eca91387932a9a246add@kernel.org \ --to=maz@kernel.org \ --cc=david@lechnology.com \ --cc=devicetree@vger.kernel.org \ --cc=grzegorz.jaszczyk@linaro.org \ --cc=jason@lakedaemon.net \ --cc=lee.jones@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=robh+dt@kernel.org \ --cc=s-anna@ti.com \ --cc=tglx@linutronix.de \ --cc=wmills@ti.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.