Re: [spi-devel-general] Re: SPI

[Vitaly W. <vw...@ru...>]

David Brownell wrote:

>On Tuesday 29 November 2005 10:37 pm, Vitaly Wool wrote:
>  
>
>>Yeah... the other limitation is that if there's more than one SPI 
>>controller onboard, spi_write_then_read will serialize the transfers 
>>    
>>
>
>I hope you're not trying to claim that -- if that really matters -- it'd
>take more than a spare thought to change that so it kmallocs a pointer.
>(You _could_ get smart and kmalloc one only if the pre-allocated one
>was being used...)
>  
>
Yep... it _really_ matters, especially considering possible priority 
invesrion.
Well, getting smart and considering if pre-allocated was being used or 
not leads to callbacks exactly as they are implemented in our core.
Sometimes keeping things simple means just hiding the problems :)

>
>  
>
>>One more limitation of your SPI core: it cannot be compiled as a module. 
>>What are the reasons behind that BTW?
>>    
>>
>
>The spi_board_info stuff has to be called at arch_initcall() time along
>with all the other arch/.../mach-*/board-*.c board-specific init, so those
>parts clearly can't be in a module.  That's not much code though; I think
>it was in a separate file very early, but that got annoying to work with.
>(The pieces probably fit together now though.)
>
>The rest just didn't seem to matter.  I suppose that could be switched
>around so it's modular ... do you think that's important at all?  If so,
>you know the drill:  feel free to submit a patch!
>
>2KB code (on ARM) didn't seem like much static code to worry about; I've
>saved more code than that just by space-tuning some drivers.  ISTR things
>often get bigger when they link as modules.  Anyway, keeping it all in
>one file was a reasonable incentive towards staying small.  :)
>  
>
Yeah the kernel footprint will not significantly change... I was 
thinking of a different situation though.
Suppose you have a precompiled kernel w/o SPI support. Getting SPI to 
work will imply recompilation of the whole kernel which is a) 
inconvenient b) may be impossible due to some reasons, like not having 
the full source tree of this particular kernel version :)
Therefore I consider this a serious drawback, sorry. I2C core, as well 
as MTD core etc. etc. can be configured as a module; our SPI core also can.

Moreover, I've got a strong suspicion that spi_write_then_read may not 
work with DMA in some cases when compiled as a module.

Vitaly