CPM_UART: Fix non-console transmit

Kalle.

After applying your patch,
the transmission doesn't take place at all..
just hanging in write...
at least it is possible to exit the program.

That's strange. No matter how I test the driver it now works perfectly for me with my patches. Did you apply them both? However, I cannot see why the length of the transmission would cause any difference.

What is you baud rate on SMC2? How about the TX buffer count and TX FIFO size - have you changed them? I suspect that cpm_uart_tx_pump() could disable your TX interrupt when you have all characters queued in separate TX buffers. I'll test this theory tomorrow.

You might want to strace your program and post the results here. Also put

#define DEBUG

in front of cpm_uart_core.c and cpm_uart_cpm2.c and recompile. You'll get a lot of debugging messages after

echo 8 > /proc/sys/kernel/printk

That should give us clues what goes wrong. The output of

stty -F /dev/ttyCPM1 -a

would also help.

Ditto. Your patch fixed my problems. I'd like to see a fix (either this one or another one, there are different solutions) pushed upstream soon, as the problem is quite serious. I'm quite amazed nobody had ever reported it before.

I only applied [PATCH] CPM_UART: Fix non-console transmit

Cheers,

Laurent Pinchart

I think cpm_uart_startup() is the right place to enable both transmitter and receiver, since they are disabled in the corresponding shutdown() function. Or actually, one might be just fine with never disabling the hardware at all. I can't see any reason other than power consumption that they are disabled by the shutdown() function.

It seems the reason of not enabling the transmitter at startup() is that the serial core specification only states that reception should be enabled with that function call. However enabling also the transmitter does not by itself initiate any transmissions, so it should be just fine. It just makes the hardware ready to transmit.