Re: [PATCH] sky2: Fix WARNING: at lib/dma-debug.c:902 check_sync
From: David Miller
Date: Fri Jan 22 2010 - 01:38:44 EST
From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
Date: Fri, 22 Jan 2010 14:11:29 +0900
> Even if 'offset' is zero, 'size' still matters, I think. If 'size' is
> not a multiple of the cache line size, it's possible that driver
> writers who aren't familiar with cache would be surprised (it depends
> on the way their drivers use buffers though).
> The easiest way for 'completely safe sync for any driver writers' is
> asking for all the sync parameters must be the same as those passed
> into the single mapping API. If writes knows what they do, they can do
> a partial sync with sync_range API. That's the author intention, I
This is not reasonable.
You have to think about how people actually use these
They have a large buffer, and if they receive a small request they
want to allocate a smaller buffer, copy into that smaller buffer, and
give the larger buffer back to the hardware.
It's an optimization, it performs better this way.
If you make it so that the DMA sync has to cover the entire large
buffer, the whole point of the optimization is taken away.
That makes no sense at all.
I know that when I designed and wrote the first implementation of the
PCI DMA interfaces, I sure as hell meant to allow partial DMA sync
I know this as a fact, because the first drivers ported over
to these interfaces were network drivers. And I definitely
knew about the copy-break mechanism I describe above and how
networking drivers use such a scheme pretty much across the
The DMA API documentation is wrong, it must be fixed to allow partial
syncs of arbitrary offsets and sizes.
The issue of cache line boundaries and such are the domain of the DMA
API implementation, and has absolutely no business in the definition
of these interfaces. Nor should it be something driver authors have
to be knowledgable about, that would be completely unreasonable.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/