From: Thomas Gleixner <tglx@linutronix.de>
To: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Cc: monstr@monstr.eu, jason@lakedaemon.net, marc.zyngier@arm.com,
linux-kernel@vger.kernel.org, michal.simek@xilinx.com,
linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au
Subject: Re: [Patch V6 2/6] irqchip: xilinx: Clean up irqdomain argument and read/write
Date: Mon, 31 Oct 2016 13:51:59 -0600 (MDT) [thread overview]
Message-ID: <alpine.DEB.2.20.1610311335380.5011@nanos> (raw)
In-Reply-To: <1477916207-25157-3-git-send-email-Zubair.Kakakhel@imgtec.com>
On Mon, 31 Oct 2016, Zubair Lutfullah Kakakhel wrote:
> The drivers read/write function handling is a bit quirky.
Can you please explain in more detail what's quirky and why it should be
done differently,
> And the irqmask is passed directly to the handler.
I can't make any sense out of that sentence. Which handler? If you talk
about the write function, then I don't see a change. So what are you
talking about?
> Add a new irqchip struct to pass to the handler and
> cleanup read/write handling.
I still don't see what it cleans up. You move the write function pointer
into a data structure, which is exposed by another pointer. So you create
two levels of indirection in the hotpath. The function prototype is still
the same. So all this does is making things slower unless I'm missing
something.
> -static unsigned int (*read_fn)(void __iomem *);
> -static void (*write_fn)(u32, void __iomem *);
> +struct xintc_irq_chip {
> + void __iomem *base;
> + struct irq_domain *domain;
> + struct irq_chip chip;
The tabs between struct and the structure name are bogus.
> + u32 intr_mask;
> + unsigned int (*read)(void __iomem *iomem);
> + void (*write)(u32 data, void __iomem *iomem);
Please structure that like a table:
void __iomem *base;
struct irq_domain *domain;
struct irq_chip chip;
u32 intr_mask;
unsigned int (*read)(void __iomem *iomem);
void (*write)(u32 data, void __iomem *iomem);
Can you see how that makes parsing the struct simpler, because the data
types are clearly to identify?
> +static struct xintc_irq_chip *xintc_irqc;
>
> static void intc_write32(u32 val, void __iomem *addr)
> {
> @@ -54,6 +60,18 @@ static unsigned int intc_read32_be(void __iomem *addr)
> return ioread32be(addr);
> }
>
> +static inline unsigned int xintc_read(struct xintc_irq_chip *xintc_irqc,
> + int reg)
> +{
> + return xintc_irqc->read(xintc_irqc->base + reg);
> +}
> +
> +static inline void xintc_write(struct xintc_irq_chip *xintc_irqc,
> + int reg, u32 data)
> +{
> + xintc_irqc->write(data, xintc_irqc->base + reg);
> +}
> +
> static void intc_enable_or_unmask(struct irq_data *d)
> {
> unsigned long mask = 1 << d->hwirq;
> @@ -65,21 +83,21 @@ static void intc_enable_or_unmask(struct irq_data *d)
> * acks the irq before calling the interrupt handler
> */
> if (irqd_is_level_type(d))
> - write_fn(mask, intc_baseaddr + IAR);
> + xintc_write(xintc_irqc, IAR, mask);
So this whole thing makes only sense, when you want to support multiple
instances of that chip and then you need to store the xintc_irqc pointer as
irqchip data and retrieve it from there. Unless you do that, this "cleanup"
is just churn for nothing with the effect of making things less efficient.
Thanks,
tglx
next prev parent reply other threads:[~2016-10-31 19:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-31 12:16 [Patch V6 0/6] microblaze/PowerPC: Move irq-xilinx Zubair Lutfullah Kakakhel
2016-10-31 12:16 ` [Patch V6 1/6] microblaze: irqchip: Move intc driver to irqchip Zubair Lutfullah Kakakhel
2016-10-31 12:16 ` [Patch V6 2/6] irqchip: xilinx: Clean up irqdomain argument and read/write Zubair Lutfullah Kakakhel
2016-10-31 19:51 ` Thomas Gleixner [this message]
2016-11-01 11:05 ` Zubair Lutfullah Kakakhel
2016-11-07 9:53 ` Zubair Lutfullah Kakakhel
2016-11-09 15:53 ` Marc Zyngier
2016-11-15 11:06 ` Michal Simek
2016-10-31 12:16 ` [Patch V6 3/6] irqchip: xilinx: Rename get_irq to xintc_get_irq Zubair Lutfullah Kakakhel
2016-10-31 12:16 ` [Patch V6 4/6] irqchip: xilinx: Add support for parent intc Zubair Lutfullah Kakakhel
2016-10-31 12:16 ` [Patch V6 5/6] irqchip: xilinx: Try to fall back if xlnx,kind-of-intr not provided Zubair Lutfullah Kakakhel
2016-10-31 12:16 ` [Patch V6 6/6] powerpc/virtex: Use generic xilinx irqchip driver Zubair Lutfullah Kakakhel
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=alpine.DEB.2.20.1610311335380.5011@nanos \
--to=tglx@linutronix.de \
--cc=Zubair.Kakakhel@imgtec.com \
--cc=jason@lakedaemon.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=marc.zyngier@arm.com \
--cc=michal.simek@xilinx.com \
--cc=monstr@monstr.eu \
--cc=mpe@ellerman.id.au \
/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
all inboxes | Powered by JetHome®