Re: [spi-devel-general] SPI

Re: [spi-devel-general] SPI

[Vitaly Wool]

Hi,

apart of just struggling whose core is better, I'd like to find 
rationale in both.
I think that we've got to have a final convergence of the cores, so 
let's pass over to constructive dialogue.

>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.
>  
>
Can you please review both the list and the new core and comment on the 
recent one?

>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.)
>
>
>  
>
True, although it works with 2.6.14 which is probably the most recent 
kernel needed for anyone else aside :-)
Will respin shortly anyway.

>>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!  :)
>  
>
Well, I can agree that for simple SPI devices David's core might be 
easier to use.

>>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;
>  
>
Those two are fulfilled in both cores.

>(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_.

>>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.
>  
>
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.

Vitaly