Re: [PATCH 2.6-git] SPI core refresh

[David Brownell <david-b@pacbell.net>]

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/