[spi-devel-general] Re: SPI

[David B. <da...@pa...>]

On Friday 11 November 2005 1:32 am, dmitry pervushin wrote:
> This is an updated version of SPI framework from me, Dmitry Pervushin.
> It seems that now it is good time to consolidate our SPI frameworks to
> push it to kernel :)

Agreed.  Apologies by the way, this message was buried in an email
filter.  I looked at your patch, compared it to mine, and summarize:

 - They share the model of a queue of "messages", whih is processed
   asynchronously.  That's a big help.  :)

 - Maybe the biggest difference is in what's in the messages:

     * You have special DMA hooks where I just expect device
       drivers to follow the more usual "hands off" approah;

     * Your messages are single transfers, mine are entire atomic
       protocol sequences (potentially one chained DMA operation).

   Neither core supports as much protocol flexibility as it needs; that
   toolset must grow over time.

 - Mine lets board-specific device tables be declared in the
   relevant arch_setup() thing (board-*.c).  Both frameworks allow
   later board specific code to dynamically declare the devices,
   with binary (Dave's) or parsed-text (Dmitry's) descriptions.

 - Yours has a "struct spi_driver", mine doesn't.  It's probably
   inevitable, though not currently needed.  Likewise mine has
   the struct driver.suspend() and resume() changes, yours doesn't.

 - Mine supports "modalias" driver binding through hotplug, or via
   sysfs for coldplug.  Yours doesn't.  (Simplified recently.)

Those last few seem like easy convergence points.

There's other stuff in yours that I don't much like; I won't
belabor them here, but key issues are:

 - Bundling a particular type of userspace interface ... mostly
   bad because that should be a separate discussion.

 - Imposes needless policies on how controller drivers are written.

 - That spi_transfer() call.  It can't decide whether it's going
   to be synchronous or asynchronous ... error prone, confusing.
   spi_write() and spi_read() always copy memory.

 - that spimsg_* infrastruture looks quite heavyweight.


> We've tested our SPI core as well with bus drivers with wireless LAN
> driver and achieved good performance with relatively small overhead.
> This proves the viability of this framework in real life even in
> real-time environment.

It may work with RT_PREEMPT, but it still encourages needless memcpy()!
GPL'd WLAN code?  Hmmm... ;)

- Dave