Sorry I'm just re-joining this conversation. That's the fun of being 9 time zones apart...
On Tue, May 27, 2008 at 2:13 AM, Wolfgang Denk wd@denx.de wrote:
In message 20080527103245.565527ba@hskinnemo-gx745.norway.atmel.com you wrote:
So maybe we should try to get rid of the CONFIG_HARD_SPI define? I
Well, I think I'd rather get rid of CONFIG_MPC8XXX_SPI as this is redundant - it's what you atomatically get when using CONFIG_HARD_SPI on a MPC8XXX system. That would make this more in line with the I2C code. And we can use something like
#if defined(CONFIG_HARD_SPI) || defined (CONFIG_SOFT_SPI)when we need to know if there is any SPI support at all (like we do with I2C).
Ideally, we'd be able to re-claim CONFIG_SPI from whatever perverse use it currently has (IIRC it CONFIG_BOOT_FROM_SPI_EEPROM), but that's pretty invasive. I don't think we want to take out CONFIG_MCP8XXX_SPI, because then somebody needs to keep track of what CPUs have it and maintain the header files appropriately. I can just imagine the mess:
#if (defined MPC834X) || (defined MPC857X) || (defined MPC9766) || \ . . . do your stuff #endif
Automatically generating CONFIG_HARD_SPI from it, though, makes sense, though, although I hate to see architecture-specific stuff go in spi.h. NBD, I guess.
I suspect that if we do want something like that, it will probably be about combining hardware and software SPI (i.e. we want more SPI busses than the chip can provide in hardware.)
Yes, I guess this is going to happen first. Hopefully not soon, though ;-)
Yeah, suggesting that something isn't necessary virtually assures that it will be.
I'll put together a new patch and re-send later today.
regards, Ben