linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@xilinx.com>
To: Marc Zyngier <maz@kernel.org>,
	Mubin Usman Sayyed <mubin.usman.sayyed@xilinx.com>
Cc: tglx@linutronix.de, jason@lakedaemon.net,
	michal.simek@xilinx.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, siva.durga.paladugu@xilinx.com,
	anirudha.sarangi@xilinx.com
Subject: Re: [PATCH v2] irqchip: xilinx: Add support for multiple instances
Date: Thu, 6 Feb 2020 08:06:11 +0100	[thread overview]
Message-ID: <3d6077c1-2b13-acc6-e8f4-3d1ab23dc159@xilinx.com> (raw)
In-Reply-To: <b8e7b9120bc6cd306bda3347cde117ff@kernel.org>

On 05. 02. 20 17:53, Marc Zyngier wrote:
> On 2020-02-05 14:05, Mubin Usman Sayyed wrote:
>> From: Mubin Sayyed <mubin.usman.sayyed@xilinx.com>
>>
>> This patch adds support for multiple instances of
>> xilinx interrupt controller. Below configurations are
>> supported by driver,
>>
>> - peripheral->xilinx-intc->xilinx-intc->gic
>> - peripheral->xilinx-intc->xilinx-intc
>>
>> Signed-off-by: Anirudha Sarangi <anirudha.sarangi@xilinx.com>
>> Signed-off-by: Mubin Sayyed <mubin.usman.sayyed@xilinx.com>
>> ---
>> Changes for v2:
>>         - Removed write_fn/read_fn hooks, used xintc_write/
>>           xintc_read directly
>>         - Moved primary_intc declaration after xintc_irq_chip
>> ---
>>  drivers/irqchip/irq-xilinx-intc.c | 121
>> +++++++++++++++++++++++---------------
>>  1 file changed, 73 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-xilinx-intc.c
>> b/drivers/irqchip/irq-xilinx-intc.c
>> index e3043de..14cb630 100644
>> --- a/drivers/irqchip/irq-xilinx-intc.c
>> +++ b/drivers/irqchip/irq-xilinx-intc.c
>> @@ -38,29 +38,32 @@ struct xintc_irq_chip {
>>         void            __iomem *base;
>>         struct          irq_domain *root_domain;
>>         u32             intr_mask;
>> +       struct                  irq_chip *intc_dev;
>> +       u32                             nr_irq;
>>  };
>>
>> -static struct xintc_irq_chip *xintc_irqc;
>> +static struct xintc_irq_chip *primary_intc;
>>
>> -static void xintc_write(int reg, u32 data)
>> +static void xintc_write(void __iomem *addr, u32 data)
>>  {
>>         if (static_branch_unlikely(&xintc_is_be))
>> -               iowrite32be(data, xintc_irqc->base + reg);
>> +               iowrite32be(data, addr);
>>         else
>> -               iowrite32(data, xintc_irqc->base + reg);
>> +               iowrite32(data, addr);
>>  }
>>
>> -static unsigned int xintc_read(int reg)
>> +static unsigned int xintc_read(void __iomem *addr)
> 
> Since you are changing this, please change the return value to reflect
> the size of what you're returning (u32 instead of unsigned int).
> 
>>  {
>>         if (static_branch_unlikely(&xintc_is_be))
>> -               return ioread32be(xintc_irqc->base + reg);
>> +               return ioread32be(addr);
>>         else
>> -               return ioread32(xintc_irqc->base + reg);
>> +               return ioread32(addr);
>>  }
>>
>>  static void intc_enable_or_unmask(struct irq_data *d)
>>  {
>>         unsigned long mask = 1 << d->hwirq;
>> +       struct xintc_irq_chip *local_intc =
>> irq_data_get_irq_chip_data(d);
>>
>>         pr_debug("irq-xilinx: enable_or_unmask: %ld\n", d->hwirq);
>>
>> @@ -69,47 +72,57 @@ static void intc_enable_or_unmask(struct irq_data *d)
>>          * acks the irq before calling the interrupt handler
>>          */
>>         if (irqd_is_level_type(d))
>> -               xintc_write(IAR, mask);
>> +               xintc_write(local_intc->base + IAR, mask);
>>
>> -       xintc_write(SIE, mask);
>> +       xintc_write(local_intc->base + SIE, mask);
>>  }
>>
>>  static void intc_disable_or_mask(struct irq_data *d)
>>  {
>> +       struct xintc_irq_chip *local_intc =
>> irq_data_get_irq_chip_data(d);
>> +
>>         pr_debug("irq-xilinx: disable: %ld\n", d->hwirq);
>> -       xintc_write(CIE, 1 << d->hwirq);
>> +       xintc_write(local_intc->base + CIE, 1 << d->hwirq);
>>  }
>>
>>  static void intc_ack(struct irq_data *d)
>>  {
>> +       struct xintc_irq_chip *local_intc =
>> irq_data_get_irq_chip_data(d);
>> +
>>         pr_debug("irq-xilinx: ack: %ld\n", d->hwirq);
>> -       xintc_write(IAR, 1 << d->hwirq);
>> +       xintc_write(local_intc->base + IAR, 1 << d->hwirq);
>>  }
>>
>>  static void intc_mask_ack(struct irq_data *d)
>>  {
>>         unsigned long mask = 1 << d->hwirq;
>> +       struct xintc_irq_chip *local_intc =
>> irq_data_get_irq_chip_data(d);
>>
>>         pr_debug("irq-xilinx: disable_and_ack: %ld\n", d->hwirq);
>> -       xintc_write(CIE, mask);
>> -       xintc_write(IAR, mask);
>> +       xintc_write(local_intc->base + CIE, mask);
>> +       xintc_write(local_intc->base + IAR, mask);
>>  }
>>
>> -static struct irq_chip intc_dev = {
>> -       .name = "Xilinx INTC",
>> -       .irq_unmask = intc_enable_or_unmask,
>> -       .irq_mask = intc_disable_or_mask,
>> -       .irq_ack = intc_ack,
>> -       .irq_mask_ack = intc_mask_ack,
>> -};
>> +static unsigned int xintc_get_irq_local(struct xintc_irq_chip
>> *local_intc)
>> +{
>> +       int hwirq, irq = -1;
> 
> Type consistency for hwirq.
> 
>> +
>> +       hwirq = xintc_read(local_intc->base + IVR);
>> +       if (hwirq != -1U)
>> +               irq = irq_find_mapping(local_intc->root_domain, hwirq);
>> +
>> +       pr_debug("irq-xilinx: hwirq=%d, irq=%d\n", hwirq, irq);
>> +
>> +       return irq;
> 
> That now gives you both -1 and 0 for error values. Please stick with 0.
> 
>> +}
>>
>>  unsigned int xintc_get_irq(void)
>>  {
>> -       unsigned int hwirq, irq = -1;
>> +       int hwirq, irq = -1;
>>
>> -       hwirq = xintc_read(IVR);
>> +       hwirq = xintc_read(primary_intc->base + IVR);
>>         if (hwirq != -1U)
>> -               irq = irq_find_mapping(xintc_irqc->root_domain, hwirq);
>> +               irq = irq_find_mapping(primary_intc->root_domain, hwirq);
>>
>>         pr_debug("irq-xilinx: hwirq=%d, irq=%d\n", hwirq, irq);
> 
> I have the ugly feeling I'm reading the same code twice... Surely you can
> make these two functions common code.

I have some questions regarding this.
I have updated one patchset which is adding support for Microblaze SMP.
And when I was looking at current wiring of this driver I have decided
to change it.

I have enabled  GENERIC_IRQ_MULTI_HANDLER and HANDLE_DOMAIN_IRQ.
This driver calls set_handle_irq(xil_intc_handle_irq)
and MB do_IRQ() call handle_arch_irq()
and IRQ routine here is using handle_domain_irq().

I would expect that this chained IRQ handler can also use
handle_domain_irq().

Is that correct understanding?



>>
>> @@ -118,15 +131,18 @@ unsigned int xintc_get_irq(void)
>>
>>  static int xintc_map(struct irq_domain *d, unsigned int irq,
>> irq_hw_number_t hw)
>>  {
>> -       if (xintc_irqc->intr_mask & (1 << hw)) {
>> -               irq_set_chip_and_handler_name(irq, &intc_dev,
>> +       struct xintc_irq_chip *local_intc = d->host_data;
>> +
>> +       if (local_intc->intr_mask & (1 << hw)) {
> 
> BIT(hw)
> 
>> +               irq_set_chip_and_handler_name(irq, local_intc->intc_dev,
>>                                                 handle_edge_irq, "edge");
>>                 irq_clear_status_flags(irq, IRQ_LEVEL);
>>         } else {
>> -               irq_set_chip_and_handler_name(irq, &intc_dev,
>> +               irq_set_chip_and_handler_name(irq, local_intc->intc_dev,
>>                                                 handle_level_irq,
>> "level");
>>                 irq_set_status_flags(irq, IRQ_LEVEL);
>>         }
>> +       irq_set_chip_data(irq, local_intc);
>>         return 0;
>>  }
>>
>> @@ -138,11 +154,13 @@ static const struct irq_domain_ops
>> xintc_irq_domain_ops = {
>>  static void xil_intc_irq_handler(struct irq_desc *desc)
>>  {
>>         struct irq_chip *chip = irq_desc_get_chip(desc);
>> +       struct xintc_irq_chip *local_intc =
>> +               irq_data_get_irq_handler_data(&desc->irq_data);
>>         u32 pending;
>>
>>         chained_irq_enter(chip, desc);
>>         do {
>> -               pending = xintc_get_irq();
>> +               pending = xintc_get_irq_local(local_intc);
>>                 if (pending == -1U)
>>                         break;
>>                 generic_handle_irq(pending);
>> @@ -153,28 +171,20 @@ static void xil_intc_irq_handler(struct irq_desc
>> *desc)
>>  static int __init xilinx_intc_of_init(struct device_node *intc,
>>                                              struct device_node *parent)
>>  {
>> -       u32 nr_irq;
>>         int ret, irq;
>>         struct xintc_irq_chip *irqc;
>> -
>> -       if (xintc_irqc) {
>> -               pr_err("irq-xilinx: Multiple instances aren't
>> supported\n");
>> -               return -EINVAL;
>> -       }
>> +       struct irq_chip *intc_dev;
>>
>>         irqc = kzalloc(sizeof(*irqc), GFP_KERNEL);
>>         if (!irqc)
>>                 return -ENOMEM;
>> -
>> -       xintc_irqc = irqc;
>> -
>>         irqc->base = of_iomap(intc, 0);
>>         BUG_ON(!irqc->base);
>>
>> -       ret = of_property_read_u32(intc, "xlnx,num-intr-inputs",
>> &nr_irq);
>> +       ret = of_property_read_u32(intc, "xlnx,num-intr-inputs",
>> &irqc->nr_irq);
>>         if (ret < 0) {
>>                 pr_err("irq-xilinx: unable to read
>> xlnx,num-intr-inputs\n");
>> -               goto err_alloc;
>> +               goto error;
>>         }
>>
>>         ret = of_property_read_u32(intc, "xlnx,kind-of-intr",
>> &irqc->intr_mask);
>> @@ -183,30 +193,42 @@ static int __init xilinx_intc_of_init(struct
>> device_node *intc,
>>                 irqc->intr_mask = 0;
>>         }
>>
>> -       if (irqc->intr_mask >> nr_irq)
>> +       if (irqc->intr_mask >> irqc->nr_irq)
>>                 pr_warn("irq-xilinx: mismatch in kind-of-intr param\n");
>>
>>         pr_info("irq-xilinx: %pOF: num_irq=%d, edge=0x%x\n",
>> -               intc, nr_irq, irqc->intr_mask);
>> +               intc, irqc->nr_irq, irqc->intr_mask);
>> +
>> +       intc_dev = kzalloc(sizeof(*intc_dev), GFP_KERNEL);
>> +       if (!intc_dev) {
>> +               ret = -ENOMEM;
>> +               goto error;
>> +       }
>>
>> +       intc_dev->name = intc->full_name;
> 
> No. The world doesn't need to see the OF path of your interrupt
> controller in /proc/cpuinfo.
> The name that was there before was perfectly descriptive, please stick
> to it.

It should be showing name like interrupt-controller@41800000.
Do you think that we really should stick with just fixed name?
There could be multiple instances in the system and you will have no
idea how they are connected.

Thanks,
Michal

  reply	other threads:[~2020-02-06  7:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-05 14:05 [PATCH v2] irqchip: xilinx: Add support for multiple instances Mubin Usman Sayyed
2020-02-05 14:15 ` David Laight
2020-02-05 14:54   ` Michal Simek
2020-02-06  8:07     ` Mubin Usman Sayyed
2020-02-05 14:53 ` Michal Simek
2020-02-06  8:02   ` Mubin Usman Sayyed
2020-02-05 16:53 ` Marc Zyngier
2020-02-06  7:06   ` Michal Simek [this message]
2020-02-06  9:09     ` Marc Zyngier
2020-02-06  9:11       ` Michal Simek
2020-02-06  9:15         ` Marc Zyngier
2020-02-06  9:17           ` Michal Simek
2020-02-11 19:38   ` Mubin Usman Sayyed

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=3d6077c1-2b13-acc6-e8f4-3d1ab23dc159@xilinx.com \
    --to=michal.simek@xilinx.com \
    --cc=anirudha.sarangi@xilinx.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=mubin.usman.sayyed@xilinx.com \
    --cc=siva.durga.paladugu@xilinx.com \
    --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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).