On Thu, Nov 6, 2008 at 1:11 AM, René Bürgel <r.buergel@xxxxxxxxxxxxx> wrote: > This patch is a workaround for bug #364 found in the MPC52xx processor. > The errata document can be found under > http://www.freescale.com/files/32bit/doc/errata/MPC5200E.pdf?fpsp=1&WT_TYPE=Errata&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation > > When a device with a low baudrate is connected to the serial port, but the > processor "listens" on a higher baudrate, it might falsely receive breaks > from the controller. During a break, the serial controller may not be reset. > The appended patch provides a workaround for that situation by lowering the > baudrate without resetting the controller and waiting until no break is > received anymore. > I'm still don't like the state of this patch for two reasons: 1. It is enabled/disabled by a #ifdef. It is quite possible that we will eventually be able to build a multiplaform kernel that boots on both mpc5200 and mpc5121. The workaround needs to be detected and enabled at runtime based on the data in the device tree (ie. if the compatible property is "fsl,mpc5200-psc-uart"). 2. I'm do not like the mdelay() busywait loop. The long busy wait just wastes CPU time. Doing it with IRQs off means that irq latencies become unbounded while this is happening. This needs to be reworked to use a workqueue or something similar. Also, I'm not convinced that this is the best fix. It doesn't actually solve the problem, it just makes it less likely to occur. What happens if you instead manipulate portconfig to change the PSC pins to GPIO? I wonder if that will disconnect the RX pin from the PSC entirely. If it does, then that might be a suitable method to eliminate the break condition entirely. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
