I'll comment that you've significantly mischaracterized the work I'veCan you please review both the list and the new core and comment on the recent one?
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 caughtTrue, although it works with 2.6.14 which is probably the most recent kernel needed for anyone else aside :-)
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.)
Well, I can agree that for simple SPI devices David's core might be easier to use.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:
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! :)
Those two are fulfilled in both cores.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;Lemme point once again that David' core is not DMA-ready. More comments on that will follow, lemme get some sleep :)
(d) given the variety of SPI chips, protocol controls are needed;IMHO this one is fulfilled in both.
(e) place minimal implementation constraints on controller drivers.Yeah David's core fulfilling this one well. However, my view on that is it's leaving too much for the controller driver to implement, requiring so much sophistication from it that it partially disapproves the whole concept of having the _core_.
Yeah and I do suggest that we start a true convergence of the cores. I think that it should happen after David thoroughly reviews/comments Dmitry's notes on his core rather than just say in bare words that they're invalid.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.