1. Theory of the RTS/CTS
=====================

Many perple confuse on the RTS/CTS.
Please read the email for Russull King:
http://marc.info/?l=linux-arm-kernel&m=133554080524774&w=2

"
Well, theres a lot of confusion over RTS.  Most implementations of it
are as per this paragraph on the above page:

 A non-standard symmetric alternative, commonly called "RTS/CTS handshaking=,"
 was developed by various equipment manufacturers. In this scheme, CTS is no
 longer a response to RTS; instead, CTS indicates permission from the DCE
 for the DTE to send data to the DCE, and RTS indicates permission from
 the DTE for the DCE to send data to the DTE. RTS and CTS are controlled
 by the DTE and DCE respectively, each independent of the other. This was
 eventually codified in version RS-232-E (actually TIA-232-E by that time)
 by defining a new signal, "RTR (Ready to Receive)," which is CCITT V.24
 circuit 133. TIA-232-E and the corresponding international standards were
 updated to show that circuit 133, when implemented, shares the same pin
 as RTS (Request to Send), and that when 133 is in use, RTS is assumed by
 the DCE to be ON at all times

This is what is actually used by all NULL modem cables, serial consoles,
and many modems can be (sensibly) configured to support it.  Many
modems can be configured via AT commands to respond as per the above
paragraph too.

And this is the hardware flow control scheme implemented by the Linux
Kernel for CRTSCTS, plus the hardware assisted hardware flow control
provided by industry standard UARTs such as the 1675x and later UARTs.
"

But the IC guy gave me a simple rule about the RTS/CTS signals:
  "The RX side controls the Output signal. The TX side just follows the
  signal of the RX."

2. Connection of the DTE/CTE
=========================

If we connect a mx28-evk with a mx23-evk, the connection should
like this:

	+-------------+                   +-------------+
	|             | 2 -----\/------ 2 |             |
	|             | 3 -----/\------ 3 |             |
	|  MX28(DTE)  |                   |  MX23(DTE)  |
	|             | 7 -----\/------ 7 |             |
	|             | 8 -----/\------ 8 |             |
	+-------------+                   +-------------+


If we connect a mx28-evk with a mx53-evk(with an AUTOMOTIVE PORT CARD).
The connection should like this:

	+-------------+                   +-------------+
	|             | 2 ------------- 2 |             |
	|             | 3 ------------- 3 |             |
	|  MX28(DTE)  |                   |  MX53(DCE)  |
	|             | 7 ------------- 7 |             |
	|             | 8 ------------- 8 |             |
	+-------------+                   +-------------+

3. Test cases
===================

We test the UART with the uart_test application. The uart_test is an internal tool.
We can only tranfer just one byte.

Just take the mx53 as example to show how to test the RTSCTS feature of
the driver. (I am testing the mx53 now.)

 ------------------------- test cases begin here ----------------------
  [1] Use the mx53 as the TX end (use mx28 as RX end).
	< Case 1 > Start the mx28 first: "uart_test /dev/ttySP1 115200 F R 1 1"

	  In the mx53 side, the uart_startup() will call the ->get_mctrl() to
	  get the _CURRENT_ state of modem control inputs. The ->get_mctrl()
	  will return the TIOCM_CTS in this case, since the RTS is asserted
	  by the mx28. So the uart_startup() will set ->hw_stopped to 0.
	  When we start the mx53 to send the data, it will send out the
	  data immediatly without any wait.

	< Case 2 > Start the mx53 first: "uart_test /dev/ttymxc1 115200 F W 1 1"

	  In the mx53 side, the ->get_mctrl() return 0, and the ->hw_stopped
	  will be set to 1. So the mx53 do not send out the data right now,
	  it has to wait until the RTS pin is asserted. See the __uart_start()
	  for the detail.

	  At this time, we can start the mx28 now. It will asserted the mx53's
	  RTS pin. There is an RTSD interrupt arised in the mx53, the interrupt
	  hander will detect the change of RTS pin, and it will call the
	  uart_handle_cts_change() in the end which will send out the data out.

  [2] Use the mx53 as the RX end (use mx28 as TX end).
	< Case 3 > Start the mx53 first: "uart_test /dev/ttymxc1 115200 F R 1 1"

	  The mx53 will assert the mx28's CTS pin, so the mx28 will send out the
	  data immediatly.

	< Case 4 > Start the mx28 first: "uart_test /dev/ttySP1 115200 F W 1 1"

	  The mx28 will wait until its CTS pin is asserted.
	  What about the mx53? When should it asserts the mx28's CTS pin?
	  The CTSC(UCR2) controls the operation of the CTS output pin.
	  When the mx53 is ready, it can set the CTSC bit which will assert
	  the mx28's CTS pin.
 ------------------------- test cases end here -----------------------

The driver should passes all the four test cases!

4. Enable the DMA for uart
==========================

If the uart driver supports the DMA tranfer, it should also passed the
four test cases above. Also you should try to tranfer more bytes,
not just only  byte.
