On Fri, May 16, 2008 at 3:25 PM, Jon Smirl [off-list ref] wrote:

On 5/16/08, Grant Likely [off-list ref] wrote:

quoted

On Fri, May 16, 2008 at 2:27 PM, Jon Smirl [off-list ref] wrote:
 > On 5/16/08, Grant Likely [off-list ref] wrote:
 >> This series is a set of changes to allow the slaves on an SPI bus to be
 >>  described in the OF device tree (useful in arch/powerpc) and adds a driver
 >>  that uses it (the Freescale MPC5200 SoC's SPI device).
 >
 > Right now we have SPI hooked up to PSC3. Hardware engineer is gone but
 > I'll see if I can get him to alter things to use the SPI controller. I
 > have an old mail from him where he thinks the Phytec board is missing
 > a signal needed to use the SPI controller.


While I'd appreciate the testing, I suspect that you really don't want
 to do that.  The dedicated SPI controller isn't very good.  It only
 does a byte at a time and so is rather slow.  A PSC is SPI mode should
 be better (but I haven't tried it personally it yet).

What is the device tree node for PSC3 supposed to look like when it
has both serial and spi enabled?

The *PSC3 device* cannot support both serial and SPI at the same time.
 Only one mode works at a time...

However, *PSC3 pin group* has can be configured to route both the
*PSC3 device* and the *SPI device* signal out to the board at the same
time.

Pin routing is not something that is described by the device tree.
It's viewed as a board level initialization thing, similar to how DDR
RAM initialization is viewed.  Ideally, the bootloader will write the
correct value into port_config for pin routing and Linux will never
need to touch it.  If the bootloader cannot be changed, then
board-specific platform code can be added to fixup the port_config
setting.  However, the drivers should never touch or care about pin
routing.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.