[PATCH 1/2] serial/imx: add DMA support

[Russell King - ARM Linux]

On Fri, Apr 27, 2012 at 05:46:22PM +0800, Huang Shijie wrote:
>>>> 1. How do you deal with transmitting the high-priority XON/XOFF
>>>>      characters (port->x_char) which occur with s/w flow control and
>>>>      the tty buffers fill up?
>>>> 2. How do you deal with flow control in general?  IOW, what happens
>>>>      when the remote end deasserts your CTS with h/w flow control enabled.
> If the remote end deasserts my CTS, it means the remote will not send  
> any data.
>
> My DMA for RX will expire in the following steps:
> [1] the UART only waits for 32 bytes time long
> [2] the UART triggers an IDLE Condition Detect DMA.
> [3] the dma_rx_callback() will release the DMA for Rx.

Err, hang on.  I think you're totally confused about hardware flow
control.  Certainly you're not using the correct terms for what you're
describing.

The CTS input normally controls the transmitter.  In many hardware
assisted hardware flow control setups, the deassertion of CTS merely
prevents the transmitter starting a new character.

This shouldn't have any effect on the receiver of the same UART at all.

>>>>      How does your end deal with sending RTS according to flow control
>>>>      conditions?
>>>>
> If a CTS is received after we sent out a RTS, it will follow the steps:
>  imx_int() --> imx_rtsint() --> uart_handle_cts_change() -->start_tx()
>
> The start_tx() will create an TX DMA operation, and send out the data.

The generation of RTS (connected to the remote ends CTS signal) is
supposed to control whether the remote end sends you characters.  RTS
gets deasserted either by software control when you're running out of
space to store the received characters, or (in the case of hardware
assisted hardware flow control) your receivers FIFO fills above a
certain watermark.

>> It should not.  prep_slave_sg() must be callable from atomic contexts.
>>
> the Documentation/dmaengine.txt does not explicitly force all the  dma  
> engine driver
> to do so.
>
> Add more comments for it in Documentation/dmaengine.txt?

Nevertheless, it is common practice for drivers to call prep_slave_sg()
from atomic contexts.  It sounds like your DMA driver is being fixed
anyway, so these tasklets can be killed.