From: Huang Shijie <shijie8@gmail.com> To: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Huang Shijie <b32955@freescale.com>, B20596@freescale.com, B20223@freescale.com, gregkh@linuxfoundation.org, r58066@freescale.com, linux-serial@vger.kernel.org, shawn.guo@linaro.org, s.hauer@pengutronix.de, linux-arm-kernel@lists.infradead.org, alan@linux.intel.com Subject: Re: [PATCH 1/2] serial/imx: add DMA support Date: Fri, 27 Apr 2012 11:18:15 -0400 [thread overview] Message-ID: <CAMiH66FoEYEqudAOx7Y8GpgjfT-gX2qOi0BjG0-X8xH8u24kSw@mail.gmail.com> (raw) In-Reply-To: <20120427095003.GK24211@n2100.arm.linux.org.uk> On Fri, Apr 27, 2012 at 5:50 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > 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 http://en.wikipedia.org/wiki/Flow_control#Hardware_flow_control From the wiki, the generation of RTS (assert by the "master end") is used to send data from the master to slave(the remote), not control the remote end sends me characters. Best Regards Huang Shijie > 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. > >>> -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: shijie8@gmail.com (Huang Shijie) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/2] serial/imx: add DMA support Date: Fri, 27 Apr 2012 11:18:15 -0400 [thread overview] Message-ID: <CAMiH66FoEYEqudAOx7Y8GpgjfT-gX2qOi0BjG0-X8xH8u24kSw@mail.gmail.com> (raw) In-Reply-To: <20120427095003.GK24211@n2100.arm.linux.org.uk> On Fri, Apr 27, 2012 at 5:50 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > 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 http://en.wikipedia.org/wiki/Flow_control#Hardware_flow_control >From the wiki, the generation of RTS (assert by the "master end") is used to send data from the master to slave(the remote), not control the remote end sends me characters. Best Regards Huang Shijie > 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. > >>>
next prev parent reply other threads:[~2012-04-27 15:18 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-04-26 10:37 [PATCH 0/2] add DMA support to uart Huang Shijie 2012-04-26 10:37 ` Huang Shijie 2012-04-26 10:37 ` [PATCH 1/2] serial/imx: add DMA support Huang Shijie 2012-04-26 10:37 ` Huang Shijie 2012-04-26 11:11 ` Russell King - ARM Linux 2012-04-26 11:11 ` Russell King - ARM Linux 2012-04-27 7:00 ` Huang Shijie 2012-04-27 7:00 ` Huang Shijie 2012-04-27 8:22 ` Russell King - ARM Linux 2012-04-27 8:22 ` Russell King - ARM Linux 2012-04-27 8:38 ` Richard Zhao 2012-04-27 8:38 ` Richard Zhao 2012-04-27 9:46 ` Huang Shijie 2012-04-27 9:46 ` Huang Shijie 2012-04-27 9:50 ` Russell King - ARM Linux 2012-04-27 9:50 ` Russell King - ARM Linux 2012-04-27 15:18 ` Huang Shijie [this message] 2012-04-27 15:18 ` Huang Shijie 2012-04-27 15:30 ` Russell King - ARM Linux 2012-04-27 15:30 ` Russell King - ARM Linux 2012-04-28 8:53 ` Huang Shijie 2012-04-28 8:53 ` Huang Shijie 2012-04-26 12:00 ` Sascha Hauer 2012-04-26 12:00 ` Sascha Hauer 2012-04-27 6:09 ` Huang Shijie 2012-04-27 6:09 ` Huang Shijie 2012-05-16 9:37 ` Philippe Rétornaz 2012-05-16 9:37 ` Philippe Rétornaz 2012-05-16 9:42 ` Huang Shijie 2012-05-16 9:42 ` Huang Shijie 2012-04-27 17:24 ` Arnd Bergmann 2012-04-27 17:24 ` Arnd Bergmann 2012-04-28 8:54 ` Huang Shijie 2012-04-28 8:54 ` Huang Shijie 2012-04-26 10:37 ` [PATCH 2/2] ARM: MX6q: enable DMA support for UART2 Huang Shijie 2012-04-26 10:37 ` Huang Shijie
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAMiH66FoEYEqudAOx7Y8GpgjfT-gX2qOi0BjG0-X8xH8u24kSw@mail.gmail.com \ --to=shijie8@gmail.com \ --cc=B20223@freescale.com \ --cc=B20596@freescale.com \ --cc=alan@linux.intel.com \ --cc=b32955@freescale.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-serial@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=r58066@freescale.com \ --cc=s.hauer@pengutronix.de \ --cc=shawn.guo@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.