dropping them
is the only option. I also increase the buf_overrun counter so userpace
has a clue that we lost bytes.
No objection to the patch but I'm curious whether this is something you've
actually observed and under what circumstances.
Regards,
Peter Hurley
Cc: Greg Kroah-Hartman gre
-by: Sekhar Nori nsek...@ti.com
Already in Greg's tty-next tree (and 4.3-rc1 pull request), Sekhar.
Regards,
Peter Hurley
--
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
.
As Sebastian's omap-dma driver patch shows, partial pause support has more
to do with how it's being used.
Regards,
Peter Hurley
--
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
, Russell.
This saves us a bunch of wasted effort trying to fix x_char with DMA
(and TCSANOW termios changes and throttling).
Regards,
Peter Hurley
--
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
On 08/07/2015 11:29 AM, 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
On 08/07/2015 12:39 PM, Russell King - ARM Linux wrote:
On Fri, Aug 07, 2015 at 05:44:03PM +0200, Sebastian Andrzej Siewior wrote:
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
[ + Heikki ]
On 08/07/2015 12:33 PM, Russell King - ARM Linux wrote:
On Fri, Aug 07, 2015 at 12:07:11PM -0400, Peter Hurley wrote:
On 08/07/2015 11:29 AM, 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
us
back to a situation we _know_ worked previously.
What you're suggesting here is only possible if the entire 8250_omap driver
is removed, so that's a non-starter.
I suggest to wait on any solution until the correct fix is mainlined
and backported, as you note below.
Regards,
Peter Hurley
handler should just
busy-wait until dmaengine_tx_status() returns DMA_COMPLETE for the rx_cookie.
Regards,
Peter Hurley
spin_unlock_irqrestore(priv-rx_dma_lock, flags);
@@ -813,6 +817,9 @@ static int omap_8250_rx_dma(struct uart_8250_port *p,
unsigned int iir)
break
() around those uses with this patch to avoid a bunch needless
one-off fixes.
Regards,
Peter Hurley
--
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 08/07/2015 02:32 PM, Russell King - ARM Linux wrote:
On Fri, Aug 07, 2015 at 02:21:59PM -0400, Peter Hurley wrote:
[ + Heikki ]
On 08/07/2015 12:33 PM, Russell King - ARM Linux wrote:
What you have is a race condition in the code you a responsible for
maintaining, caused by poorly
Hi Sebastian,
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? That way I could
move the termios_wait into the dma
might want it
for backports.
Regards,
Peter Hurley
--
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
[ +cc Heikki ]
Hi Sebastian,
On 08/03/2015 12:09 PM, Sebastian Andrzej Siewior wrote:
* 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
On 08/03/2015 12:54 PM, Sebastian Andrzej Siewior wrote:
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
On 07/30/2015 07:15 PM, Peter Hurley wrote:
On 07/30/2015 06:54 PM, John Ogness wrote:
uart_write_wakeup() should be called without holding the port lock.
Otherwise a possible recursive spinlock issue can occur, such as
the following callchain:
8250_core.c:serial8250_tx_chars() - called
synchronously.
This is a common line discipline bug, and typically fixed by performing
the wakeup operations from a kworker instead.
Regards,
Peter Hurley
--
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
to
complete in omap_8250_set_termios().
Regards,
Peter Hurley
+ }
+
/*
* Disable break condition and FIFOs
*/
--
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
On 07/30/2015 06:54 PM, John Ogness wrote:
That bitfield is modified by read + or + write operation. If someone
sets any of the other two bits it might render the lock useless.
Good catch.
Let's just make all of the fields not bitfield though.
Regards,
Peter Hurley
Signed-off-by: John Ogness
the errata documents of those devices as well.
Patch 1/7 fixes a related bug but can be applied independently.
Looks good. Thanks Sekhar!
For series,
Reviewed-by: Peter Hurley pe...@hurleysoftware.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
On 07/09/2015 10:15 AM, Sekhar Nori wrote:
On Thursday 09 July 2015 07:03 AM, Peter Hurley wrote:
[...]
@@ -1307,6 +1320,36 @@ static int omap8250_runtime_suspend(struct device
*dev)
return -EBUSY;
}
+ if (priv-habit UART_ERRATA_CLOCK_DISABLE
the runtime
callbacks after the system pm callbacks?
Whatever positive it brings, it's a mess at the driver level.
For example, this driver has to hook prepare()/complete() so it can
set local state so that it can detect when the runtime suspend
is being called during system suspend.
Regards,
Peter
().
[1] Advisory 21 in http://www.ti.com/lit/er/sprz408b/sprz408b.pdf
Regards,
Peter Hurley
Signed-off-by: Sekhar Nori nsek...@ti.com
---
drivers/tty/serial/8250/8250_omap.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/8250
it.
+ */
+ if (device_may_wakeup(dev))
+ omap8250_update_mdr1(up, priv);
Should this be unconditional?
Regards,
Peter Hurley
+ }
+
if (up-dma up-dma-rxchan)
omap_8250_rx_dma(up, UART_IIR_RX_TIMEOUT);
--
To unsubscribe from this list: send
specific to AM335x and like SoCs.
This patch does break backward DTB compatibility for users of
8250_omap driver on AM335x boards.
Not ok.
8250_omap was released with 3.19 and has been the default driver for
BeagleBone since 4.0.
Regards,
Peter Hurley
However, the 8250_omap driver
is new
OMAP h/w-assisted IXON flow control is borked. The transmitter becomes
stuck if XON is never received; clearing the fifos or resetting the
rx flow control bits has no effect.
Remove auto-IXANY as well, since without auto-IXON, it has no purpose.
Signed-off-by: Peter Hurley pe
: 8250_core: read
only RX if there is something in the FIFO).
This is the second attempt to get it to work on older OMAPs without
breaking other chips this time
Peter Hurley suggested to pull in the few needed lines from
serial8250_do_startup() and drop everything else that is not required
including
the wilink8 module is the only thing that can be plugged
into the camera header?
I think all this really needs to go into a DT overlay.
Regards,
Peter Hurley
+ cap-power-off-card;
+ keep-power-in-suspend;
+ ti,non-removable;
+
+ #address-cells = 1;
+ #size-cells = 0
On 04/11/2015 02:27 PM, Nishanth Menon wrote:
On 04/10/2015 02:40 PM, Peter Hurley wrote:
[ +Sebastian, +Tony ]
On 04/10/2015 02:18 PM, Nishanth Menon wrote:
8250 driver should be relatively feature complete. It can co-exist
with omap-serial driver
Not really; if the omap_8250 is selected
.
Regards,
Peter Hurley
Signed-off-by: Nishanth Menon n...@ti.com
---
Current upstream next-20150410 status: (all boards pass without this patch)
Test is a basic boot test (using omap2plus_defconfig ofcourse)..
Ofcourse:
[0.001035] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0
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 is probably
10 loc.
10 loc? I have a few more
On 02/12/2015 03:45 AM, Sebastian Andrzej Siewior wrote:
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
On 02/10/2015 12:46 PM, Peter Hurley wrote:
On 02/10/2015 07:04 AM, Nicolas Schichan wrote:
On 02/10/2015 12:34 AM, Peter Hurley wrote:
Hi Nicolas,
Thanks for the report.
[...]
When a caracter is received on the UART while the kernel is printing
the boot messages, as soon as the kernel
On 02/11/2015 03:03 PM, Tony Lindgren wrote:
* Peter Hurley pe...@hurleysoftware.com [150211 12:05]:
On 02/10/2015 12:46 PM, Peter Hurley wrote:
On 02/10/2015 07:04 AM, Nicolas Schichan wrote:
On 02/10/2015 12:34 AM, Peter Hurley wrote:
Hi Nicolas,
Thanks for the report.
[...]
When
On 02/10/2015 07:04 AM, Nicolas Schichan wrote:
On 02/10/2015 12:34 AM, Peter Hurley wrote:
Hi Nicolas,
Thanks for the report.
[...]
When a caracter is received on the UART while the kernel is printing
the boot messages, as soon as the kernel configures the UART for
receiving (after root
() is returning 0,
ie., not handled. Which in turn means IIR indicates no interrupt is pending
(UART_IIR_NO_INT == 1).
Can you log the register values for LSR and IIR at both patch locations
in serial8250_do_startup()?
(I can get you a debug patch, if necessary. Let me know)
Regards,
Peter Hurley
We
UPF_HARD_FLOW as both UPF_AUTO_RTS and UPF_AUTO_CTS to allow for distinct
and separate rx and tx flow control capabilities.
Disable sw-assisted CTS flow control when UPSTAT_AUTOCTS is enabled.
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
drivers/tty/serial/8250/8250_omap.c | 7
now that the offending in-tree driver,
omap-serial, properly drives RTS in autoRTS mode.
Regards,
Peter Hurley (4):
serial: core: Rework hw-assisted flow control support
serial: 8250_omap: Use UPSTAT_AUTORTS for RTS handling
serial: omap: Fix RTS handling
tty: Remove external interface
to workaround UART driver bugs.
Cc: Marcel Holtmann mar...@holtmann.org
Cc: Johan Hedberg johan.hedb...@gmail.com
Cc: linux-blueto...@vger.kernel.org
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
drivers/bluetooth/hci_ath.c | 15 ++-
drivers/tty/tty_ioctl.c | 3 +--
include
The OMAP UART ignores MCR[1] (ie., RTS) when in autoRTS mode. This
makes it impossible for either the serial core or userspace to
manually flow control the sender.
Disable autoRTS mode when RTS is lowered and restore the previous
mode when RTS is raised.
Signed-off-by: Peter Hurley pe
* mode to determine if
autoRTS should be enabled when raising RTS (in omap8250_set_mctrl()).
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
drivers/tty/serial/8250/8250_omap.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/8250
On 01/09/2015 03:48 AM, Arnd Bergmann wrote:
On Friday 09 January 2015 00:13:28 Peter Hurley wrote:
On 01/08/2015 05:05 PM, Arnd Bergmann wrote:
On Thursday 08 January 2015 11:11:51 Peter Hurley wrote:
This interface is just storage and minor allocation, since the
port-reuse behavior
systemd/udev)
This doesn't address pre-init.
Regards,
Peter Hurley
--
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 01/08/2015 05:05 PM, Arnd Bergmann wrote:
On Thursday 08 January 2015 11:11:51 Peter Hurley wrote:
This interface is just storage and minor allocation, since the
port-reuse behavior will be limited to the universal driver.
From a sub-driver perspective, the shared storage is actually
On 01/08/2015 08:10 AM, One Thousand Gnomes wrote:
On Mon, 5 Jan 2015 22:09:45 -0500
Peter Hurley pe...@hurleysoftware.com wrote:
Some arches have no need to create unprobed 8250 ports; these phantom
ports are primarily required for ISA ports which have no probe
mechanism or to provide non
On 01/06/2015 08:13 AM, Arnd Bergmann wrote:
On Monday 05 January 2015 22:09:45 Peter Hurley wrote:
Some arches have no need to create unprobed 8250 ports; these phantom
ports are primarily required for ISA ports which have no probe
mechanism or to provide non-operational ports for userspace
On 01/06/2015 02:43 PM, Arnd Bergmann wrote:
On Tuesday 06 January 2015 09:32:02 Peter Hurley wrote:
On 01/06/2015 08:13 AM, Arnd Bergmann wrote:
On Monday 05 January 2015 22:09:45 Peter Hurley wrote:
Some arches have no need to create unprobed 8250 ports; these phantom
ports are primarily
Bergmann a...@arndb.de
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
drivers/tty/serial/8250/8250.h | 6 ++
drivers/tty/serial/8250/8250_core.c | 13 +++--
drivers/tty/serial/8250/Kconfig | 24 +++-
3 files changed, 36 insertions(+), 7 deletions
port has been shutdown; omap_8250_pm() re-enabled
RTS after omap_8250_shutdown().
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
drivers/tty/serial/8250/8250_omap.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions
observed in practice.
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
drivers/tty/serial/8250/8250_core.c | 12 +++-
drivers/tty/serial/8250/8250_omap.c | 25 ++---
include/linux/serial_8250.h | 1
high).
I'm not sure if all the crashes were over ssh; I hadn't considered
the cpsw relevant until reading this. I'll retest over the serial console.
I have seen abrupt resets without messages on earlier kernels so perhaps
the commit is not the root cause.
Regards,
Peter Hurley
--
To unsubscribe
buggy; it is known to miscompile kernels
+#error and result in filesystem corruption and oopses.
+#endif
#endif
int main(void)
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
On 10/15/2014 08:18 PM, Russell King - ARM Linux wrote:
Hence why I recommend that Linaro takes down their buggy compiler.
Their 4.8.3 version should not be used *anywhere*, just the same as
the stock 4.8 to 4.8.2 inclusive should also not be used anywhere on
ARM either.
Completely agree.
--
have to write it myself?
I did on Friday (arm: Blacklist gcc 4.8.[012] ...) but Russell said he
was doing it himself.
Regards,
Peter Hurley
--
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
On 10/11/2014 10:51 AM, Otavio Salvador wrote:
Hello Russell,
On Sat, Oct 11, 2014 at 11:16 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sat, Oct 11, 2014 at 11:54:32AM +0800, Peter Chen wrote:
On Fri, Oct 10, 2014 at 08:44:33PM -0500, Nathan Lynch wrote:
On 10/10/2014
On 10/10/2014 09:44 PM, Nathan Lynch wrote:
On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
it seems that this has been known about for some time.)
Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x
-DMA callbacks are now OMAP-only and no bugs flags are
introduced into the generic DMA code. This also means that there is
custom IRQ routine in case of DMA.
For the series:
Reviewed-by: Peter Hurley pe...@hurleysoftware.com
--
To unsubscribe from this list: send the line unsubscribe linux
() is already gone.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
Reviewed-by: Peter Hurley pe...@hurleysoftware.com
--
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
On 09/25/2014 06:42 AM, Sebastian Andrzej Siewior wrote:
* 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
before changing
the termios (if TCSADRAIN is used for tcsetattr(), which I think for readline()
it does).
But DMA is cheating if the UART driver's tx_empty() method is saying the
transmitter is empty while TX DMA is still running.
Regards,
Peter Hurley
--
To unsubscribe from this list: send
On 09/23/2014 04:24 AM, Frans Klaver wrote:
On Wed, Sep 17, 2014 at 02:13:03PM +0200, Frans Klaver wrote:
On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
On 09/16/2014 04:50 AM, Frans Klaver wrote:
On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
On 09/15/2014 11:39
it will probable stay forever. Suppose
this tx dma bug is later discovered to be fixable inline (rather than by
state), then we'll be stuck with an irq handler that no one will want to
integrate.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
On 09/16/2014 04:50 AM, Frans Klaver wrote:
On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
On 09/15/2014 11:39 AM, Peter Hurley wrote:
On 09/15/2014 10:00 AM, Frans Klaver wrote:
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within
On 09/16/2014 12:55 PM, Sebastian Andrzej Siewior wrote:
On 09/15/2014 07:01 PM, Sebastian Andrzej Siewior wrote:
On 09/11/2014 04:35 PM, Peter Hurley wrote:
I do need to find out if omap hardware sets UART_MSR_DCTS when auto CTS
is on. Would you mind running the debug patch below with HW flow
not sufficient?
Or conversely, shouldn't this be selectable?
Regards,
Peter Hurley
PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
latency in excess of 250us?
In practice this therefore reduces the need for hardware flow control,
meaning the sending side doesn't have to buffer
On 09/15/2014 11:39 AM, Peter Hurley wrote:
On 09/15/2014 10:00 AM, Frans Klaver wrote:
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling
reduces
this to about 170 overflows in 10 minutes.
Why
-mcr |= UART_MCR_RTS;
+ }
+
+ if (up-port.flags UPF_SOFT_FLOW) {
I'm aware that this is basically from the omap driver but can someone clear
up if omap hardware can actually do UPF_HARD_FLOW and UPF_SOFT_FLOW
simultaneously? The datasheets that I've looked at say no.
Regards,
Peter Hurley
the hardware
is being stopped by uart_handle_cts_change() when auto CTS is on?
Regards,
Peter Hurley
[The UPF_HARD_FLOW thing was pretty much just done for omap even though
8250 already had auto CTS/auto RTS. Serial core hardware flow control support
needs a redo as drivers have pretty much tacked stuff
On 09/11/2014 08:50 AM, Sebastian Andrzej Siewior wrote:
On 09/11/2014 02:32 PM, Peter Hurley wrote:
On 09/11/2014 07:42 AM, Sebastian Andrzej Siewior wrote:
I also need a watchdog timer for TX since it seems that on omap3 the
DMA engine suddenly forgets to continue with DMA…
One difference
exhibiting the rx timeout bug.
Regards,
Peter Hurley
--
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
everytime stop_tx() is
called too.
The interface is asymmetric.
start_tx() may be invoked multiple times for which only 1 interrupt
will occur, and thus only invoke __stop_tx() once.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
to be called also after each character.
The 8250 core auto-stops tx when the tx ring buffer is empty (except
in the case of dma, where stopping tx isn't necessary).
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
-by: Peter Hurley pe...@hurleysoftware.com
Reported-by: Huang Shijie b32...@freescale.com
Signed-off-by: Felipe Balbi ba...@ti.com
I just noticed this patch wasn't addressed to Marcel;
seems like this should go through the bluetooth tree (but not
through bluetooth-next because it fixes an oops).
Marcel
need to schedule another work...)
I don't think that should be part of $subject, though.
I don't understand what you mean here.
Regards,
Peter Hurley
--
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
On 03/26/2014 10:10 PM, Felipe Balbi wrote:
Hi,
On Wed, Mar 26, 2014 at 08:39:11PM -0400, Peter Hurley wrote:
On 03/25/2014 02:28 PM, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [140320 12:39]:
This reverts commit 0324a821029e1f54e7a7f8fed48693cfce42dc0e.
That commit tried to fix
On 03/25/2014 02:28 PM, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [140320 12:39]:
This reverts commit 0324a821029e1f54e7a7f8fed48693cfce42dc0e.
That commit tried to fix a deadlock problem when using
hci_ldisc, but it turns out the bug was in hci_ldsic
all along where it was calling
76 matches
Mail list logo
