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

[Mark U. <bas...@ya...>]

--- Vitaly Wool <vw...@ru...> wrote:

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

So can David's core if you don't use the BIOS table feature. This is how I'm doing my development
on a PC.

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



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com