* Grygorii Strashko | 2015-12-12 10:30:10 [+0200]:
>git://git.ti.com/~gragst/ti-linux-kernel/gragsts-ti-linux-kernel.git
sucked in, thanks.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo
* Grygorii Strashko | 2015-10-15 19:33:43 [+0300]:
>Hi Thomas,
>
>On 10/13/2015 09:33 PM, Thomas Gleixner wrote:
>>Grygorii,
>>
>>On Tue, 13 Oct 2015, Grygorii Strashko wrote:
>>>I'd very appreciate for any advice of how to better proceed with your
>>>request.
>>> - I can try to apply and
* Bjorn Helgaas | 2015-12-04 12:46:19 [-0600]:
>The backtrace might be OK (maybe slightly overkill), but all the
>stack addresses are certainly irrelevant and distracting. We only
>need enough to recognize the problem. I don't think the modules list
>is relevant either.
I would shorten it to
On 11/06/2015 08:59 PM, Grygorii Strashko wrote:
> Hi Sebastian,
Hi Grygorii,
> - IRQF_NO_THREAD is the first considered option for such kind of issues.
> But: Now in LKML there are ~60 occurrences of IRQF_NO_THREAD - most of
> them are used by Arch code. And It's only used by 6 drivers
On 11/05/2015 07:43 PM, Grygorii Strashko wrote:
> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> index 6589e7e..31460f4 100644
> --- a/drivers/pci/host/pci-dra7xx.c
> +++ b/drivers/pci/host/pci-dra7xx.c
> @@ -302,8 +302,30 @@ static int __init
RX-DMA completly on probe.
The rx_dma_broken assignment on probe could be removed once we working
pause function in omap-dma.
Cc: sta...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
v1…v2:
- disable RX-DMA right on boot
drivers/tty/serial/8250/8250_omap.c
counter so userpace
has a clue that we lost bytes.
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_omap.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial
...@linuxfoundation.org
Signed-off-by: John Ogness john.ogn...@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index
sensitive protocols that
transfer less than 48 bytes will have to wait 250ms to complete.
Is there maybe a user interface where one could set small or bulk transfers?
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_omap.c | 33
On 08/11/2015 12:06 PM, Russell King - ARM Linux wrote:
I think what people need to learn is that an API in the kernel which
returns an int _can_ fail - it returns an int so it _can_ return an
error code. If it _can_ return an error code, there _will_ be
implementations which _do_.
If you
On 08/10/2015 01:54 PM, Peter Ujfalusi wrote:
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 0340ee6ba970..07a11e0935e4 100644
--- a/drivers/tty/serial/8250/8250_omap.c
@@ -769,7 +771,9 @@ static void omap_8250_rx_dma_flush(struct uart_8250_port
On 08/08/2015 02:28 AM, Peter Hurley wrote:
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 0340ee6ba970..07a11e0935e4 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -769,7 +771,9 @@ static void
On 08/07/2015 03:17 PM, Russell King - ARM Linux wrote:
On Fri, Aug 07, 2015 at 02:35:45PM +0200, Sebastian Andrzej Siewior wrote:
On 08/07/2015 12:55 PM, Russell King - ARM Linux wrote:
On Fri, Aug 07, 2015 at 10:41:57AM +0200, Sebastian Andrzej Siewior wrote:
This DMA driver is used by 8250
On 08/07/2015 03:22 PM, Russell King - ARM Linux wrote:
On Fri, Aug 07, 2015 at 12:36:14PM +0200, Sebastian Andrzej Siewior wrote:
On 08/07/2015 11:44 AM, Peter Ujfalusi wrote:
with a short testing audio did not broke (the only user of pause/resume)
Some comments embedded.
Cc: sta
...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_omap.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 0340ee6ba970..07a11e0935e4 100644
it does only pause +
terminate.
Cc: sta...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/dma/omap-dma.c | 54 ++
1 file changed, 41 insertions(+), 13 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers
On 08/07/2015 11:44 AM, Peter Ujfalusi wrote:
On 08/07/2015 11:41 AM, Sebastian Andrzej Siewior wrote:
This DMA driver is used by 8250-omap on DRA7-evm. There is one
requirement that is to pause a transfer. This is currently used on the RX
side. It is possible that the UART HW aborted the RX
On 08/07/2015 06:07 PM, Peter Hurley wrote:
If we look at what 8250-dma.c is doing:
if (dma-rx_running) {
dmaengine_pause(dma-rxchan);
It's 8250-dma.c which is silently _ignoring_ the return code, failing
to check that the operation it requested
()
will keep the pause bit set and we can't pause the following
transfer.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/dma/omap-dma.c | 107 +
1 file changed, 73 insertions(+), 34 deletions(-)
diff --git
* Russell King - ARM Linux | 2015-08-07 17:26:48 [+0100]:
On Fri, Aug 07, 2015 at 05:36:05PM +0200, Sebastian Andrzej Siewior wrote:
+/*
+ * We do not allow DMA_MEM_TO_DEV transfers to be paused.
+ * According to RMK the OMAP hardware might prefetch bytes
On 08/07/2015 05:29 PM, Russell King - ARM Linux wrote:
On Fri, Aug 07, 2015 at 11:08:48AM -0400, Peter Hurley wrote:
[ + Greg KH ]
On 08/07/2015 09:57 AM, Russell King - ARM Linux wrote:
As it is something that the driver has _not_ supported, you are clearly
adding a feature to an existing
-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
include/linux/dmaengine.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 8ad9a4e839f6..4eac4716bded 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux
#1 is something that can go stable and disables RX-DMA should it
notice that it does not work.
#2 adds the anotation as suggest by Russell.
#3 adds the missing feature to omap-dma so dmaengine_pause() works. Once
this is merged, the warning from #1 disappears.
--
To unsubscribe from this
not allowed.
- clear pause on terminate_all. Otherwise pause() + terminate_all()
will keep the pause bit set and we can't pause the following
transfer.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/dma/omap-dma.c | 122
support was not the best back then but I am
almost sure that I had vanilla running for testing.
But I don't insist on the stable tag. Consider it dropped.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/dma/omap-dma.c | 54
On 08/07/2015 12:55 PM, Russell King - ARM Linux wrote:
On Fri, Aug 07, 2015 at 10:41:57AM +0200, Sebastian Andrzej Siewior wrote:
This DMA driver is used by 8250-omap on DRA7-evm. There is one
requirement that is to pause a transfer. This is currently used on the RX
side. It is possible
On 08/06/2015 02:27 PM, Peter Hurley wrote:
Hi Sebastian,
Hi Peter,
On 08/04/2015 07:58 AM, Sebastian Andrzej Siewior wrote:
On 08/03/2015 09:32 PM, Peter Hurley wrote:
You mean a function in 8250-dma API which does what I did just here
with the wait_event() and the wake_up in the callback
On 08/06/2015 02:31 PM, Sebastian Andrzej Siewior wrote:
Hi Peter,
I'll look at/test this this weekend, ok?
Sure. I'm currently re-spinning the patches so have everything in
proper pieces. While at it I will take a look at x_char.
So now that I actually look at it. If I read this right, we
On 08/03/2015 09:32 PM, Peter Hurley wrote:
You mean a function in 8250-dma API which does what I did just here
with the wait_event() and the wake_up in the callback? That way I could
move the termios_wait into the dma struct instead of keeping in the
omap specific part. I am also not sure if
* Peter Hurley | 2015-07-30 20:51:10 [-0400]:
Hi John,
Hi Peter,
I was never really a fan of the deferred set_termios();
I think it's more appropriate to wait for tx dma to
complete in omap_8250_set_termios().
So you want something like this? This was only compile + boot tested
(without
On 08/03/2015 06:34 PM, Peter Hurley wrote:
Hi Sebastian,
Hi Peter,
struct old_serial_port {
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index d9a37191a1ae..12249125a218 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++
On 07/27/2015 02:50 PM, Linus Walleij wrote:
Patch applied.
thanks.
Now this question appear in my head:
Is drivers/gpio full of stuff that will not work with the -RT kernel,
and is this a change that should be done mutatis mutandis on
all the GPIO drivers?
I described two call paths
() / gpio_set_debounce()
looks low but still this is not good.
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
Acked-by: Santosh Shilimkar ssant...@kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/gpio/gpio-omap.c | 82
On 07/09/2015 11:46 PM, Pavel Machek wrote:
On Thu 2015-07-09 23:39:22, Pavel Machek wrote:
Hi!
Hi,
sysfs should contain one value per file. This one has at least two,
with nice english sentence as a bonus.
root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto#
On 06/30/2015 12:55 PM, Grygorii Strashko wrote:
Hi Sebastian, All,
Hi Grygorii,
The problem here is that OMAPs code implemented using PM runtime based
approach and PM runtime is used everywhere. We don't see warnings form
other drivers just because their HW IRQ handlers forced to be
On 06/30/2015 08:45 AM, Linus Walleij wrote:
This doesn't apply to the current development tree.
it has been pointed out to me.
Can you rebase this patch in Torvalds' HEAD, add Javier's ACK
and resend?
I will do it once I'm done roasted :)
Please put me on the To: line, I have no time to
() / gpio_set_debounce()
looks low but still this is not good.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/gpio/gpio-omap.c | 78 +++
1 file changed, 39 insertions(+), 39 deletions(-)
--- a/drivers/gpio/gpio-omap.c
handler like it is doing now.
So lets try that.
Fixes: ca8bb4aefb93 (serial: 8250: Revert tty: serial: 8250_core:
read only RX if there is something in the FIFO)
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250
On 04/12/2015 02:23 AM, Nishanth Menon wrote:
I think for the moment we should just freeze omap-serial and let
most of userspace catch up first; a lot of the official and
unofficial vender support is still stuck in 3.14. By the time,
3.19+ is de rigueur we'll hopefully have figured out the
Hi Shawn,
On Fri, Mar 13, 2015 at 11:29:32AM +0800, Shawn Guo wrote:
We did not add a DT property for it, because there was already enough
info (clock configuration) in DT for kernel to figure it out.
Correct. My understanding is whatever can be figured out without DT should
be done that way.
On 2015-02-17 14:01:04 [-0800], Stephen Boyd wrote:
diff =
--- arch/arm/mach-imx/mach-imx6q.c
+++ /tmp/cocci-output-11792-b62223-mach-imx6q.c
@@ -211,7 +211,6 @@ static void __init imx6q_1588_init(void)
* set bit IOMUXC_GPR1[21]. Or the PTP clock must be from pad
* (external
On 02/16/2015 09:54 AM, Javier Martinez Canillas wrote:
Hello Sebastian,
Hello Javier,
Right, those are bugs regardless of PREEMPT_RT or not as you said.
I'll add it to my TODO list, thanks for finding those.
Thanks.
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
Best regards,
on it. Therefore the Omap fix is
reverted for now.
Fixes: 0aa525d11859 (tty: serial: 8250_core: read only RX if there is
something in the FIFO)
Reported-By: Nicolas Schichan nschic...@freebox.fr
Debuged-By: Peter Hurley pe...@hurleysoftware.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
...@hurleysoftware.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/8250/8250_core.c | 10 --
drivers/tty/serial/8250/8250_omap.c | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial
* Peter Hurley | 2015-02-12 11:32:04 [-0500]:
That said, I don't think serial8250_do_startup() is really doing that much
for OMAP h/w startup; open-coding what omap_8250 really needs is probably
10 loc.
10 loc? I have a few more. serial8250_clear_fifos(),
serial_link_irq_chain() aren't
On 02/12/2015 08:55 PM, Peter Hurley wrote:
On 02/12/2015 02:23 PM, Sebastian Andrzej Siewior wrote:
* Peter Hurley | 2015-02-12 11:32:04 [-0500]:
That said, I don't think serial8250_do_startup() is really doing that much
for OMAP h/w startup; open-coding what omap_8250 really needs
of gpiod_set_debounce() / gpio_set_debounce()
looks low but still this is not good.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/gpio/gpio-omap.c | 78
1 file changed, 39 insertions(+), 39 deletions(-)
diff --git a/drivers
On 02/11/2015 09:42 PM, Peter Hurley wrote:
Reverting makes sense to me if it has caused a regression. Maybe Sebastian
can update his patch to do this based on some quirk flag instead?
That's fine with me. There's a 'bugs' field in struct 8250_uart_port and
UART_BUG_* defines in 8250/8250.h
On 02/10/2015 12:34 AM, Peter Hurley wrote:
The too much work message means serial8250_handle_irq() is returning 0,
ie., not handled. Which in turn means IIR indicates no interrupt is pending
(UART_IIR_NO_INT == 1).
The OMAP UART for instance have two possible TX-IRQ handling. The
default is
This patch invokes add_preferred_console() with ttyS based on ttyO
arguments if the user didn't specify it on its own. This ensures that
the user will see the kernel booting on his serial console in case he
forgot to update the command line.
Signed-off-by: Sebastian Andrzej Siewior bige
On 12/11/2014 09:34 PM, Nicolae Rosia wrote:
Hello,
Hi,
Any updates on this series? I don't see it applied in [1] or [2].
I manage to freeze am335x-evm with those patches and I think Vignesh
is looking into this.
Regards,
Nicolae Rosia
Sebastian
--
To unsubscribe from this list: send the
On 12/01/2014 10:53 AM, Vignesh R wrote:
Hi Sebastian,
Hi Vignesh,
I fixed the issue that was triggering the WARN_ON(). I think it would be
better if you tested these patches, before I posted them on the
mainline. I don't want to clutter the list with too main versions. Here
is the link to
On 12/01/2014 05:38 PM, Tony Lindgren wrote:
* One Thousand Gnomes gno...@lxorguk.ukuu.org.uk [141201 06:11]:
Well the nightmare userspace switch from ttyS to ttyO few years ago is
something we want to avoid.. I think the best solution would be to make
serial-omap.c transparently provide
* Sebastian Andrzej Siewior | 2014-11-26 23:01:46 [+0100]:
Technically speaking this is not required. If both are enabled then the
Maikefile order says that 8250 one wins, the second is never probed.
If we choose to enable 8250_omap via defconfig then one might get supprised
that his console
ttyOx.
This patch _tries_ to bring this to the users' attention by not showing
the serial-omap driver once the 8250 one is enabled. So the user might
choose to use the help text which says that this driver (8250_omap)
uses ttySx instead ttyOx.
Signed-off-by: Sebastian Andrzej Siewior bige
On 11/06/2014 09:35 PM, Tony Lindgren wrote:
The pinctrl change in this patch and the wake-up events are a separate
issue.
So this patch can go in and wake-up issue will be fixed once the
infrastructure is there. No misunderstanding here?
Tony
Sebastian
--
To unsubscribe from this list:
On 11/21/2014 02:10 PM, Richard Cochran wrote:
On the BB white using the LCD4 cape and the shipped debian kernel, the
cursor *does* jump away, but not as often or as far as on the custom
design I was working with.
This sounds like the ADC is still sampling while the input data becomes
* Vignesh R | 2014-11-14 10:37:25 [+0530]:
This series of patches fix TSC defects related to lag in touchscreen
performance and cursor jump at touch release. The lag was result of
udelay in TSC interrupt handler. Cursor jump due to false pen-up event.
The patches implement Advisory 1.0.31 in
On 11/24/2014 01:16 PM, Vignesh R wrote:
I have tried running both IIO and TSC at the same time. But I have never
seen WARN_ON() even after running for close to 30 min. Can you send me
the exact script, so that it will be easy to reproduce?
Sure thing.
- one shell
evtest
On 11/05/2014 08:43 PM, Lennart Sorensen wrote:
I managed to get something dma related on uart3. But it isn't happy:
[ 95.577401] DMA misaligned error with device 53
repeated many times.
I wonder if the dma support isn't quite working for the omap572x yet in
this tree (ti's 3.12.y
On 11/06/2014 04:14 AM, Greg KH wrote:
I've now applied the patches here that I could, if I have missed any,
please let me know and resend.
Thank you Greg. I pulled your tty-testing and it seems to work on
am335x-evm/dra7-evm.
Tony, if you could please take the two .dts files then the series
...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_omap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 57a8b1241b85..1681875f2996 100644
--- a/drivers/tty
On 11/06/2014 08:15 PM, Nishanth Menon wrote:
sounds good to me *IF* omap8250_enable_wakeup (wakeirq handling) is
the way we want to continue doing things for daisychain? - Tony, can
you comment?
http://marc.info/?l=linux-omapm=141222144402707w=2
I wonder if wakeirq explicit handling is
On 11/05/2014 02:15 AM, Lennart Sorensen wrote:
Well 4 hours running with multiple reboots (our testsuite reboots every
30 minutes to test the watchdog). So far it has only lost 70 bytes out
of 40MB of data sent between uart7 and uart8 (and we are pretty sure
the serial test has a small bug
On 11/05/2014 05:20 PM, Lennart Sorensen wrote:
On Wed, Nov 05, 2014 at 10:33:15AM -0500, Lennart Sorensen wrote:
Two systems ran 16 hours each so far with no issues. Pushed 170MB of
data through the pair of serial ports on one system at 230400.
The console on uart3 doesn't appear to be
On 11/04/2014 12:44 PM, Vignesh R wrote:
I ran following commands
$ evtest /dev/input/touchscreen0
(with heavy item on touchscreen)
and
$ cat /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage4_en
(in a busy loop)
I tried above experiment on my board but I didn't hit any problem
On 11/04/2014 06:02 PM, Lennart Sorensen wrote:
According to the manual the DMA channels for UART7 to 10 are:
uart7: 144 145
uart8: 146 147
uart9: 148 149
uart10: 150 151
Might as well add those too. We have uart 7 and 8 in use on our board
so I am about to go test it.
Mind
On 10/27/2014 08:02 PM, Griffis, Brad wrote:
On 10/27/2014 12:34 PM, Sebastian Andrzej Siewior wrote:
Do we really need #3 (and then #4)? Given the complexity we have already, is
there any benefit by decreasing this value?
I specifically requested we add ti,charge-delay to the device tree
On 10/27/2014 12:08 PM, Vignesh R wrote:
This series of patches fix TSC defects related to lag in touchscreen
I will try to look this in the next few days. Do we really need #3 (and
then #4)? Given the complexity we have already, is there any benefit by
decreasing this value? Would someone want
with a crash as follows:
good, Thanks.
Acked-by: Sebastian Andrzej Siewior bige...@linutronix.de
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/21/2014 06:23 PM, Nishanth Menon wrote:
The final solution is to transition off to use 8250 driver and no
dependency on console structures and move away from omap-serial driver,
hence no major cleanups are done for this driver.
So the shiny new driver works for you, is this what you
* Frans Klaver | 2014-09-30 10:44:16 [+0200]:
On Mon, Sep 29, 2014 at 12:30:43PM +0200, Frans Klaver wrote:
On Mon, Sep 29, 2014 at 11:54:40AM +0200, Sebastian Andrzej Siewior wrote:
For your too much work for irq problem: Could you add trace_printk()
in tx/rx dma start/complete, and irq
* Tony Lindgren | 2014-10-02 09:43:39 [-0700]:
Looks good to me. For the patches that do not yet have my acks, please
feel free to add:
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Thanks.
It's probably best that I queue the .dts changes separately
* Frans Klaver | 2014-09-29 10:50:42 [+0200]:
This version fixes the console things for us. It also increases the
amount of data we can push over the serial port. If I push the data
towards our requirements, we're not there yet. I get the too much work
for irq notice still. However, I don't think
* Frans Klaver | 2014-09-29 11:26:06 [+0200]:
On Wed, Sep 10, 2014 at 09:30:08PM +0200, Sebastian Andrzej Siewior wrote:
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
* Frans Klaver | 2014-09-29 11:38:23 [+0200]:
threshold
fixed
+/*
+ * It claims to be 16C750 compatible however it is a little different.
+ * It has EFR and has no FCR7_64byte bit. The AFE (which it claims to
+ * have) is enabled via EFR instead of MCR. The type is set here
* Frans Klaver | 2014-09-29 11:46:20 [+0200]:
On Wed, Sep 10, 2014 at 09:29:57PM +0200, Sebastian Andrzej Siewior wrote:
+/*
+ * This two wrapper ensure, that enable_runtime_pm_tx() can be called more
than
These two wrappers ensure that enable_runtime_pm_tx() ...
fixed
@@ -1469,7 +1531,12
* Peter Hurley | 2014-09-17 08:20:41 [-0400]:
So I connected my am335x-evm
with beagle board xm because both of them have an old fashion UART
connector (instead those uart-to-usb). Both configured with HW-Flow and
I haven't seen the function invoked but I saw port-icount.overrun
being
The queue is getting smaller. The highlights of v9…v10
- the DMA stall Frans Klaver reported which popped up in yocto is gone. It
also seems that the ack the err-irq even if nothing happened in EDMA
can be dropped.
- the RX- and TX-DMA callbacks are now OMAP-only and no bugs flags are
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/dma/edma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7b65633f495e..123f578d6dd3 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -288,7
in the driver
in startup.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_omap.c | 96 +
1 file changed, 96 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
for the TX side.
*Now* we learn about the RX status based on our bookkeeping and don't
need dmaengine_tx_status() for this anymore.
Cc: vinod.k...@intel.com
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
__stop_tx(). Should it been filed then in the
start_tx() path we should program the DMA transfer and remove the error
flag and the THRI bit.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_omap.c | 144
include
.
This patch provides callbacks for custom TX/RX DMA implementation. If
there are not setup / used, then the default (current) implementation is
used.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 3 +++
drivers/tty/serial/8250/8250_core.c | 11
Frans reworded the two comments with better English for better
understanding. His review hit the mailing list after the patch got
applied so here is an incremental update.
Reported-by: Frans Klaver frans.kla...@xsens.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers
of serial8250_start_tx()
succeed then the dma_tx_err flag along with the THRI bit is removed and
DMA only usage may continue.
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h
-by: Frans Klaver frans.kla...@xsens.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_omap.c | 914
drivers/tty/serial/8250/Kconfig | 9 +
drivers/tty/serial/8250/Makefile| 1 +
3 files changed, 924
/0x228)
…
| [c009fa48] (SyS_init_module) from [c000e6e0] (ret_fast_syscall+0x0/0x30)
| Code: 7823603b f8314620 051b3013 491ed416 (44792204)
because serial8250_console_setup() is already gone.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 2
Cc: devicet...@vger.kernel.org
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
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
IRQ handler :)
Cc: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Peter Hurley pe...@hurleysoftware.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 2 ++
drivers/tty/serial/8250/8250_core.c | 6 ++--
drivers/tty/serial/8250
routine.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_omap.c | 71 +
1 file changed, 71 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index
Cc: devicet...@vger.kernel.org
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
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
* Heikki Krogerus | 2014-09-22 10:46:05 [+0300]:
Well, there are no other SoCs at the moment that would need it, and
it's actually possible that there never will be. So yes, just handle
that also in the omap specific code.
Okay. So let me move the irq routine and the workarounds into omap then.
* Sebastian Andrzej Siewior | 2014-09-24 09:53:46 [+0200]:
* Peter Hurley | 2014-09-23 13:03:51 [-0400]:
But DMA is cheating if the UART driver's tx_empty() method is saying the
transmitter is empty while TX DMA is still running.
This shouldn't be the case. But I will check this once I able
* Peter Hurley | 2014-09-25 07:31:32 [-0400]:
I just verified that GNU readline6 uses ioctl(TCSETSW, ...) to do the
set_termios
(which is the ioctl that libc should use for tcsetattr(TCSADRAIN)).
Maybe this userspace is using a readline()-alike that has a bug by not using
the
correct
* Frans Klaver | 2014-09-22 11:28:54 [+0200]:
I guess then we'd still have to answer the question why the yocto build
calls set_termios() so often, but that's not on you then. Did you notice
it even changing settings? We might want to fix this even if the kernel
should be able to cope.
could you
* Peter Ujfalusi | 2014-09-20 00:29:01 [+0300]:
mask 800 means URXEVT0 (UART0 rx), 400 is UTXEVT0 (UART0 tx) events.
But it is clear that my theory was not even close to what's going on.
Do you have some tool which can be used to reproduce this issue?
The latest uart patch set is at
* Peter Hurley | 2014-09-23 13:03:51 [-0400]:
readline() does this; it 'saves' the caller's termios, sets termios
for non-canonical reads, reads one char, and 'restores' the caller's
termios.
interresting, thanks. I guess I would need to opimize this a little so
the baudrate isn't going to 0 and
* Frans Klaver | 2014-09-22 11:28:54 [+0200]:
Wow, thanks for your work here. This does indeed sound hard to trap.
I guess then we'd still have to answer the question why the yocto build
calls set_termios() so often, but that's not on you then. Did you notice
it even changing settings? We might
* Frans Klaver | 2014-09-17 12:28:12 [+0200]:
- Bone Black: Yocto poky, core-image-minimal
Login, less file locks up, doesn't show anything. I can exit using
Ctrl-C.
So I have the same with my and the serial-omap driver. No difference
here. The trace looks like this:
| idle-0
1 - 100 of 434 matches
Mail list logo
