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 hskinnemoen@atmel.com
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