linux-kernel - Re: [PATCH 0/4 v6] i.MX31: dmaengine and framebuffer 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, 6 Jan 2009 10:51:37 +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>,
	Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH 0/4 v6] i.MX31: dmaengine and framebuffer drivers

Hi Sascha

On Tue, 6 Jan 2009, Sascha Hauer wrote:

> Hi Guennadi,
> 
> On Fri, Dec 26, 2008 at 06:11:13PM +0100, Guennadi Liakhovetski wrote:
> > Hi,
> > 
> > This is version 6 of dmaengine and framebuffer drivers for i.MX31.
> > 
> > Changes since version 5: as requested by Sascha Hauer switched to dynamic 
> > IPU IRQ mapping.
> 
> I tried to express that it's really odd that you demux your _internal_
> interrupts as chained handlers.

Your last comment was:

> Preferably a way which does not involve introducing 100+ unused
> interrupts.

which I have done. Now we're back to demux / not demux...

> Consider a network driver which has a
> rx, tx and an error status bit, all of them can trigger an interrupt. A
> you aware of a single driver that uses chained interrupts for this
> case?
> No, they don't have to, because all this happens inside one driver
> and this can easily be dispatched in one interrupt handler. IMHO chained
> interrupts only make sense when you have an interrupt source which
> leaves your driver code and you don't know who might be interested in,
> like the assorted non channel interrupts the IPU also provides.
> 
> I bet you'd never have the idea for such a code design without the
> Freescale code as a sample.

Think about other IPU interrupts. For now I removed the CSI interrupt, but 
it may well be needed at some point. Or any of overflow interrupts? What 
do we do then? Why shall we build in limitations from the beginning, when 
there is an implementation already there, which doesn't have them? Sorry, 
do not understand.

I know you proposed to dispatch all DMA EOF interrupts to one IRQ number 
and (optionally / as required) others to single IRQs. But I like to see 
single DMA sources as separate entries in /proc/interrupts, even if only 
for debugging.

And no, it is not thanks to Freescals code, that I'm doing that, it's more 
contrary to their code - they do not implement an irq_chip API and instead 
add an API of their own.

> Note that arch/arm/plat-mxc/include/mach/mx31.h does not apply anymore
> due to upstream changes.

If we agree on the rest, I'll submit a v7 - updating mx31.h to its current 
state and fixing Kconfig / NR_IRQS.

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/