On 5/16/08, Grant Likely <grant.likely@secretlab.ca> wrote:
quoted text
> On Fri, May 16, 2008 at 3:25 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>  > On 5/16/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>  >> On Fri, May 16, 2008 at 2:27 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>  >>  > On 5/16/08, Grant Likely <grant.likely@secretlab.ca> 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.

I need to talk to my hardware guy.  He is using PSC3 for the boot
console with the assumption that once booted it is ok to retask it to
SPI. Serial console is only needed for software debugging.  SSH works
after boot and can replace the serial console.

I'll trying changing my device tree entry from UART to SPI and boot.
Hopefully I'll see the console until the SPI driver loads.

quoted text
>
>  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.
>


-- 
Jon Smirl
jonsmirl@gmail.com
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/