[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1164297574.2829.9.camel@mulgrave.il.steeleye.com>
Date: Thu, 23 Nov 2006 09:59:33 -0600
From: James Bottomley <James.Bottomley@...elEye.com>
To: Ralf Baechle <ralf@...ux-mips.org>
Cc: Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
linux-scsi@...r.kernel.org
Subject: Re: [PATCH] Kill dma_is_consistent()
On Thu, 2006-11-23 at 15:03 +0000, Ralf Baechle wrote:
> dma_is_consistent() is ill-designed in that it does not have a struct device
> argument which makes proper support for systems that consist of a mix of
> coherent and non-coherent DMA devices hard.
At the time the interface was designed, the general consensus was that
it was easier to recognise incoherent memory regions by their address
range than by which device they came from. The main proponent of this
being arm, if I remember rightly.
> There also is just a single
> user, a BUG_ON() call in the 53c700.c SCSI driver so removing instead of
> fixing it up seems to be the thing to do.
Really, no, this is a bad idea. However, if you want to make it per
device as well as per dma_addr_t, please feel free ... the patch will be
marginally smaller than the one you just submitted ...
> - /* all of these offsets are L1_CACHE_BYTES separated. It is fatal
> - * if this isn't sufficient separation to avoid dma flushing issues */
> - BUG_ON(!dma_is_consistent(pScript) && L1_CACHE_BYTES < dma_get_cache_alignment());
Really, this is a good BUG_ON; it detects a condition that would cause
incredibly subtle and extremely hard to diagnose data corruption
problems in the driver caused by mixed cacheline incoherency. It's the
price I paid in the driver for having my data separations for the
mailboxes determined at compile time rather than runtime. If you want
to take this out, we need to use dma_get_cache_alignment() to determine
the mailbox separations and set them up accordingly at runtime.
James
-
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