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 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
observed in practice.
Cc: Sebastian Andrzej Siewior
Signed-off-by: Peter Hurley
---
drivers/tty/serial/8250/8250_core.c | 12 +++-
drivers/tty/serial/8250/8250_omap.c | 25 ++---
include/linux/serial_8250.h | 1 +
include/linux/serial_core.h | 1 +
4
of RTS after port has been shutdown; omap_8250_pm() re-enabled
RTS after omap_8250_shutdown().
Cc: Sebastian Andrzej Siewior
Signed-off-by: Peter Hurley
---
drivers/tty/serial/8250/8250_omap.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/seri
to disable phantom port
registration; ie., CONFIG_SERIAL_8250_PHANTOM_UARTS=N only registers
probed ports (ACPI/PNP, "serial8250" platform devices, PCI, etc).
Cc: Sebastian Andrzej Siewior
Cc: Tony Lindgren
Cc: Grant Likely
Cc: Arnd Bergmann
Signed-off-by: Peter Hurley
---
drivers/
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-
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 p
On 01/08/2015 08:10 AM, One Thousand Gnomes wrote:
> On Mon, 5 Jan 2015 22:09:45 -0500
> 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
.dev_name = "ttyS",
./drivers/tty/serial/dz.c: .dev_name = "ttyS",
./drivers/tty/serial/sunhv.c: .dev_name = "ttyS",
./drivers/s390/char/sclp_vt220.c:#define SCLP_VT220_CONSOLE_NAME
"ttyS"
./drivers/
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-driv
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
s no longer required 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: Remov
workaround UART driver bugs.
Cc: Marcel Holtmann
Cc: Johan Hedberg
Cc:
Signed-off-by: Peter Hurley
---
drivers/bluetooth/hci_ath.c | 15 ++-
drivers/tty/tty_ioctl.c | 3 +--
include/linux/tty.h | 1 -
3 files changed, 3 insertions(+), 16 deletions(-)
diff --git a
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
---
drivers
ter, use the UPSTAT_* mode to determine if
autoRTS should be enabled when raising RTS (in omap8250_set_mctrl()).
Signed-off-by: Peter Hurley
---
drivers/tty/serial/8250/8250_omap.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_o
OFT_FLOW as capabilities; re-define
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
---
drivers/tty/serial/8250/8250_omap.c
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 are using the second UART multiplexed on mpps 15 and 16.
>
> Reverting this particular patch fixes the issue.
>
> We are seing the p
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 message
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 02/11/2015 03:03 PM, Tony Lindgren wrote:
> * Peter Hurley [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:
>>>>>
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?
>>
>>
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
>> &l
ts of userspace breakage.
Regards,
Peter Hurley
> Signed-off-by: Nishanth Menon
> ---
> 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
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
t; status = "okay";
> };
>
> +&gpio1 {
> + status = "okay";
> +};
> +
> &gpio3 {
> status = "okay";
> };
> @@ -468,6 +545,43 @@
> cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
>
gt; commit ca8bb4aefb9 ("serial: 8250: Revert "tty: serial: 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
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
---
drivers/tty
call 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.
o care of other
> quirks 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 Hurle
date into helper function, omap8250_update_mdr1().
[1] Advisory 21 in http://www.ti.com/lit/er/sprz408b/sprz408b.pdf
Regards,
Peter Hurley
> Signed-off-by: Sekhar Nori
> ---
> drivers/tty/serial/8250/8250_omap.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff
udelay(1);
> + syss = serial_in(up, UART_OMAP_SYSS);
> + } while (--timeout && !(syss & OMAP_UART_SYSS_RESETDONE));
If there is not a omap helper function to reset modules, there should be.
Open-coding the module reset is not appropriate.
> + if (!timeout) {
> +
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;
>>&
process
> of updating 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap
() function, which cannot perform the write 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
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
> Signe
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:
>>
>>
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().
Regards,
Peter Hurley
> + }
> +
> /*
>* Disable break condition and FIFOs
>*/
>
--
To unsubscribe from this
[ +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 t
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/s
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
&
iting until the transfer completes would be simpler but it
> is not necessarily high priority.
I agree; this is what we should do first because someone 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
; data loss implications.
Thanks for adding your hard-won knowledge to this discussion, 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 "unsub
8250 will go back to using non-DMA mode -
> which is the situation which existed prior to the change which coupled the
> two drivers together. That's an acceptable change for -stable trees,
> because it's reverting the change which caused the regression, taking us
> back to a
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 c
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:
>>>> [
[ + 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:
>>>> [
cal functionality is missing?
Even dma_get_slave_caps() returns _true_ for cmd_pause support; ok, that
interface is pointless.
Rather than losing /critical data/ here, the interrupt handler should just
busy-wait until dmaengine_tx_status() returns DMA_COMPLETE for the rx_cookie.
Regards,
ering there are
fewer than 20 users of dmaengine_pause() in the entire tree, we should add
WARN_ON_ONCE() 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
types of pause support, but I don't think that's required.
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&
>
> Tested-by: Sekhar Nori
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/majordomo-info.html
6 so I think 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 Hurle
ed that I forgot to
right, but that's unnecessary. You can pm_runtime_get() every time
start_tx() is called. Just make sure to put 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 on
: OMAP: use a 1-byte RX FIFO
> threshold in PIO mode :)
That commit looks like it should have been specific to the silicon
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
ult is the following:
> + * - RX_TRIGGER amount of bytes in the FIFO will cause an interrupt.
> + * - less than RX_TRIGGER number of bytes will also cause an interrupt
> + * once the UART decides that there no new bytes arriving.
> + * - Once THRE is enabled, the
ps 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
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 f
t option 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 sendi
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
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, w
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 ru
ourage
unnecessary code variation in the 8250 driver. The inertia of an
omap-specific irq handler will mean 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
integr
.
> If I delay the restore_registers part of set_termios() until TX-DMA is
> complete then it seems that the TX-DMA stall does not tall anymore.
The tty core calls the driver's wait_until_sent() method 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 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 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
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
>>> t
s already gone.
>
> Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: 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
be dropped.
> - the RX- and TX-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
--
To unsubscribe from this list: send
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
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
> 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 11:25 AM, Rus
t; is dealing with the stack.
>>
>> I think the only viable solution here is that:
>>
>> 1. We blacklist the bad compiler versions outright in the kernel.
>
> Yes, please do this, it's what we have done for other buggy compiler
> versions, no need to do some
compilers: 3.3
> +#errorKnown good compilers: 3.3, 4.x
> +#endif
> +#if GCC_VERSION >= 40800 || GCC_VERSION < 40803
^^
&&
> +#error Your compiler is too buggy; it is known to miscompile kernels
> +#error a
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.
stop 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 bo
ill deadlock.
Reviewed-by: Peter Hurley
Reported-by: Huang Shijie
Signed-off-by: Felipe Balbi
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,
You may want to buil
k functions already (so don't
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 mes
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 [140320 12:39]:
This reverts commit 0324a821029e1f54e7a7f8fed48693cfce42dc0e.
That commit tried to fix a deadlock
On 03/25/2014 02:28 PM, Tony Lindgren wrote:
* Felipe Balbi [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 ->write() from wi
76 matches
Mail list logo
