On Tue, 2008-02-05 at 13:28 +0100, Haavard Skinnemoen wrote: > No need to add an extra layer of indirection and externals all over > the place. Just let the board code define two functions, > spi_cs_activate() and spi_cs_deactivate, and use them to do any > board-specific magic with the chipselects. > > Not all drivers may need those extra functions however. If that's the > case, the board code may just leave them out (assuming they know what > the driver needs) or rely on the linker to strip them out (assuming > --gc-sections is being used.) > > Also introduce a new function, spi_setup(), which must be called to > initialize communications parameters for a given slave. This function > will also check if the given chipselect id is valid. The driver may > call spi_cs_is_valid(), which is defined by the board code if > necessary, to verify that a given chipselect id is valid on the > current board. > > Changed in v2: > - Convert the mpc8xxx_spi driver and the mpc8349emds board to the > new API. > > Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> > --- > I haven't tested if the boards affected by this patch still work, or > even build, so use with care. I'd very much like some feedback on > whether this API change is a good thing or not though.
This is a really good change as it fixes a relocation bug. The chipsel func. ptr isn't relocated by current u-boot so it still points to FLASH after u-boot has been relocated to RAM. Jocke ------------------------------------------------------------------------- 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/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
