[PATCH] CS4270 node is misplaced in the MPC8610 device tree

Timur Tabi timur at freescale.com
Tue May 20 06:17:10 EST 2008


Timur Tabi wrote:
> Anton Vorontsov wrote:
> 
>> Hm... this should be controlled by the PIXIS' BRDCFG0's I2CSPAN and
>> SERSEL bits:
> 
> Since these pins should not have changed from one kernel version to another, it
> doesn't explain how my device "jumped" from I2C2 to I2C1.  I'm debugging this now.

I found the problem.  Your patch "86xx: mpc8610_hpcd: fix second serial port"
fixes it.

The original code moved the I2C devices from I2C1 to I2C2.  On R1 boards, the
default for I2CSPAN was 1 because the chip used on those boards would bridge the
two buses together if I2CSPAN==1.  On R3 boards, a different chip is used, and
I2CSPAN==1 means to use I2C2 instead of I2C1.  On R1 boards, the default for
BRDCFG0 is 0xBD, but on R3 boards it's 0xB8.  So when
mpc8610hpcd_set_monitor_port() wrote 0xBD to BRDCFG0, it moved the I2C devices
from I2C1 to I2C2.

I also had a hard time pinpointing this code because
mpc8610hpcd_set_monitor_port() is called only when the DIU is enabled.  Since I
don't have anything attached to my DIU port, I don't always enable the DIU.  So
some of my kernels had DIU support, and some of them didn't!  Those kernels that
have DIU enabled but not your patch will move the devices to I2C2.  I was
running one of those kernels when I posted my patch.

So in summary, this patch "CS4270 node is misplaced in the MPC8610 device tree"
should not be applied.  The I2C devices should stay on I2C1.

-- 
Timur Tabi
Linux kernel developer at Freescale



More information about the Linuxppc-dev mailing list