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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
