On Tue, 24 Jan 2012, Govindraj wrote: > On Tue, Jan 24, 2012 at 1:18 AM, Paul Walmsley <paul@xxxxxxxxx> wrote: > > On Mon, 23 Jan 2012, Govindraj wrote: > >> On Mon, Jan 23, 2012 at 4:17 PM, Paul Walmsley <paul@xxxxxxxxx> wrote: > > > > The point is that if you want tty_insert_flip_string() to be called after > > every character is received, there seems little point in using RX DMA. > > It should be less efficient than PIO. And the current way that it is used > > is pointless from a power management point of view. > > Yes, Its between power and performance, current way gives a better > response for most devices That seems rather unlikely. And I don't agree that there is a balance to be struck in this case. Compared to a correctly-working RX PIO path, the RX DMA in the current driver is likely to be much worse in energy consumption, and to be equal at best in receive latency. In a correctly-working RX PIO path, the driver is going to receive an interrupt the moment the data is ready to be transferred from the FIFO. The driver doesn't have to wait for a polling timer to fire and execute. Nor does the ISR have to compete with a 1 microsecond polling timer for the CPU. And I doubt that an accurate comparison could have been made between the PIO and DMA RX paths. In the current driver, the PIO RX FIFO threshold was set to 16 bytes, while the DMA RX FIFO threshold in the DMA path was set to 1 byte. So I'm hardly surprised that the RX DMA path looked good under those circumstances. The current driver is sufficiently broken that any benchmarks based on it are suspect. And in many cases, the way that the driver works around its problems is by effectively disabling system power management. > (specially while downloading the firmware for external chip > initialization and other use cases) Downloading firmware to an external chip uses the transmit path, not the receive path. So that is an orthogonal case. In terms of transmit, it's hardly surprising that the TX DMA path would outperform the driver's current TX PIO path. For one thing, the FIFO handling in the current TX PIO path is broken. The driver doesn't even use 75% of the TX FIFO. Also, the transmission of a large block of data is not sensitive to MPU wakeup latency the same way that RX DMA is. A large block of data can be queued to be transmitted, and the MPU doesn't need to wake up again until the SDMA has finished handing off that data to the UART FIFO. At that point the kernel has plenty of time to prepare the next buffer. - Paul
