[PATCH 46/61] mpc885ads: Rework initialization.
Vitaly Bordug
vitb at kernel.crashing.org
Wed Jul 18 18:44:02 EST 2007
Overall looks good, though mentioned mutually exclusive SoC devices adding some pain
and extra code having relevant parts removed but not covered (see below).
I think it makes sense to work ontop of this code to address known quirks/issues though, hence will cover this.
yet, there are little chances to play with the 8xx inside this merge window, so I basically don't object from it being merged
as is.
On Tue, 17 Jul 2007 20:36:00 -0500
Scott Wood wrote:
> -#ifdef CONFIG_SERIAL_CPM_SMC1
> - clrbits32(bcsr_io, BCSR1_RS232EN_1);
> - clrbits32(&cp->cp_simode, 0xe0000000 >> 17); /* brg1
> */
> - tmpval8 = in_8(&(cp->cp_smc[0].smc_smcm)) | (SMCM_RX |
> SMCM_TX);
> - out_8(&(cp->cp_smc[0].smc_smcm), tmpval8);
> - clrbits16(&cp->cp_smc[0].smc_smcmr, SMCMR_REN |
> SMCMR_TEN); /* brg1 */ -#else
> - setbits32(bcsr_io,BCSR1_RS232EN_1);
> - out_be16(&cp->cp_smc[0].smc_smcmr, 0);
> - out_8(&cp->cp_smc[0].smc_smce, 0);
> -#endif
these are not just for beauty: if corresponding not-used uart regs are not cleared, second one has a
good chances to be hosed.
> -void init_scc_ioports(struct fs_platform_info *fpi)
> -{
> - int scc_no = fs_get_scc_index(fpi->fs_no);
> + /* The SCC3 enet registers overlap the SMC1 registers, so
> + * one of the two must be removed from the device tree.
> + */
Unfortunately,
this approach has very little chances to work. IIRC, SCC3 eth and SMC1 do have overlapping pins,
and just removing it from the tree is not going to save the world because now we have all-in-one early condensed
pins setup.
Also, we have to be very careful with corresponding ports shutdown: say turn off smc1 if scc3 is enabled: most prolly
it was turned on by the firmware/bootwrapper, and eth won't be alive.
--
Sincerely, Vitaly
More information about the Linuxppc-dev
mailing list