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