On Wed, 18 Jul 2007 11:40:07 -0500
Scott Wood wrote:
> Vitaly Bordug 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.
>
> The CPM reset should take care of that.
>
IIRC we had CPM reset prior, and it didn't help, making all those stuff added.
> >>-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.
>
> It may not save the world, but it's needed to keep the driver from
> poking at the disabled device.
>
I am not against that, just about that it tends to be not enough.
> > 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.
>
> The conflict is in register space, not pins -- why would the smc1
> pins matter?
ok, I may have confused this with something else. Anyway, the only doubt point
is
SMC2 console + SCC3 ENET functionality - it is easier to just test that.
--
Sincerely, Vitaly
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
