Messages in this thread | | | From | David Brownell <> | Subject | Re: [PATCH 2.6-git] SPI core refresh | Date | Wed, 30 Nov 2005 13:36:38 -0800 |
| |
On Wednesday 30 November 2005 8:50 am, Vitaly Wool wrote:
> However, there also are some advantages of our core compared to David's I'd like to mention
I'd also be interested in your responses to the comparison I wrote up last week. (Post dated 23-November to that spi-devel list...)
> - it can be compiled as a module
Which as I pointed out would be a rather minor patch to mine. There's a bit of code to manage the board-specific SPI tables, which _can't_ be a module. Then there's something less than 2KB of code (ARM .text) that could live in a module. I can't get excited about making that live in a module, but I'd take a patch to change that.
> - it is DMA-safe
Which as I pointed out is incorrect. The core API (async) has always been fully DMA-safe. And a **LOT** lower overhead than yours, which allocates buffers behind the back of drivers, and encourages lots of memcpy rather than just doing DMA directly to/from the buffers that are provided by the SPI protocol drivers.
> - it is priority inversion-free > - it can gain more performance with multiple controllers > - it's more adapted for use in real-time environments
You'd have to explain what you mean by all of these. I could guess based on what you've said before (disagree!), but that won't help.
> - it's not so lightweight, but it leaves less effort for the bus driver developer.
Whereas in my previous comments about your framework, I think I've pointed out that imposing needless and restrictive policies on how the controller drivers work is a Bad Thing.
- Dave
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |