Hi Felipe,
Am 15.08.2014 um 00:58 schrieb Felipe Balbi ba...@ti.com:
Hi,
On Thu, Aug 14, 2014 at 11:04:58PM +0200, Belisko Marek wrote:
during 3.15 release was removed by commit
985bfd54c826c0ba873ca0adfd5589263e0c6ee2 code which was added by
9574f36fb801035f6ab0fbb1b53ce2c12c17d100 by
Hi,
On Fri, Aug 15, 2014 at 08:08:44AM +0200, Dr. H. Nikolaus Schaller wrote:
Hi Felipe,
Am 15.08.2014 um 00:58 schrieb Felipe Balbi ba...@ti.com:
Hi,
On Thu, Aug 14, 2014 at 11:04:58PM +0200, Belisko Marek wrote:
during 3.15 release was removed by commit
This patch provides a 8250-core based UART driver for the internal OMAP
UART. The long term goal is to provide the same functionality as the
current OMAP uart driver and DMA support.
I tried to merge omap-serial code together with the 8250-core code.
There should should be hardly a noticable
The omap needs a DMA request pending right away. If it is enqueued once
the bytes are in the FIFO then nothing will happen and the FIFO will be
later purged via RX-timeout interrupt.
This patch enqueues RX-DMA request on completion but not if it was
aborted on error. The first enqueue will happen
The rx path of the 8250_dma user in the RX-timeout case:
- it starts the RX transfer
if the rx-timeout interrupt occurs, it dmaengine_pause() the transfer
- step two is dmaengine_terminate_all() on this channel.
- based on dmaengine_tx_status() it learns the number of transferred
bytes.
- the
The OMAP UART provides support for HW assisted flow control. What is
missing is the support to throttle / unthrottle callbacks which are used
by the omap-serial driver at the moment.
This patch adds the callbacks. It should be safe to add them since they
are only invoked from the serial_core
Right now it is possible that serial8250_tx_dma() fails and returns
-EBUSY. The caller (serial8250_start_tx()) will then enable
UART_IER_THRI which will generate an interrupt once the TX FIFO is
empty.
In serial8250_handle_irq() nothing will happen because up-dma is set
and so
The OMAP version of the 8250 can actually use 1:1 serial8250_startup().
However it needs to be extended by a wake up irq which should to be
requested enabled at -startup() time and disabled at -shutdown() time.
v2…v3: properly copy callbacks
v1…v2: add shutdown callback
Acked-by: Alan Cox
The serial8250_do_startup() function unconditionally clears the
interrupts and for that it reads from the RX-FIFO without checking if
there is a byte in the FIFO or not. This works fine on OMAP4+ HW like
AM335x or DRA7.
OMAP3630 ES1.1 (which means probably all OMAP3 and earlier) does not like
The rx path of the 8250_dma user in the RX-timeout case:
- it starts the RX transfer
- if the rx-timeout interrupt occurs, it dmaengine_pause() the transfer
- step two is dmaengine_terminate_all() on this channel.
- the rx interrupt occurs, it does not start the RX-transfer because
according to
While comparing the OMAP-serial and the 8250 part of this I noticed that
the latter does not use run time-pm. Here are the pieces. It is
basically a get before first register access and a last_busy + put after
last access. This has to be enabled from userland _and_ UART_CAP_RPM is
required for
This is my complete queue fo the omap serial driver based on the 8250 core
code. I played with it on beagle bone, am335x-evm and dra7xx including DMA.
The uncertain remain the runtime-pm pieces.
I hacked a small serial testing application which sent 10x 4KiB of data in
raw mode. The number of
At least on AM335x the following problem exists: Even if the TX FIFO is
empty and a TX transfer is programmed (and started) the UART does not
trigger the DMA transfer.
After $TRESHOLD number of bytes have been written to the FIFO manually the
UART reevaluates the whole situation and decides that
The OMAP UART needs the RX-DMA programmed right away. If we receive a BREAK
then we have to cancel the DMA transfer before we can handle the break
condition. Otherwise, after we handled the break condition the DMA
engine will start reading bytes from the FIFO while we also purge the
FIFO manually.
There is nothing to do for RPM in the RX path. If the HW goes off then it
won't assert the DMA line and the transfer won't happen. So we hope that
the HW does not go off for RX to work (DMA or PIO makes no difference
here).
For TX the situation is slightly different. RPM is enabled on
start_tx().
This patch adds the required pieces to 8250-OMAP UART driver for DMA
support. The TX burst size is set to 1 so we can send an arbitrary
amount of bytes.
The RX burst is currently set to 48 which means we receive an DMA
interrupt every 48 bytes and have to reprogram everything. Less bytes in
the
Cc: devicet...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/dra7.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 10066f4..a904561 100644
---
Cc: devicet...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4a4e02d..cdccbd6 100644
---
On Fri, Aug 15, 2014 at 07:42:28PM +0200, Sebastian Andrzej Siewior wrote:
This is my complete queue fo the omap serial driver based on the 8250 core
code. I played with it on beagle bone, am335x-evm and dra7xx including DMA.
The uncertain remain the runtime-pm pieces.
I hacked a small serial
On Fri, Aug 15, 2014 at 07:42:33PM +0200, Sebastian Andrzej Siewior wrote:
This patch provides a 8250-core based UART driver for the internal OMAP
UART. The long term goal is to provide the same functionality as the
current OMAP uart driver and DMA support.
I tried to merge omap-serial code
On 08/15/2014 08:17 PM, Lennart Sorensen wrote:
Are you saying that with the new driver you have to respond to the RX
irq faster than before to avoid overflows? It is not quite clear.
Yes. The irq fires 46 bytes giving you 16 bytes buffer before overflow
vs 63 bytes buffer the old one had.
On 08/15/2014 08:37 PM, Lennart Sorensen wrote:
On Fri, Aug 15, 2014 at 07:42:33PM +0200, Sebastian Andrzej Siewior wrote:
This patch provides a 8250-core based UART driver for the internal OMAP
UART. The long term goal is to provide the same functionality as the
current OMAP uart driver and
On Fri, Aug 15, 2014 at 09:27:59PM +0200, Sebastian Andrzej Siewior wrote:
If you want to change this to reduce the gap, then you have first
change 8250 core code. Currently it waits until the shift register is
empty.
Oh the 8250 normally works this way? I didn't know that.
On the other
On 08/15/2014 09:33 PM, Lennart Sorensen wrote:
On the other hand if you use DMA then it can handle transfers 64bytes
in one go and you can start transfers while the FIFO is not completely
empty.
You can dma more than the fifo size?
Yes. The UART asserts the DMA line as long as there is
* Sebastian Andrzej Siewior bige...@linutronix.de [140815 12:16]:
On 08/15/2014 08:17 PM, Lennart Sorensen wrote:
Are you saying that with the new driver you have to respond to the RX
irq faster than before to avoid overflows? It is not quite clear.
Yes. The irq fires 46 bytes giving
* Sebastian Andrzej Siewior bige...@linutronix.de [140815 11:13]:
+#ifdef CONFIG_SERIAL_8250_DMA
+ if (pdev-dev.of_node) {
+ /*
+ * Oh DMA support. If there are no DMA properties in the DT then
+ * we will fall back to a generic DMA channel which does
* Sebastian Andrzej Siewior bige...@linutronix.de [140815 10:46]:
This patch provides a 8250-core based UART driver for the internal OMAP
UART. The long term goal is to provide the same functionality as the
current OMAP uart driver and DMA support.
I tried to merge omap-serial code together
* Tony Lindgren t...@atomide.com [140815 14:10]:
* Sebastian Andrzej Siewior bige...@linutronix.de [140815 10:46]:
This patch provides a 8250-core based UART driver for the internal OMAP
UART. The long term goal is to provide the same functionality as the
current OMAP uart driver and DMA
28 matches
Mail list logo
