[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1300964887.2735.84.camel@localhost>
Date: Thu, 24 Mar 2011 13:08:07 +0200
From: Artem Bityutskiy <dedekind1@...il.com>
To: Russell King - ARM Linux <linux@....linux.org.uk>
Cc: Nicolas Ferre <nicolas.ferre@...el.com>,
"'linux-arm-kernel@...ts.infradead.org'"
<linux-arm-kernel@...ts.infradead.org>,
Linux Kernel list <linux-kernel@...r.kernel.org>,
Patrice VILCHEZ <patrice.vilchez@...el.com>,
Hong XU <hong.xu@...el.com>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
Andrew Victor <linux@...im.org.za>,
linux-mtd <linux-mtd@...ts.infradead.org>
Subject: Re: Hit BUG_ON in dma-mapping.c:425 (RFC)
On Thu, 2011-03-24 at 09:27 +0000, Russell King - ARM Linux wrote:
> The only real answer I can give is: if you want to deal with DMA, you
> absolutely must conform to the restrictions on DMA which means that you
> can't pass vmalloc addresses to the DMA API.
I see, thanks. Well, I do not see any issues with changing MTD-related
SW (JFFS2, UBI, UBIFS, etc) to use kmalloc. But this would require som
non-trivial efforts, although I believe this is doable.
Basically, we have to work with entire eraseblocks often, which may be
128KiB or 256KiB or even 512KiB nowadays. And we vmalloc the
eraseblock-sized buffers in these cases.
We could instead work with arrays of pages (or multiple pages), and then
do things like readv/writev. But this requires a brave knight who'd come
and just implemented this, or a company who'd fund someone to work on
this.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
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/
Powered by blists - more mailing lists