[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa686aa40805161432w6b5243f9nb0d0c32a87d86d02@mail.gmail.com>
Date: Fri, 16 May 2008 15:32:20 -0600
From: "Grant Likely" <grant.likely@...retlab.ca>
To: "Jon Smirl" <jonsmirl@...il.com>
Cc: linuxppc-dev@...abs.org, spi-devel-general@...ts.sourceforge.net,
linux-kernel@...r.kernel.org, dbrownell@...rs.sourceforge.net,
fabrizio.garetto@...il.com
Subject: Re: [RFC PATCH 0/4] Describe SPI devices in the OF device tree and add mpc5200-spi driver
On Fri, May 16, 2008 at 3:25 PM, Jon Smirl <jonsmirl@...il.com> wrote:
> On 5/16/08, Grant Likely <grant.likely@...retlab.ca> wrote:
>> On Fri, May 16, 2008 at 2:27 PM, Jon Smirl <jonsmirl@...il.com> wrote:
>> > On 5/16/08, Grant Likely <grant.likely@...retlab.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.
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists