linux-kernel - Re: [PATCH 2/4 v4] i.MX31: Image Processing Unit DMA and IRQ drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Dec 2008 17:33:11 +0100 (CET)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	Sascha Hauer <s.hauer@...gutronix.de>
cc:	linux-kernel@...r.kernel.org,
	linux-fbdev-devel@...ts.sourceforge.net, adaplas@...il.com,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	Dan Williams <dan.j.williams@...el.com>
Subject: Re: [PATCH 2/4 v4] i.MX31: Image Processing Unit DMA and IRQ drivers

On Tue, 23 Dec 2008, Sascha Hauer wrote:

> You're still not getting it. Consider an implementation of the chained
> interrupt handler like this:
> 
> static struct ipu_irq_bank irq_bank_fn[IPU_IRQ_NR_FN_BANKS] = {
>         {
>                 .nr_irqs        = 1,	/* IDMAC EOF and NF irq */
>         }, {
>                 .nr_irqs        = 24,	/* misc interrupts the IPU is not
> 					 * interested in, but clients drivers
> 					 * may be.
> 					 */
>         },
> };
> 
> static struct ipu_irq_bank irq_bank_err[IPU_IRQ_NR_ERR_BANKS] = {
>         /* 2 groups of error interrupts */
>         {
>                 .nr_irqs        = 1,	/* IDMAC channel error irq */
>         }, {
>                 .nr_irqs        = 17,	/* misc interrupts the IPU is not
>                                          * interested in, but clients drivers
>                                          * may be.
>                                          */
>         },
> };
> 
> /* Chained IRQ handler for IPU error interrupt */
> static void ipu_irq_err(unsigned int irq, struct irq_desc *desc)
> {
>         struct ipu *ipu = get_irq_data(irq);
>         u32 status;
>         int i, line;
> 
> 	/* These interrupts are handled exclusively by the IPU code */
> 	if (ipu_read_reg(ipu, IPU_INT_STAT_4))
> 		generic_handle_irq(IPU_IRQ);
> 
> 	status = ipu_read_reg(ipu, IPU_INT_STAT_5);
>         while ((line = ffs(status))) {
>                 status &= ~(1UL << (line - 1));
>                 generic_handle_irq(irq_bank_err[i].irq_base + line - 1);
>         }
> }
> 
> /* Chained IRQ handler for IPU function interrupt */
> static void ipu_irq_fn(unsigned int irq, struct irq_desc *desc)
> {
>         struct ipu *ipu = get_irq_data(irq);
>         u32 status;
>         int i, line;
> 
>         /* These interrupts are handled exclusively by the IPU code */
>         if (ipu_read_reg(ipu, IPU_INT_STAT_1) || ipu_read_reg(ipu, IPU_INT_STAT_2))
>                 generic_handle_irq(IPU_ERR_IRQ);
> 
>         status = ipu_read_reg(ipu, IPU_INT_STAT_3);
>         while ((line = ffs(status))) {
>                 status &= ~(1UL << (line - 1));
>                 generic_handle_irq(irq_bank_err[i].irq_base + line - 1);
>         }
> }
> 
> 
> and in ipu_idmac.c:
> 
> request_irq(IPU_ERR_IRQ, &ipu_err_handler);
> request_irq(IPU_IRQ, &ipu_irq);

These all are just slightly different variations - with this one you'd 
have to scan dma channels in your dma irq handler, which I currently don't 
have to do.

> That said I'm not sure whether we need a chained interrupt handler at all.
> Looking at the remaining interrupts it seems that for example the
> CSI_EOF (IPU_INT_STAT3 bit 5) interrupt is redundant to the corresponding
> channels interrupt. In the camera driver you already realized that it's
> the dma end event you're interested in, not the CSI_EOF event. Not sure
> if that holds for the other interrupts though.

I think the version with a lookup table is optimal - it uses standard 
mechanisms for irq handling and doesn't waste RAM. The disadvantage - 
every addition will need driver modification...

But ok, this is taking way too long. Just tell me which way you'd like to 
have it and I'll do it.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/