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