* Re: [PATCH v2 3/7] soc: qcom: Add GENI based QUP Wrapper driver
From: Karthik Ramasubramanian @ 2018-01-31 19:02 UTC (permalink / raw)
To: Rob Herring, Bjorn Andersson
Cc: Rajendra Nayak, corbet, andy.gross, david.brown, mark.rutland,
wsa, gregkh, linux-doc, linux-arm-msm, devicetree, linux-i2c,
linux-serial, jslaby, Sagar Dharia, Girish Mahadevan
In-Reply-To: <20180119225708.4mo6fiy5zyd6kscj@rob-hp-laptop>
On 1/19/2018 3:57 PM, Rob Herring wrote:
> On Thu, Jan 18, 2018 at 08:57:45AM -0800, Bjorn Andersson wrote:
>> On Thu 18 Jan 01:13 PST 2018, Rajendra Nayak wrote:
>>
>>> []..
>>>
>>>>> diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
>>>>> new file mode 100644
>>>>> index 0000000..3f43582
>>>>> --- /dev/null
>>>>> +++ b/drivers/soc/qcom/qcom-geni-se.c
>>>>> @@ -0,0 +1,1016 @@
>>>>> +/*
>>>>> + * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
>>>>> + *
>>>>> + * This program is free software; you can redistribute it and/or modify
>>>>> + * it under the terms of the GNU General Public License version 2 and
>>>>> + * only version 2 as published by the Free Software Foundation.
>>>>> + *
>>>>> + * This program is distributed in the hope that it will be useful,
>>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>>> + * GNU General Public License for more details.
>>>>> + *
>>>>> + */
>>>>
>>>> Please use SPDX style license header, i.e. this file should start with:
>>>>
>>>> // SPDX-License-Identifier: GPL-2.0
>>>> /*
>>>> * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
>>>> */
>>>
>>> Looks like Mark Brown commented elsewhere [1] that we should use the C++
>>> commenting style even for the Linux Foundation copyright?
>>>
>>> [1] https://marc.info/?l=linux-clk&m=151497978626135&w=2
>>>
>>
>> While I can agree with Mark on the ugliness of the mixed commenting
>> style, this is the style that I found communicated and is what you find
>> in other files.
>
> Well, that's pretty new guidance. Moving target...
>
> Given that Linus said '//' comments are the only thing C++ got right, I
> expect to see more of them.
I believe that in the source file I have to use C++ style comments(as
per this discussion) and in the header file I have to use C-style
comments (as per https://lwn.net/Articles/739183/ for reasons related to
tooling). Please correct me otherwise.
>
> Rob
>
Regards,
Karthik.
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [GIT PULL] TTY/Serial patches for 4.16-rc1
From: Greg KH @ 2018-02-01 11:07 UTC (permalink / raw)
To: Linus Torvalds, Jiri Slaby
Cc: Stephen Rothwell, Andrew Morton, linux-kernel, linux-serial
The following changes since commit 30a7acd573899fd8b8ac39236eff6468b195ac7d:
Linux 4.15-rc6 (2017-12-31 14:47:43 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-4.16-rc1
for you to fetch changes up to c7e1b4059075c9e8eed101d7cc5da43e95eb5e18:
tty: serial: exar: Relocate sleep wake-up handling (2018-01-25 12:44:50 +0100)
----------------------------------------------------------------
TTY/Staging driver updates for 4.16-rc1
Here is the big tty/serial driver update for 4.16-rc1.
The usual number of various serial driver fixes and updates to try to
get them to work with crazy hardware configurations (seriously, how many
different ways are hardware engineers going to come up with to hook up a
simple UART?)
There is also some serdev bugfixes and updates, as well as a smattering
of other small fixes in here.
All have been in the linux-next tree for a while, with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Aaron Sierra (1):
tty: serial: exar: Relocate sleep wake-up handling
Andrey Smirnov (2):
serdev: Make .remove in struct serdev_device_driver optional
serdev: Introduce devm_serdev_device_open()
Andy Shevchenko (2):
MAINTAINERS: Add myself as designated reviewer for 8250_dw
serial: 8250_dw: Revert "Improve clock rate setting"
Branislav Radocaj (1):
tty: serial: mxs-auart: fix error handling in mxs_auart_probe
Christian Borntraeger (1):
serial: forbid 8250 on s390
Colin Ian King (1):
tty: n_gsm: remove redundant pointer gsm
Fabio Estevam (2):
dt-bindings: serial: fsl-imx-uart: Remove 'fsl,irda-mode' property
serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTS
Gaurav Kohli (1):
tty: fix data race between tty_init_dev and flush of buf
Geert Uytterhoeven (5):
tty: serial: sh-sci: Hide number of ports config question
tty: serial: sh-sci: Hide serial console config question
tty: serial: sh-sci: Hide earlycon config question
tty: serial: sh-sci: Hide DMA config question
tty: serial: sh-sci: Add default for number of ports for compile-testing
Greg Kroah-Hartman (2):
Merge 4.15-rc3 into tty-next
Merge 4.15-rc6 into tty-next
Guilherme G. Piccoli (2):
tty: serial: jsm: Remove unnecessary NULL checks
tty: serial: jsm: Add one check against NULL pointer dereference
Gustavo A. R. Silva (1):
tty: vt: replace _manual_ swap with swap macro in set_selection
Hans de Goede (1):
serdev: Fix serdev_uevent failure on ACPI enumerated serdev-controllers
Jan Kundrát (9):
serial: max310x: Fix invalid memory access during GPIO init
serial: max310x: Do not hard-code the IRQ type
serial: max310x: Use level-triggered interrupts
serial: max310x: Support IRQ sharing with other devices
serial: max310x: Document clock setup
serial: max310x: use a batch write op for UART transmit
serial: max310x: Use batched reads when reasonably safe
serial: max310x: Reduce RX work starvation
gpio: serial: max310x: Support open-drain configuration for GPIOs
Jia-Ju Bai (1):
tty/isicom: Fix a possible sleep-in-atomic bug in WaitTillCardIsFree
Johan Hovold (6):
serdev: document driver callbacks
serdev: ttyport: release tty lock sooner on open
serdev: ttyport: ignore carrier detect to avoid hangups
serdev: ttyport: do not used keyed wakeup in write_wakeup
serdev: do not generate modaliases for controllers
serdev: only match serdev devices
Lars Kanis (1):
tty: moxa: Add support for CMSPAR
Ludovic Barre (1):
serial: stm32: fix name conflict with 8250
Lukas Wunner (7):
serial: pl011: Drop duplicate loop counter
serial: pl011: Use cached copy of IMSC register
serial: Make retrieval of rs485 properties platform-agnostic
dt-bindings: serial: Add common rs485 binding for RTS polarity
serial: core: Support common rs485 binding for RTS polarity
serial: fsl_lpuart: Support common rs485 binding for RTS polarity
serial: imx: Support common rs485 binding for RTS polarity
Martin Blumenstingl (4):
tty: serial: meson: remove duplicate "clear error" bit definition
tty: serial: meson: merge the two register sections for AML_UART_CONTROL
tty: serial: meson: fix typo in the "stop bit" register definition
nvmem: meson-mx-efuse: fix reading from an offset other than 0
Martin Kaiser (1):
serial: imx: fix endless loop during suspend
Masahiro Yamada (1):
serial: 8250_of: fix return code when probe function fails to get reset
Miquel Raynal (1):
dt-bindings: mvebu-uart: update documentation with extended UART
Paul Cercueil (3):
serial: core: Make uart_parse_options take const char* argument
serial: 8250_ingenic: Add support for the JZ4770 SoC
serial: 8250_ingenic: Parse earlycon options
Rafael Gago (1):
tty: omap-serial: Fix initial on-boot RTS GPIO level
Rolf Evers-Fischer (1):
serial: 8250: 8250_omap: Fix spelling error.
Sahara (1):
pty: cancel pty slave port buf's work in tty_release
Sebastian Andrzej Siewior (2):
tty: goldfish: Enable 'earlycon' only if built-in
serial: core: mark port as initialized after successful IRQ change
Stefan Potyra (1):
serial: 8250_dw: Disable clock on error
Tony Lindgren (1):
tty: n_gsm: Allow ADM response in addition to UA for control dlci
Troy Kisky (1):
tty: serial: imx: remove imx_disable_rx_int
Wei Yongjun (1):
serial: 8250_uniphier: fix error return code in uniphier_uart_probe()
Wolfram Sang (1):
serial: mxs-auart: don't use GPIOF_* with gpiod_get_direction
.../devicetree/bindings/serial/fsl-imx-uart.txt | 4 +-
.../devicetree/bindings/serial/fsl-lpuart.txt | 3 +-
.../devicetree/bindings/serial/ingenic,uart.txt | 8 +-
.../devicetree/bindings/serial/maxim,max310x.txt | 18 +-
.../devicetree/bindings/serial/mvebu-uart.txt | 50 +++-
.../devicetree/bindings/serial/omap_serial.txt | 1 +
Documentation/devicetree/bindings/serial/rs485.txt | 1 +
Documentation/driver-model/devres.txt | 3 +
MAINTAINERS | 5 +
drivers/tty/Kconfig | 6 +-
drivers/tty/goldfish.c | 2 +
drivers/tty/isicom.c | 6 +-
drivers/tty/moxa.c | 17 +-
drivers/tty/moxa.h | 2 +
drivers/tty/n_gsm.c | 19 +-
drivers/tty/serdev/core.c | 106 +++++---
drivers/tty/serdev/serdev-ttyport.c | 8 +-
drivers/tty/serial/8250/8250_dw.c | 33 ++-
drivers/tty/serial/8250/8250_exar.c | 34 ++-
drivers/tty/serial/8250/8250_ingenic.c | 17 +-
drivers/tty/serial/8250/8250_of.c | 5 +-
drivers/tty/serial/8250/8250_omap.c | 2 +-
drivers/tty/serial/8250/8250_port.c | 26 --
drivers/tty/serial/8250/8250_uniphier.c | 5 +-
drivers/tty/serial/8250/Kconfig | 1 +
drivers/tty/serial/Kconfig | 14 +-
drivers/tty/serial/amba-pl011.c | 12 +-
drivers/tty/serial/atmel_serial.c | 2 +-
drivers/tty/serial/fsl_lpuart.c | 15 +-
drivers/tty/serial/imx.c | 93 +++----
drivers/tty/serial/jsm/jsm_neo.c | 6 +-
drivers/tty/serial/jsm/jsm_tty.c | 6 -
drivers/tty/serial/max310x.c | 267 ++++++++++++++-------
drivers/tty/serial/meson_uart.c | 31 ++-
drivers/tty/serial/mxs-auart.c | 11 +-
drivers/tty/serial/omap-serial.c | 18 +-
drivers/tty/serial/serial_core.c | 35 ++-
drivers/tty/serial/stm32-usart.h | 2 +-
drivers/tty/tty_io.c | 10 +-
drivers/tty/tty_ldisc.c | 4 +-
drivers/tty/vt/selection.c | 6 +-
include/linux/serdev.h | 7 +-
include/linux/serial_core.h | 8 +-
include/linux/tty.h | 2 +
44 files changed, 579 insertions(+), 352 deletions(-)
^ permalink raw reply
* [PATCH] DT: serial: renesas,sci-serial: document R8A77980 bindings
From: Sergei Shtylyov @ 2018-02-01 19:36 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, linux-serial, devicetree
Cc: Mark Rutland, linux-renesas-soc
R-Car V3H (R8A77980) SoC has the R-Car gen3 compatible SCIF and HSCIF ports,
so document the SoC specific bindings.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++
1 file changed, 2 insertions(+)
Index: tty/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
===================================================================
--- tty.orig/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ tty/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -43,6 +43,8 @@ Required properties:
- "renesas,hscif-r8a7796" for R8A7796 (R-Car M3-W) HSCIF compatible UART.
- "renesas,scif-r8a77970" for R8A77970 (R-Car V3M) SCIF compatible UART.
- "renesas,hscif-r8a77970" for R8A77970 (R-Car V3M) HSCIF compatible UART.
+ - "renesas,scif-r8a77980" for R8A77980 (R-Car V3H) SCIF compatible UART.
+ - "renesas,hscif-r8a77980" for R8A77980 (R-Car V3H) HSCIF compatible UART.
- "renesas,scif-r8a77995" for R8A77995 (R-Car D3) SCIF compatible UART.
- "renesas,hscif-r8a77995" for R8A77995 (R-Car D3) HSCIF compatible UART.
- "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART.
^ permalink raw reply
* Re: [PATCH] DT: serial: renesas,sci-serial: document R8A77980 bindings
From: Sergei Shtylyov @ 2018-02-01 19:43 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2182bb59-d16f-54f0-d992-65b49815ce1d-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On 02/01/2018 10:36 PM, Sergei Shtylyov wrote:
> R-Car V3H (R8A77980) SoC has the R-Car gen3 compatible SCIF and HSCIF ports,
> so document the SoC specific bindings.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Forgot to mention that this patch is against the 'tty-next' branch of GregKH's 'tty.git' repo...
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] DT: serial: renesas,sci-serial: document R8A77980 bindings
From: Geert Uytterhoeven @ 2018-02-01 20:00 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Greg Kroah-Hartman, Rob Herring, linux-serial,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Mark Rutland, Linux-Renesas
In-Reply-To: <2182bb59-d16f-54f0-d992-65b49815ce1d@cogentembedded.com>
On Thu, Feb 1, 2018 at 8:36 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> R-Car V3H (R8A77980) SoC has the R-Car gen3 compatible SCIF and HSCIF ports,
> so document the SoC specific bindings.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] DT: serial: renesas,sci-serial: document R8A77980 bindings
From: Simon Horman @ 2018-02-02 8:47 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Greg Kroah-Hartman, Rob Herring,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2182bb59-d16f-54f0-d992-65b49815ce1d-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On Thu, Feb 01, 2018 at 10:36:20PM +0300, Sergei Shtylyov wrote:
> R-Car V3H (R8A77980) SoC has the R-Car gen3 compatible SCIF and HSCIF ports,
> so document the SoC specific bindings.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Reviewed-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [v3,2/2] ACPI / scan: Fix enumeration for special UART devices
From: Frédéric Danis @ 2018-02-02 10:03 UTC (permalink / raw)
To: Graeme Gregory
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, marcel-kz+m5ild9QBg9hUCZPvPmw,
sre-DgEjT+Ai2ygdnm+yROfE0A, loic.poulain-Re5JQEeQqe8AvxtiuMwx3w,
johan-DgEjT+Ai2ygdnm+yROfE0A, lukas-JFq808J9C/izQB+pC5nmwQ,
hdegoede-H+wXaHxf7aLQT0dZR+AlfA, rafael-DgEjT+Ai2ygdnm+yROfE0A,
greg-U8xfFu+wG4EAvxtiuMwx3w,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180131142100.GE26342@xora-haswell>
Hi Graeme,
Le 31/01/2018 à 15:21, Graeme Gregory a écrit :
> On Wed, Oct 11, 2017 at 10:32:14AM +0200, Frédéric Danis wrote:
>> UART devices is expected to be enumerated by SerDev subsystem.
>>
>> During ACPI scan, serial devices behind SPI, I2C or UART buses are not
>> enumerated, allowing them to be enumerated by their respective parents.
>>
>> Rename *spi_i2c_slave* to *serial_bus_slave* as this will be used for serial
>> devices on serial buses (SPI, I2C or UART).
>>
>> On Macs an empty ResourceTemplate is returned for uart slaves.
>> Instead the device properties "baud", "parity", "dataBits", "stopBits" are
>> provided. Add a check for "baud" in acpi_is_serial_bus_slave().
>>
> This patch appears to break UART probing in ACPI on xgene based
> plaforms.
>
> The appropriate chunks of DSDT.
>
> Device (_SB.AHBC)
> {
> OperationRegion (SRST, SystemMemory, 0x1F2AC000, 0x04)
> OperationRegion (CLKE, SystemMemory, 0x1F2AC004, 0x04)
> OperationRegion (SRRM, SystemMemory, 0x1F2AD070, 0x04)
> OperationRegion (RD2F, SystemMemory, 0x1F2AE014, 0x04)
>
> ...
>
> Device (UAR0)
> {
> Name (_HID, "APMC0D08") // _HID: Hardware ID
> Name (_DDN, "UAR0") // _DDN: DOS Device Name
> Name (_UID, "UAR0") // _UID: Unique ID
> Name (_STR, Unicode ("APM88xxxx UART0 Controller")) // _STR: Description String
> Name (_ADR, 0x1C021000) // _ADR: Address
> Name (_CID, "NS16550A") // _CID: Compatible ID
>
> ...
>
> Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
> {
> Memory32Fixed (ReadWrite,
> 0x1C021000, // Address Base
> 0x00000100, // Address Length
> )
> UartSerialBusV2 (0x00002580, DataBitsEight, StopBitsOne,
> 0x00, LittleEndian, ParityTypeNone, FlowControlHardware,
> 0x0010, 0x0010, "UAR0",
> 0x00, ResourceConsumer, , Exclusive,
> )
> Interrupt (ResourceProducer, Level, ActiveHigh, Exclusive, ,, )
> {
> 0x0000006D,
> }
> })
This seems to be related to
https://bugzilla.redhat.com/show_bug.cgi?id=1531140
Am I correct?
The SerDev support should allow UART to appear as tty device if not used
by an underlying component (cf. tty_port_register_device_attr() in
drivers/tty/tty_port.c).
AFAIU, there is no internal device attached to this serial port.
Is it possible to get complete ACPI DSDT?
Is SerDev enabled on this device?
Boot logs with SerDev debug traces enabled can be useful to understand
what happens.
Regards,
Fred
--
Frédéric Danis Embedded Linux Consultant
frederic.danis.oss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
^ permalink raw reply
* Re: MAX310X transfers usage in DMA mode
From: Jan Kundrát @ 2018-02-02 10:19 UTC (permalink / raw)
To: Gerlando Falauto
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CABMprFg5N_Qxj6No0P8fkBfY6goB2wh4Q=kawNyOi2XjdkyZ7w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On pátek 2. února 2018 10:25:09 CET, Gerlando Falauto wrote:
> I saw your patches about max310x and all the improvements you brought in to
> achieve
> burst transfers.
> My goal would be to push the chip to its limits (i.e. to 2.000.000bps) on a
> raspberry pi.
Hi Gerlando,
I'm happy that these patches help others as well :).
> I had already noticed the inefficiencies and tried something similar to
> your approach for burst transfers (but sticking to regmap).
I wonder how you did that? I looked at regmap, but it felt as if it wasn't
really possible to persuade regmap to just keep the SCLK line running for
batch-reading additional bytes from the same register (and just for
registers 0x00).
> In both cases
> (with or without regmap) it looks like the CPU is the bottleneck.
> I was thinking of using DMA and your approach looks just one step away from
> achieving this.
Regarding DMA, I have no clue how it works on RPi. I know that the SoC I
have has something similar, but it's severely limited and the kernel
doesn't really support it.
> Did you ever consider this?
Here's what I think should help get you a better performance:
1) Ensure that the userspace actually configures the UART in a mode which
enables batched reads (also known as "SPI burst access"). This is a big
catch. By default, reading each byte requires two SPI transactions, one for
reading one byte from the RX FIFO, and another one for the Line Status
Register. The HW does not support "batch reading" the RX buffer along with
the LSR, unfortunately. This means that by default, each byte received by
the UART requires at least four bytes to be transmitted over SPI.
However, if the userspace tells the kernel that it is not interested in
checking the BREAK condition, in determining RX parity errors, etc, then
the kernel can skip (and does skip, at least in the tty-next tree) the LSR
register. And because it's only reading from the RXFIFO, it can leverage
that SPI burst access.
Here's a snippet of my code which does that `termios` configuration:
m_config.c_iflag = IGNPAR;
m_config.c_oflag = 0;
m_config.c_cflag = CLOCAL | CREAD | CS8 | B115200;
m_config.c_lflag = 0;
m_config.c_cc[VMIN] = 0;
m_config.c_cc[VTIME] = 1;
2) Check the SPI frequency. The RPi's documentation suggests that there are
some limitations of the maximal SPI frequency. It's apparently a bit
coarse, with a big gap between 16MHz and 32MHz. The chip that I use is
spec'ed to allow up to 26MHz, which means 16MHz on your system.
3) We can also improve the RX FIFO utilization. My device has a 128B
buffer, and when I added some debugging code to produce a histogram of the
actual watermark level when reading the RX FIFO, I was surprised to see
plenty of small transfers. That's because the current driver prefers to
read from the RX buffer "ASAP", as soon as there's something in there.
The HW also allows another mode of operation where it only raises an IRQ
once either:
- more than X bytes are in the FIFO,
- or any byte in the FIFO has been there for more than Y "periods", where a
"period" is the time it takes the UART to transmit/receive one byte.
Doing that would make a lot of sense in this context. If we always read
after, say, 32 bytes are in the buffer (or upon a matching timeout), then
it's likely that we will do 32byte SPI transactions much more often. That
should reduce the SPI utilization when reading by (asymptotically) 50%.
I plan to (eventually) send a patch doing just that, but ENOTIME for now.
Hope this helps.
With kind regards,
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] serial: core: mark port as initialized in autoconfig
From: Sebastian Andrzej Siewior @ 2018-02-03 11:27 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Sebastian Andrzej Siewior,
Johan Hovold, Nikola Ciprich, stable
This is a followup on 44117a1d1732 ("serial: core: mark port as
initialized after successful IRQ change").
Nikola has been using autoconfig via setserial and reported a crash
similar to what I fixed in the earlier mentioned commit. Here I do the
same fixup for the autoconfig. I wasn't sure that this is the right
approach. Nikola confirmed that it fixes his crash.
Fixes: b3b576461864 ("tty: serial_core: convert uart_open to use tty_port_open")
Link: http://lkml.kernel.org/r/20180131072000.GD1853@localhost.localdomain
Reported-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
Tested-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
Cc: Johan Hovold <johan@kernel.org>
Cc: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/tty/serial/serial_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index c8dde56b532b..35b9201db3b4 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1144,6 +1144,8 @@ static int uart_do_autoconfig(struct tty_struct *tty,struct uart_state *state)
uport->ops->config_port(uport, flags);
ret = uart_startup(tty, state, 1);
+ if (ret == 0)
+ tty_port_set_initialized(port, true);
if (ret > 0)
ret = 0;
}
--
2.15.1
^ permalink raw reply related
* Re: [PATCH] serial: core: mark port as initialized in autoconfig
From: Nikola Ciprich @ 2018-02-03 11:52 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-serial, Greg Kroah-Hartman, Jiri Slaby, Johan Hovold,
stable, Nikola Ciprich
In-Reply-To: <20180203112723.11129-1-bigeasy@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 55 bytes --]
Tested-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] serial: core: mark port as initialized in autoconfig
From: Johan Hovold @ 2018-02-04 1:02 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-serial, Greg Kroah-Hartman, Jiri Slaby, Johan Hovold,
Nikola Ciprich, stable
In-Reply-To: <20180203112723.11129-1-bigeasy@linutronix.de>
On Sat, Feb 03, 2018 at 12:27:23PM +0100, Sebastian Andrzej Siewior wrote:
> This is a followup on 44117a1d1732 ("serial: core: mark port as
> initialized after successful IRQ change").
> Nikola has been using autoconfig via setserial and reported a crash
> similar to what I fixed in the earlier mentioned commit. Here I do the
> same fixup for the autoconfig. I wasn't sure that this is the right
> approach. Nikola confirmed that it fixes his crash.
>
> Fixes: b3b576461864 ("tty: serial_core: convert uart_open to use tty_port_open")
> Link: http://lkml.kernel.org/r/20180131072000.GD1853@localhost.localdomain
> Reported-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
> Tested-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
> Cc: Johan Hovold <johan@kernel.org>
> Cc: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Johan Hovold <johan@kernel.org>
^ permalink raw reply
* Re: [PATCH] DT: serial: renesas,sci-serial: document R8A77980 bindings
From: Rob Herring @ 2018-02-05 6:09 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Greg Kroah-Hartman, linux-serial, devicetree, Mark Rutland,
linux-renesas-soc
In-Reply-To: <2182bb59-d16f-54f0-d992-65b49815ce1d@cogentembedded.com>
On Thu, Feb 01, 2018 at 10:36:20PM +0300, Sergei Shtylyov wrote:
> R-Car V3H (R8A77980) SoC has the R-Car gen3 compatible SCIF and HSCIF ports,
> so document the SoC specific bindings.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] [PATCH] tty/serial: atmel: add new version check for usart
From: Nicolas Ferre @ 2018-02-05 12:36 UTC (permalink / raw)
To: Jonas Danielsson, linux-serial, Richard Genoud
Cc: Greg Kroah-Hartman, Alexandre Belloni, linux-arm-kernel,
Jiri Slaby
In-Reply-To: <20180129113954.12011-1-jonas@orbital-systems.com>
On 29/01/2018 at 12:39, Jonas Danielsson wrote:
> On our at91sam9260 based board the usart0 and usart1 ports report
> their versions (ATMEL_US_VERSION) as 0x10302. This version is not
> included in the current checks in the driver.
>
> Signed-off-by: Jonas Danielsson <jonas@orbital-systems.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
It must be the AT91SAM9260 rev. B SoC, isn't it?
Thanks for your patch.
Best regards,
Nicolas
> ---
> drivers/tty/serial/atmel_serial.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index efa25611ca0c..ae9f1dcbf3fc 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -1734,6 +1734,7 @@ static void atmel_get_ip_name(struct uart_port *port)
> switch (version) {
> case 0x302:
> case 0x10213:
> + case 0x10302:
> dev_dbg(port->dev, "This version is usart\n");
> atmel_port->has_frac_baudrate = true;
> atmel_port->has_hw_timer = true;
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] [PATCH] tty/serial: atmel: add new version check for usart
From: Jonas Danielsson @ 2018-02-05 14:04 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Richard Genoud, Greg Kroah-Hartman, Alexandre Belloni,
linux-serial, Jiri Slaby, linux-arm-kernel
In-Reply-To: <e20ced24-666b-32b7-92cd-d30e1a10b42e@microchip.com>
On Mon, Feb 5, 2018 at 1:36 PM, Nicolas Ferre
<nicolas.ferre@microchip.com> wrote:
> On 29/01/2018 at 12:39, Jonas Danielsson wrote:
>> On our at91sam9260 based board the usart0 and usart1 ports report
>> their versions (ATMEL_US_VERSION) as 0x10302. This version is not
>> included in the current checks in the driver.
>>
>> Signed-off-by: Jonas Danielsson <jonas@orbital-systems.com>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
>
> It must be the AT91SAM9260 rev. B SoC, isn't it?
>
> Thanks for your patch.
>
> Best regards,
> Nicolas
>
Hi Nicolas!
Thank you for the review!
Yes that is right, we have the rev B SoC :) I Tried to find some
documentation online
regarding the US_VERSION register, but fell short.
Allt the best
Jonas
^ permalink raw reply
* Re: [PATCH] [PATCH] tty/serial: atmel: add new version check for usart
From: Nicolas Ferre @ 2018-02-05 14:37 UTC (permalink / raw)
To: Jonas Danielsson
Cc: Richard Genoud, Greg Kroah-Hartman, Alexandre Belloni,
linux-serial, Jiri Slaby, linux-arm-kernel
In-Reply-To: <CALDOjziu=FBck-VSi=g=i8tcYWi_DQ_azzDnwKTkTuTrh54AkA@mail.gmail.com>
On 05/02/2018 at 15:04, Jonas Danielsson wrote:
> On Mon, Feb 5, 2018 at 1:36 PM, Nicolas Ferre
> <nicolas.ferre@microchip.com> wrote:
>> On 29/01/2018 at 12:39, Jonas Danielsson wrote:
>>> On our at91sam9260 based board the usart0 and usart1 ports report
>>> their versions (ATMEL_US_VERSION) as 0x10302. This version is not
>>> included in the current checks in the driver.
>>>
>>> Signed-off-by: Jonas Danielsson <jonas@orbital-systems.com>
>>
>> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
>>
>> It must be the AT91SAM9260 rev. B SoC, isn't it?
>>
>> Thanks for your patch.
>>
>> Best regards,
>> Nicolas
>>
>
> Hi Nicolas!
>
> Thank you for the review!
>
> Yes that is right, we have the rev B SoC :) I Tried to find some
> documentation online
> regarding the US_VERSION register, but fell short.
It's actually a non-documented register ;-)
In short, bits [0-11] Hardware module version
bits [16-18] Metal fix number.
So your at91sam9260 revB benefit from the metal fix #1.
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH v2 3/7] soc: qcom: Add GENI based QUP Wrapper driver
From: Bjorn Andersson @ 2018-02-05 23:50 UTC (permalink / raw)
To: Karthik Ramasubramanian
Cc: corbet, andy.gross, david.brown, robh+dt, mark.rutland, wsa,
gregkh, linux-doc, linux-arm-msm, devicetree, linux-i2c,
linux-serial, jslaby, Sagar Dharia, Girish Mahadevan
In-Reply-To: <1faee481-8cb6-4dc6-ac0f-eb89445227e1@codeaurora.org>
On Wed 31 Jan 10:58 PST 2018, Karthik Ramasubramanian wrote:
> On 1/16/2018 11:20 PM, Bjorn Andersson wrote:
> > On Fri 12 Jan 17:05 PST 2018, Karthikeyan Ramasubramanian wrote:
[..]
> > I'm not aware of any non-serial-engine "geni" at Qualcomm, so can we
> > drop the "se" throughout this driver?
> Currently GENI is used to program just the serial engines. But it is not
> restricted to that. It can be used to program other hardware cores. Hence
> keeping "se" will help to clarify that this driver is meant for GENI based
> serial engines only.
Okay, fair enough.
[..]
> > > diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
[..]
> > > + geni_cgc_ctrl = geni_read_reg(base, GENI_CGC_CTRL);
> > > + dma_general_cfg = geni_read_reg(base, SE_DMA_GENERAL_CFG);
> > > + geni_cgc_ctrl |= DEFAULT_CGC_EN;
> > > + dma_general_cfg |= (AHB_SEC_SLV_CLK_CGC_ON | DMA_AHB_SLV_CFG_ON |
> > > + DMA_TX_CLK_CGC_ON | DMA_RX_CLK_CGC_ON);
> >
> > Drop the parenthesis and there's no harm in making multiple assignments
> > in favour of splitting the line.
> Ok.
> >
> > > + io_op_ctrl = DEFAULT_IO_OUTPUT_CTRL_MSK;
> > > + geni_write_reg(geni_cgc_ctrl, base, GENI_CGC_CTRL);
> > > + geni_write_reg(dma_general_cfg, base, SE_DMA_GENERAL_CFG);
> >
> > Is there a reason why this chunk of code is a mix of 3 independent
> > register updates?
> I am not sure I understand the context of your question. This is how the
> hardware programming manual is describing to program the registers as part
> of initializing a serial engine. Please let me know if this is not the
> information you are looking for.
Can you please double check with the hardware guys if it really is
required that you do:
a = read(A)
b = read(B)
modify a
modify b
assign c
write(a)
write(b)
write(c)
And if that is the case, then try to make things as easy to read as
possible - e.g. by inlining the value of "c" and adding an empty line
between reads, modifications and writes as I did here.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v2 3/7] soc: qcom: Add GENI based QUP Wrapper driver
From: Bjorn Andersson @ 2018-02-05 23:53 UTC (permalink / raw)
To: Karthik Ramasubramanian
Cc: Rob Herring, Rajendra Nayak, corbet-T1hC0tSOHrs,
andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wsa-z923LK4zBo2bacvFa/9K2g,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA, jslaby-IBi9RG/b67k,
Sagar Dharia, Girish Mahadevan
In-Reply-To: <1abb0679-1997-9b70-30bd-d3472cea7053-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Wed 31 Jan 11:02 PST 2018, Karthik Ramasubramanian wrote:
> On 1/19/2018 3:57 PM, Rob Herring wrote:
> > On Thu, Jan 18, 2018 at 08:57:45AM -0800, Bjorn Andersson wrote:
> > > On Thu 18 Jan 01:13 PST 2018, Rajendra Nayak wrote:
[..]
> > > > >
> > > > > Please use SPDX style license header, i.e. this file should start with:
> > > > >
> > > > > // SPDX-License-Identifier: GPL-2.0
> > > > > /*
> > > > > * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
> > > > > */
> > > >
> > > > Looks like Mark Brown commented elsewhere [1] that we should use the C++
> > > > commenting style even for the Linux Foundation copyright?
> > > >
> > > > [1] https://marc.info/?l=linux-clk&m=151497978626135&w=2
> > > >
> > >
> > > While I can agree with Mark on the ugliness of the mixed commenting
> > > style, this is the style that I found communicated and is what you find
> > > in other files.
> >
> > Well, that's pretty new guidance. Moving target...
> >
> > Given that Linus said '//' comments are the only thing C++ got right, I
> > expect to see more of them.
> I believe that in the source file I have to use C++ style comments(as per
> this discussion) and in the header file I have to use C-style comments (as
> per https://lwn.net/Articles/739183/ for reasons related to tooling). Please
> correct me otherwise.
I had missed that detail, you're right.
Thanks,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 20/36] nds32: Signal handling support
From: Vincent Chen @ 2018-02-06 6:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime Hu, Greentime, Linux Kernel Mailing List, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
Networking, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial, Geert Uytterhoeven, Linus Walleij,
Mark Rutland, Greg KH, Guo Ren
In-Reply-To: <CAK8P3a0eeJKAOZjJ-XVQwLOCuVzSqdUtCaS4F90zZ=WvRQ8sBQ@mail.gmail.com>
Thanks, I got it.
After referring to arm64 and risc-v, we try to refine our code, such as
removing unneeded checking and refining syscall restart flow. We
hope these modifications can enhance the reliability and readability.
However, the following 2 files which you had acked are included in
this modification.
1. arch/nds32/include/asm/nds32.h
(patch: Assembly macros and definitions)
The definition of macro tbl and why are removed.
- Now, we use pt_reg->syscallno instead of 'why' to determine
whether entering kernel is via syscall or not. Therefore, macro
'why' is unneeded.
--- a/arch/nds32/include/asm/nds32.h
+++ b/arch/nds32/include/asm/nds32.h
@@ -66,10 +66,6 @@ static inline unsigned long CACHE_LINE_SIZE
#endif /* __ASSEMBLY__ */
-/* tbl and why is used in ex-scall.S and ex-exit.S */
-#define tbl $r8
-#define why $r8
-
#define IVB_BASE PHYS_OFFSET
2. arch/nds32/kernel/ex-scall.S (patch: System calls handling)
a. Define macro tbl
- The marco tbl is used only in this file. So, I move its definition
from arch/nds32/include/asm/nds32.h to here.
b. Remove 'set why = 0' when issuing syscall number is invalid
c. Adjust input arguments of syscall_trace_enter
--- a/arch/nds32/kernel/ex-scall.S
+++ b/arch/nds32/kernel/ex-scall.S
...
+#define tbl $r8
/*
* $r7 will be writen as syscall nr
- * by retrieving from $ITYPE 'SWID' bitfiled
*/
.macro get_scno
lwi $r7, [$sp + R15_OFFSET]
@@ -54,7 +49,6 @@ ENTRY(eh_syscall)
get_scno
gie_enable
-ENTRY(eh_syscall_phase_2)
lwi $p0, [tsk+#TSK_TI_FLAGS]
andi $p1, $p0, #_TIF_WORK_SYSCALL_ENTRY
@@ -71,7 +65,6 @@ jmp_systbl:
jr $p1 ! no return
_SCNO_EXCEED:
- movi why, 0
ori $r0, $r7, #0
ori $r1, $sp, #0
b bad_syscall
@@ -81,8 +74,7 @@ _SCNO_EXCEED:
* context switches, and waiting for our parent to respond.
*/
__sys_trace:
- move $r1, $sp
- move $r0, $r7 ! trace entry [IP = 0]
+ move $r0, $sp
bal syscall_trace_enter
move $r7, $r0
la $lp, __sys_trace_return ! return address
If you think these modifications in acked files are not permitted,
we will recover it.
We verify all modifications by LTP 2017 related cases and glibc
2.26 testsuite. We plan to add it in the next version patch and
hope you can give us some comments as before.
Thanks
Vincent
2018-01-24 19:13 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Wed, Jan 24, 2018 at 1:56 AM, Vincent Chen <deanbo422@gmail.com> wrote:
>> 2018-01-18 18:30 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>>> From: Greentime Hu <greentime@andestech.com>
>>>>
>>>> This patch adds support for signal handling.
>>>>
>>>> Signed-off-by: Vincent Chen <vincentc@andestech.com>
>>>> Signed-off-by: Greentime Hu <greentime@andestech.com>
>>>
>>> I never feel qualified enough to properly review signal handling code, so
>>> no Ack from me for this code even though I don't see anything wrong with it.
>>> Hopefully someone else can give an Ack after looking more closely.
>>>
>>
>> Dear Arnd:
>>
>> We'd be glad to improve signal handling code to meet your requirement.
>> Could you
>> tell us which part we need to refine or which implementation is good
>> for us to refer?
>
> No, as I said, the problem is on my side, I just don't understand enough of it.
> I would assume that the arm64 and risc-v implementations are the most
> thoroughly reviewed, but haven't looked at those in enough detail either.
> If your code does something that risc-v doesn't do, try to understand whether
> there should be a difference or not.
>
> Arnd
^ permalink raw reply
* Re: [PATCH v6 19/36] nds32: VDSO support
From: Vincent Chen @ 2018-02-06 7:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime Hu, Greentime, Linux Kernel Mailing List, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
Networking, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial, Geert Uytterhoeven, Linus Walleij,
Mark Rutland, Greg KH, Guo Ren
In-Reply-To: <CAK8P3a0GQDrj+7kc4YB1_ZC1vCWmMtSiYeKsNir_27FvY50Kmg@mail.gmail.com>
2018-01-18 18:28 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu@gmail.com> wrote:
>> From: Greentime Hu <greentime@andestech.com>
>>
>> This patch adds VDSO support. The VDSO code is currently used for
>> sys_rt_sigreturn() and optimised gettimeofday() (using the SoC timer counter).
>>
>> Signed-off-by: Vincent Chen <vincentc@andestech.com>
>> Signed-off-by: Greentime Hu <greentime@andestech.com>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Dear Arnd Bergmann:
We find a small bug here which make LTP 20170929 clock_getres01
fail. The bug is in __vdso_clock_getres() function. When argument res
is NULL, -EFAULT error code is returned now. But, the returned
value is 0 for SyS_clock_getres under the same conditions.
Therefore, testcase thinks it is a bug.
I will modify the code as below and add it in the next version patch
if you think it is OK.
@@ -209,7 +209,7 @@ static notrace int clock_getres_fallback( ...
{
if (res == NULL)
- return -EFAULT;
+ return 0;
Thanks
Vincnet
^ permalink raw reply
* Re: [PATCH v6 19/36] nds32: VDSO support
From: Arnd Bergmann @ 2018-02-06 8:48 UTC (permalink / raw)
To: Vincent Chen
Cc: Greentime Hu, Greentime, Linux Kernel Mailing List, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
Networking, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial, Geert Uytterhoeven, Linus Walleij,
Mark Rutland, Greg KH, Guo Ren
In-Reply-To: <CAJsyPhwHmMrXmN2-NW3ZyvRvTWR0vio_bQO+GDBf30DVp=5LTw@mail.gmail.com>
On Tue, Feb 6, 2018 at 8:41 AM, Vincent Chen <deanbo422@gmail.com> wrote:
> 2018-01-18 18:28 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>> From: Greentime Hu <greentime@andestech.com>
>>>
>>> This patch adds VDSO support. The VDSO code is currently used for
>>> sys_rt_sigreturn() and optimised gettimeofday() (using the SoC timer counter).
>>>
>>> Signed-off-by: Vincent Chen <vincentc@andestech.com>
>>> Signed-off-by: Greentime Hu <greentime@andestech.com>
>>
>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> Dear Arnd Bergmann:
>
> We find a small bug here which make LTP 20170929 clock_getres01
> fail. The bug is in __vdso_clock_getres() function. When argument res
> is NULL, -EFAULT error code is returned now. But, the returned
> value is 0 for SyS_clock_getres under the same conditions.
> Therefore, testcase thinks it is a bug.
>
> I will modify the code as below and add it in the next version patch
> if you think it is OK.
>
> @@ -209,7 +209,7 @@ static notrace int clock_getres_fallback( ...
> {
> if (res == NULL)
> - return -EFAULT;
> + return 0;
>
Ok. I don't know why that is the expected behavior (clock_getres
with a NULL argument makes little sense), but I can see that it
matches the regular syscall implementation.
Arnd
^ permalink raw reply
* Re: [PATCH] gpio: serial: max310x: Use HW type for gpio_chip's label
From: Linus Walleij @ 2018-02-07 13:36 UTC (permalink / raw)
To: Jan Kundrát
Cc: linux-gpio, linux-serial, Greg Kroah-Hartman, Alexander Shiyan
In-Reply-To: <b2421132df00569baa90af8f2d19ad75242e8c48.1516996724.git.jan.kundrat@cesnet.cz>
On Fri, Jan 26, 2018 at 8:02 PM, Jan Kundrát <jan.kundrat@cesnet.cz> wrote:
> Some debugging tools (/sys/kernel/debug/gpio, `lsgpio`) use the
> gpio_chip's label for displaying an additional context. Right now, the
> information duplicates stuff which is already available from the
> parent's device. This is how e.g. `lsgpio`'s output looks like:
>
> GPIO chip: gpiochip2, "spi1.2", 16 GPIO lines
>
> Comparing the output of other GPIO expanders that I have available:
>
> gpiochip4: GPIOs 464-479, parent: spi/spi1.1, mcp23s17, can sleep:
> gpiochip5: GPIOs 448-463, parent: i2c/0-0020, pca9555, can sleep:
> gpiochip2: GPIOs 496-511, parent: spi/spi1.2, spi1.2, can sleep:
>
> This patch ensures that the type of the real HW device is shown instead
> of duplicating the SPI path:
>
> gpiochip2: GPIOs 496-511, parent: spi/spi1.2, MAX14830, can sleep:
>
> Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Greg, pls apply this to your TTY tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] gpio: serial: max310x: Use HW type for gpio_chip's label
From: Greg Kroah-Hartman @ 2018-02-07 14:23 UTC (permalink / raw)
To: Linus Walleij
Cc: Jan Kundrát, linux-gpio, linux-serial, Alexander Shiyan
In-Reply-To: <CACRpkdaCGmsyFGZm+2t7Vnptvi2PwFRXbq28iepDgYO0LRiUWQ@mail.gmail.com>
On Wed, Feb 07, 2018 at 02:36:33PM +0100, Linus Walleij wrote:
> On Fri, Jan 26, 2018 at 8:02 PM, Jan Kundrát <jan.kundrat@cesnet.cz> wrote:
>
> > Some debugging tools (/sys/kernel/debug/gpio, `lsgpio`) use the
> > gpio_chip's label for displaying an additional context. Right now, the
> > information duplicates stuff which is already available from the
> > parent's device. This is how e.g. `lsgpio`'s output looks like:
> >
> > GPIO chip: gpiochip2, "spi1.2", 16 GPIO lines
> >
> > Comparing the output of other GPIO expanders that I have available:
> >
> > gpiochip4: GPIOs 464-479, parent: spi/spi1.1, mcp23s17, can sleep:
> > gpiochip5: GPIOs 448-463, parent: i2c/0-0020, pca9555, can sleep:
> > gpiochip2: GPIOs 496-511, parent: spi/spi1.2, spi1.2, can sleep:
> >
> > This patch ensures that the type of the real HW device is shown instead
> > of duplicating the SPI path:
> >
> > gpiochip2: GPIOs 496-511, parent: spi/spi1.2, MAX14830, can sleep:
> >
> > Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> Greg, pls apply this to your TTY tree.
Ok, let me wait until 4.16-rc1 is out first :)
greg k-h
^ permalink raw reply
* [PATCH 0/2] 8250_omap: Fix issues with throttling of 8250 port
From: Vignesh R @ 2018-02-08 12:55 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Vignesh R, linux-kernel, Andy Shevchenko, linux-serial,
Jiri Slaby, linux-omap, linux-arm-kernel
This series contains couple of fixes related to throttling of 8250 uart
port when tty buffer is under pressure.
Vignesh R (2):
serial: 8250: Don't service RX FIFO if interrupts are disabled
serial: 8250: 8250_omap: Fix throttling when DMA is enabled
drivers/tty/serial/8250/8250_omap.c | 11 ++++++++++-
drivers/tty/serial/8250/8250_port.c | 3 ++-
2 files changed, 12 insertions(+), 2 deletions(-)
--
2.16.1
^ permalink raw reply
* [PATCH 1/2] serial: 8250: Don't service RX FIFO if interrupts are disabled
From: Vignesh R @ 2018-02-08 12:55 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Vignesh R, linux-kernel, Andy Shevchenko, linux-serial,
Jiri Slaby, linux-omap, linux-arm-kernel
In-Reply-To: <20180208125542.15649-1-vigneshr@ti.com>
Currently, data in RX FIFO is read based on UART_LSR register state even
if RDI and RLSI interrupts are disabled in UART_IER register.
This is because when IRQ handler is called due to TX FIFO empty event,
RX FIFO is serviced based on UART_LSR register status instead of
UART_IIR status. This defeats the purpose of disabling UART RX
FIFO interrupts during throttling(see, omap_8250_throttle()) as IRQ
handler continues to drain UART RX FIFO resulting in overflow of buffer
at tty layer.
Fix this by making sure that driver drains UART RX FIFO only when
UART_IIR_RDI is set along with UART_LSR_BI or UART_LSR_DR bits.
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
drivers/tty/serial/8250/8250_port.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 1328c7e70108..ffbb955d1c06 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1854,7 +1854,8 @@ int serial8250_handle_irq(struct uart_port *port, unsigned int iir)
status = serial_port_in(port, UART_LSR);
- if (status & (UART_LSR_DR | UART_LSR_BI)) {
+ if (status & (UART_LSR_DR | UART_LSR_BI) &&
+ iir & UART_IIR_RDI) {
if (!up->dma || handle_rx_dma(up, iir))
status = serial8250_rx_chars(up, status);
}
--
2.16.1
^ permalink raw reply related
* [PATCH 2/2] serial: 8250: 8250_omap: Fix throttling when DMA is enabled
From: Vignesh R @ 2018-02-08 12:55 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Vignesh R, linux-kernel, Andy Shevchenko, linux-serial,
Jiri Slaby, linux-omap, linux-arm-kernel
In-Reply-To: <20180208125542.15649-1-vigneshr@ti.com>
omap_8250_throttle() is called when tty RX buffer is about to overflow
and can no longer keep up with the rate at which UART is receiving data.
So, the expectation of this callback, is that UART stops RX and asserts
HW flow control to signal the sender to stop sending more data.
omap_8250_throttle() disables RX FIFO interrupts thus FIFO is no longer
serviced, leading to assertion of flow control once RX FIFO is full.
But, this does not work when DMA is enabled as driver keeps queuing new
RX DMA request in completion handler without brothering about throttling
request made by the higher layer.
This patch introduces a flag that can be used to determine whether or
not to queue next RX DMA request based on throttling request.
Without this patch, tty buffer overflows are reported at higher
baudrates.
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
drivers/tty/serial/8250/8250_omap.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 57f6eba47f44..624b501fd253 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -114,6 +114,7 @@ struct omap8250_priv {
struct uart_8250_dma omap8250_dma;
spinlock_t rx_dma_lock;
bool rx_dma_broken;
+ bool throttled;
};
#ifdef CONFIG_SERIAL_8250_DMA
@@ -692,6 +693,7 @@ static void omap_8250_shutdown(struct uart_port *port)
static void omap_8250_throttle(struct uart_port *port)
{
+ struct omap8250_priv *priv = port->private_data;
struct uart_8250_port *up = up_to_u8250p(port);
unsigned long flags;
@@ -700,6 +702,7 @@ static void omap_8250_throttle(struct uart_port *port)
spin_lock_irqsave(&port->lock, flags);
up->ier &= ~(UART_IER_RLSI | UART_IER_RDI);
serial_out(up, UART_IER, up->ier);
+ priv->throttled = true;
spin_unlock_irqrestore(&port->lock, flags);
pm_runtime_mark_last_busy(port->dev);
@@ -738,12 +741,16 @@ static int omap_8250_rs485_config(struct uart_port *port,
static void omap_8250_unthrottle(struct uart_port *port)
{
+ struct omap8250_priv *priv = port->private_data;
struct uart_8250_port *up = up_to_u8250p(port);
unsigned long flags;
pm_runtime_get_sync(port->dev);
spin_lock_irqsave(&port->lock, flags);
+ priv->throttled = false;
+ if (up->dma)
+ up->dma->rx_dma(up);
up->ier |= UART_IER_RLSI | UART_IER_RDI;
serial_out(up, UART_IER, up->ier);
spin_unlock_irqrestore(&port->lock, flags);
@@ -788,6 +795,7 @@ static void __dma_rx_do_complete(struct uart_8250_port *p)
static void __dma_rx_complete(void *param)
{
struct uart_8250_port *p = param;
+ struct omap8250_priv *priv = p->port.private_data;
struct uart_8250_dma *dma = p->dma;
struct dma_tx_state state;
unsigned long flags;
@@ -805,7 +813,8 @@ static void __dma_rx_complete(void *param)
return;
}
__dma_rx_do_complete(p);
- omap_8250_rx_dma(p);
+ if (!priv->throttled)
+ omap_8250_rx_dma(p);
spin_unlock_irqrestore(&p->port.lock, flags);
}
--
2.16.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox