On Wednesday 27 February 2008, Bryan Wu wrote: > On Wed, Feb 27, 2008 at 5:59 PM, David Brownell <[EMAIL PROTECTED]> wrote: > > > > To speak my mind, i feel i am imposed a troublesome messaging scheme > > > > from the SPI framework. Maybe it has to do with buggy controller, > > > > controller driver, buggy chips with erratas longer than the reference > > > > manual. Well, wont rant about that right now. Need to solve this > > problem > > > > instead. > > > > We sort of lack a testing framework for SPI master drivers. The best > > solution for now seems to be to make sure several existing drivers > > work with it ... > > I remember some LTP guys are developing bus driver testing case such > as i2c, spi ,etc, but don't know the detail.
When I did it for USB, I essentially defined a "golden device" that could be the target of such testing. Easy to do with various microcontrollers with I2C; a bit less so with SPI, because you'd also want to test higher data rates than most micros like. > For the testing of Blackfin, we tested SPI touchscreen, SPI > joystick, SPI flash and a SPI MMC driver over SPI framework. Better coverage than many systems. :) > > > > I hope to make the block writing working this > > > > weekend. I need to make it work since we want to use the inexpensive > > > > BF532 chip + SPI ethernet + MMC/SD for storage in a product. > > > > > > > > I´ll commit my result to the drivers/mmc/spi_mmc, even though its > > > > obsolete maybe the mainline driver developers can make use of my > > progress. > > > > > > sounds great ! > > > > The spi-devel list archives have at least one patch providing a > > mutual exclusion mechanism at the bus level. One problem is that > > all such mechanisms evidently need controller driver changes, > > since they involve changing the I/O queue managemnt policy. > > > > So how about move the controller driver queue management stuff to spi-core? > controller driver just send out data and receive data. That can be *part* of the solution, although I'd rather see the controller drivers talking in terms of messages: "get me the next message", with the core knowing how to handle things like this exclusive-access policy. The rest of the solution involves implementation and interface details, including just how to gracefully migrate to that model. The original notion was not to have any kind of mid-layer ... in my experience they're magnets for code bloat. But in this case I'm not sure I see a really good solution other than that. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
