CPM_UART: tcdrain() is broken
Laurent Pinchart
laurent.pinchart at tbox.biz
Tue Nov 14 23:45:21 EST 2006
Hi,
> > > > There is, however, a problem left. The SCC controllers have a 32-
> > > > byte FIFO between the buffer descriptors and the wires.
> > > > cpm_uart_tx_empty() checks if all buffer descriptors have been
> > > > processed, but doesn't check if the transmit FIFO is actually empty.
> > >
> > > There is no way to determine if the hardware FIFO is empty.
> > > It's buried under the CPM microcode.
> >
> > I was hoping the information would be somewhere in the parameter RAM :-(
> >
> > > > ..... I can't figure out how to do so from the datasheet.
> > > > Does anyone have an idea ?
> > >
> > > The original versions of the SCC UART driver used to have a
> > > timeout based on the maximum depth of this FIFO and baud rate.
> > > After the last BD was empty, it would further wait this amount of
> > > time. Lots of these little details seem to have been lost over
> > > the years of making a "better" driver :-)
> >
> > That's a solution, but we might wait longer than necessary then. Vitaly,
> > what's your opinion ? We should at least set fifosize to a proper value
> > (see my previous mail). I'll submit a patch after we agree on the need
> > for an additional delay.
>
> Well, I also bothered Dan with the same question some time ago, getting the
> same answer :) I think here we aught to have this delay ported, but under
> Kconfig option, so that those who are happy with current being, do not
> suffer from additional delays.
There might be another way. Setting TxBD[CR] to 1 will generate the TX
interrupt only when the stop bit of the last character in the buffer begins
transmission. I still have to find out if it applies to the time when the CPM
clears TxBD[R] as well. If so, this would be better than a fixed delay, but
it would also prevent buffers from being sent back-to-back (3 bits of idle
are sent between consecutive buffers).
Laurent Pinchart
More information about the Linuxppc-embedded
mailing list