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 _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
