Re: [spi-devel-general] SPI

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

On Monday 21 November 2005 1:29 am, Komal Shah wrote:
> --- dmitry pervushin <dpe...@gm...> 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 :)

Hmm, I didn't see this message until just now when I found it in the
archives at

  http://sourceforge.net/mailarchive/forum.php?thread_id=8945243&forum_id=45866

I'll comment that you've significantly mischaracterized the work I've
done in your "list of main differences" in several respects, but I've
not yet read the whole thing.

Also, that won't work on current GIT trees because it's not caught
up to the "remove third argument to device_driver.suspend()" patch,
which Russell King did as followup to the previous version of my
patch.  (URL for current version of my patch is below, which IS
caught up to that and other 2.6.14+ changes.)


> I see no discussion on the kernel/spi-devel list on this patch. I am
> working on TI OMAP2420 (linux-omap-open-source), I want to use this
> latest spi framework for omap24xx spi driver implementation.

I'd suggest instead using the light weight framework I sent before:

  http://marc.theaimsgroup.com/?l=linux-kernel&m=113169588230519&w=2

That's got a bunch of drivers working in it right now, including an
ads7846 (touchscreen/sensor) driver that runs on both OMAP and PXA
controller drivers.  Reusable drivers ... what a concept!  :)


> SPI already works on 24xx using custom hack for audio and touchscreen
> but it can not be submitted to linux-omap tree, as it is not following
> proper driver model.

That's one of the reasons I started on the SPI stuff ... the current
MicroWire hookup (for TSC210x audio/touchscreen and ADS7846 touchscreen)
sort of sucks from the driver model perspective.  But then, so did the
first half dozen SPI "framework" patches I saw posted on LKML, so I
though it might help if I fixed that not-so-little issue.  :)

I've tried to take the best of the frameworks I've seen, subject to the
basic constraints that

(a) SPI shouldn't perpetuate the driver model botches of I2C;
(b) ditto I2C's "everything is synchronous" botches;
(c) it should work well with DMA, to support things like DataFlash;
(d) given the variety of SPI chips, protocol controls are needed;
(e) place minimal implementation constraints on controller drivers.

I think I basically succeeded in that.  The most recent iterations of
Dmitry's framework that I've seen fell short IMO on all except (b),
though I don't know about his newest patch (URL above).


> If you guys give me the latest update on this framework and it's
> possiblity of getting accepted in linux-kernel mailing list?
> _otherwise_ I can take this framework write a driver for 24xx and
> submit to linux-omap-open-source mailing list, so that it can get omap
> specific audience + more testing.

Anything can be accepted onto LKML ... it's an open list!  The issue
is more whether some API starts to become official, by merging into
first the MM tree and then the mainstream kernel.  That matters because
the point of a framework is code re-use, and that won't happen if there
are multiple frameworks.

My own plan was to ask if Andrew would let my patch cook in the MM tree
for a while, after Stephen posted his pxa2xx_spi update.  (I consider a
decent basic patchset would be the core, pxa2xx_spi, ads7846, and maybe
the DataFlash driver even though that's just ported not tested.  I could
submit the platform support for Lubbock, which is one of the defacto
reference platforms for PXA 25x chips ... a holdup has been the fact
that some of the post-2.6.14 ARM MMU rework broke booting there, fixes
are on the way after much headscratching.)  I know there are other folk
already working on that same framework, who want a quasi-official blessing.

But I agree that this issue is worth trying to close.  I'd be interested
in any comments from Andrew or Greg, but probably LKML is the best place
to have technical discussions related to "which framework".

- Dave