440EPx - SPI and IIC1 conflict

440EPx - SPI and IIC1 conflict

[Gary Jennejohn]

Hello,

I've developed a driver for the SPI controller in the 440EPx, which should
also work for e.g. the 460EX, and maybe other AMCC processors.

According to the UM bit 14 in SDR0_PFC1 controls whether certain signals
are for IIC1 or SPI.  My driver assures that this bit is set to 0.  Note
that I haven't been able to find any code in the Linux tree which
manipulates this register except for my driver, so IIC1 isn't actually
enabled for the 440EPx or the 460EX.

Anyway.  In order to guarantee that IIC1 doesn't interfere with the
operation of SPI I have this code snippet in i2c-ibm_of.c:

#if (defined(CONFIG_SPI_PPC4xx) || defined(CONFIG_SPI_PPC4xx_MODULE)) \
	&& defined(CONFIG_440EPX)
	/*
	 * Hack, but on the 440EPx we can have either IIC1 or SPI.
	 */
	if (dev->paddr == 0x1ef600800ULL)
		goto fail1;
#endif

which skips IIC1 if the SPI controller is being used.

However, this isn't very aesthetically pleasing.

A colleague suggested testing bit 14 in SDR0_PFC1 and bailing if it's
set.

The problem with this is that the test would depend on the order in which
the init routines are called.  Right now the SPI driver is initialized
before the i2c driver, but I'm not certain that this would be the case for
all time.

Basically I'm wondering whether anyone on this list has any brilliant
idea for handling this problem or whether my present solution is really
just OK.

---
Gary Jennejohn
*********************************************************************
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@denx.de
*********************************************************************

Re: 440EPx - SPI and IIC1 conflict

[Grant Likely]

On Thu, May 15, 2008 at 1:02 PM, Gary Jennejohn <garyj@denx.de> wrote:
> Hello,
>
> I've developed a driver for the SPI controller in the 440EPx, which should
> also work for e.g. the 460EX, and maybe other AMCC processors.
>
> According to the UM bit 14 in SDR0_PFC1 controls whether certain signals
> are for IIC1 or SPI.  My driver assures that this bit is set to 0.  Note
> that I haven't been able to find any code in the Linux tree which
> manipulates this register except for my driver, so IIC1 isn't actually
> enabled for the 440EPx or the 460EX.
>
<snip>
>
> Basically I'm wondering whether anyone on this list has any brilliant
> idea for handling this problem or whether my present solution is really
> just OK.

Yes, this is an easy issue to solve.  The way to do it is to *not* let
your device drivers fiddle with board level configuration stuff (like
the register that selects between SPI and I2C mode).  Instead, that
register should ideally setup by the bootloader, or if that is not
possible, then by the platform code (the board specific stuff in
arch/ppc/platforms/*).  Then your driver can test that bit if it likes
to see if the pins are connected; (or even better, disable the device
entirely by not listing it in the device tree).

In fact, if it doesn't hurt anything to have the device enabled when
the bit is set against it, then the driver shouldn't care.  That makes
the driver more portable to other SoCs, and you should be relying on
the device tree anyway to bind devices to drivers.

For an example, you can look at the MPC5200 support code.  There is a
system level configuration register called "port_config" that controls
pin routing.  In most cases, u-boot sets the right value in
port_config so that Linux code never needs to touch it.  In cases
where we cannot trust u-boot to set things up correctly, like on the
lite5200 board, then the platform code fixes things up.  None of the
mpc5200 device drivers ever touch port_config.  (See
arch/powerpc/platforms/52xx/lite5200.c)

Cheers,
g.

>
> ---
> Gary Jennejohn
> *********************************************************************
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@denx.de
> *********************************************************************
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>



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