Dear Ben,
in message 1150123895.10177.36.camel@saruman.qstreams.net you wrote:
Going through the U-boot code, I found two quite different SPI implementations, in addition to a spattering of board-specific code: CONFIG_SPI is very EEPROM-specific, while CONFIG_SOFT_SPI is nice and generic, but is of course bit-banged. My application uses hard SPI, but I want to use U-boot as a hardware debug platform so generic is good.
You are right; CONFIG_SPI should probably be renamed into CONFIG_SPI_EEPROM or so.
I propose adding CONFIG_HARD_SPI, which does nothing other than #ifdef compile the hard driver. I will then re-use the data structures and commands from CONFIG_SOFT_SPI.
OK.
My questions:
- The /cpu directory has 'mpc83xx', while in fact there are at least
two groups of chips in this family that have quite different peripherals. Should I put my code here and use #ifdef CONFIG_MPC8349, or start an 'mpc834x' branch?
The current code is all MPC834x, so there should be no changes needed for a 8349. As soon as other code will be added which turns out to fit not well we will consider renaming the current directory into mpc834x.
- Where is the appropriate place to call 'spi_init()'? In my patch,
I've placed it in /lib_ppc/board.c along with 'i2c_init()'. Should it instead go in board code?
I think your decision is OK.
- Should I put changes to README in the same patch, or would you
prefer a different one? Patch size should be < 15kB, so size isn't really an issue.
I'd appreciate to see the README changes in the same patch; this makes understanding much easier.
- More embarassingly, is there a trick to getting new files to show up
when calling 'git diff' on the u-boot tree? I've tried 'git-add',
They turn up when you create a patch; I usually use "cg-mkpatch".
Best regards,
Wolfgang Denk