Fixing the statement which is producing the warning. Compiled without warning, tested with harmony BT-A2dp. Change-Id: I7540653522124aa93b5afc8551a07e8322b37316 Reviewed-on: http://git-master/r/1381 Reviewed-by: Suresh Mangipudi <smangipudi@nvidia.com> Tested-by: Suresh Mangipudi <smangipudi@nvidia.com> Reviewed-by: Bitan Biswas <bbiswas@nvidia.com> Reviewed-by: Gary King <gking@nvidia.com>
Removed the rx and tx separate lock and used only one lock to control the interrupt enable bit in independent rx and tx path. The interrupt control register is shared between the rx and tx workqueue. Tested on harmony with BT, playing songs for 30 minutes without any packet loss. Change-Id: I690f28559c0ae0c3dc98ab930298e964a7ea07dc Reviewed-on: http://git-master/r/1316 Reviewed-by: Rahul Bansal <rbansal@nvidia.com> Tested-by: Rahul Bansal <rbansal@nvidia.com> Tested-by: Anjali Kotnala <akotnala@nvidia.com> Reviewed-by: Udaykumar Rameshchan Raval <uraval@nvidia.com> Reviewed-by: Gary King <gking@nvidia.com>
Correcting the spelling error in enum definition TEGRA_DMA_REQ_ERROR_ABOTRED to TEGRA_DMA_REQ_ERROR_ABORTED. Tested on harmony. Change-Id: Ie28aea9f87c1a0a2d3f27ce6132fb3eb48eb59e6 Reviewed-on: http://git-master/r/1225 Reviewed-by: Ramachandrudu Kandhala <rkandhala@nvidia.com> Reviewed-by: Venkata (Muni) Anda <vanda@nvidia.com> Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com> Tested-by: Ramachandrudu Kandhala <rkandhala@nvidia.com>
Following improvements are done in the uart rx and tx path: - Separate locks for rx and tx paths. - Implementing the continuous double buffering with same buffer for uart rx. - Deactivating the rts line only incase of if dma does not read the fifo i.e. nonmultiple of 4. - Handling the modem control signal chnage properly. - Created the separate workqueue for the receive to handle dma thresold callback as well as the rx uart interrupts. Tested on harmony and whistler with uart testcase and BT on harmony. we tested the simulatenous file transfer and the A2DP on BT-harmony and did not observe any glitches. Change-Id: Id451ca2f42e246b524a7c9e4bbf3aa832cd0d535 Reviewed-on: http://git-master/r/1172 Reviewed-by: Gary King <gking@nvidia.com> Reviewed-by: Anantha Idapalapati <aidapalapati@nvidia.com> Tested-by: Anantha Idapalapati <aidapalapati@nvidia.com>
Following issue has been fixed: - Blocking write was returning immediatly if data request is multiple of 4. - Blocking write was not able to complete if data length is nonmultiple of 4 and more than 4. - The close was taking too much time because proper timeout and fifo size was not configured. - Tx dma path optimized to fill more data to dma buffer if there is more pending chars in the buffer. - Tx path is fixed to properly signal the wakup event to tty layer. - RTS flow control is not getting set from second open even cflag is requested for that. - Rx dma was not receiving the correct data after second open. The multiple request was getting queued for the receive path at the time of closing. - Rx dma was started before uart controller is configured and it is creating to misbehave the dma. - Transfer count was not getting calculated in the dma driver. Pending issue: - Loosing the data id more than 32K of data was sennt is single shot. Debugging this. Tested on harmony with different testcase developed for testing the linux serial driver. Change-Id: I6ed9095dd6340d2b5e7ef036823d2e4e5a61abcc Reviewed-on: http://git-master/r/1065 Tested-by: Suresh Mangipudi <smangipudi@nvidia.com> Reviewed-by: Udaykumar Rameshchan Raval <uraval@nvidia.com> Tested-by: Udaykumar Rameshchan Raval <uraval@nvidia.com> Reviewed-by: Gary King <gking@nvidia.com>
this driver is no longer being used, and its continued existence just causes confusion. Change-Id: Ia5b4a350b6590bbd0e8914625e9e81951096fb8c Reviewed-on: http://git-master/r/843 Reviewed-by: John Davis <jodavis@nvidia.com> Reviewed-by: Gary King <gking@nvidia.com> Tested-by: Gary King <gking@nvidia.com>
Based on profiling, observed UART Tx to be mostly waiting for a previous DMA to be finished so that it can proceed for further processing of data from upper layers. Two Mmodifications are implemented as part of this commit 1. Forming a DMA request for smaller transfers and waiting for DMA request to be finished introduced overhead. Implemented a polling based transfers for transfers less than a certain limit. 2. Implemented a parallel activity between "DMA Buffer -> UART FIFO" and "Application -> DMA Buffer" copies. introduced a new DMA Buffer which can be made ready by the time DMA finishes use of another DMA Buffer that was filled by Driver. Bug ID: 652334 Change-Id: I30cad291553f9c0c67cb95afa67e468446f7ffd7 Reviewed-on: http://git-master/r/743 Reviewed-by: Gary King <gking@nvidia.com> Tested-by: Gary King <gking@nvidia.com>
Resetting the baudrate variable which stores the current baudrate after resetting the controller. Change-Id: Ia1abf68738897941690644252dbc3d3e4bf6bb0f Reviewed-on: http://git-master/r/712 Reviewed-by: Gary King <gking@nvidia.com> Tested-by: Gary King <gking@nvidia.com>
The serial_core have the modem state variable mctrl which was getting modified by the tegra uart driver. The low level driver should not modify this variable as serial core uses this for the modem control statesi and uses in future for controling the modem states. Removing the modification of this variable from low level driver. Tested with suspend/resume with BT on whistler by monitoring the modem signals. Change-Id: Ib6244c5160e40623a40e4764f5f156dc4f386ec9
tegra serial driver calculates the clock values based on baudrate requested. while calculating clock values for higher baud rates, the intermediate values are getting truncated because of 32-bit overflow. Redefining the intermediate variables to 64-bit(unsigned long long instead of unsigned long) is resolving the issue.