* [PATCH] [PATCH] tty/serial: atmel: add new version check for usart
From: Jonas Danielsson @ 2018-01-29 11:39 UTC (permalink / raw)
To: linux-serial
Cc: Jonas Danielsson, Richard Genoud, Greg Kroah-Hartman,
Alexandre Belloni, Jiri Slaby, linux-arm-kernel
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>
---
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;
--
2.14.1
^ permalink raw reply related
* Re: [v2,3/7] soc: qcom: Add GENI based QUP Wrapper driver
From: Doug Anderson @ 2018-01-26 19:38 UTC (permalink / raw)
To: Jonathan Corbet, andy.gross, david.brown, Rob Herring,
Mark Rutland, Wolfram Sang, Greg Kroah-Hartman
Cc: Karthikeyan Ramasubramanian, linux-doc, linux-arm-msm, devicetree,
linux-i2c, linux-serial, Jiri Slaby, Sagar Dharia,
Girish Mahadevan, evgreen
In-Reply-To: <1515805547-22816-4-git-send-email-kramasub@codeaurora.org>
Hi,
On Fri, Jan 12, 2018 at 5:05 PM, Karthikeyan Ramasubramanian
<kramasub@codeaurora.org> wrote:
> This driver manages the Generic Interface (GENI) firmware based Qualcomm
> Universal Peripheral (QUP) Wrapper. GENI based QUP is the next generation
> programmable module composed of multiple Serial Engines (SE) and supports
> a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. This
> driver also enables managing the serial interface independent aspects of
> Serial Engines.
>
> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
> Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
> Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
> ---
> drivers/soc/qcom/Kconfig | 8 +
> drivers/soc/qcom/Makefile | 1 +
> drivers/soc/qcom/qcom-geni-se.c | 1016 +++++++++++++++++++++++++++++++++++++++
> include/linux/qcom-geni-se.h | 807 +++++++++++++++++++++++++++++++
> 4 files changed, 1832 insertions(+)
> create mode 100644 drivers/soc/qcom/qcom-geni-se.c
> create mode 100644 include/linux/qcom-geni-se.h
>
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index b81374b..b306d51 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -3,6 +3,14 @@
> #
> menu "Qualcomm SoC drivers"
>
> +config QCOM_GENI_SE
> + tristate "QCOM GENI Serial Engine Driver"
One tiny nit here: maybe it makes sense to add:
depends on ARCH_QCOM
...like all the other stuff in this file? Otherwise this ends up
polluting .config files for non-Qualcomm architectures.
-Doug
^ permalink raw reply
* [PATCH] gpio: serial: max310x: Use HW type for gpio_chip's label
From: Jan Kundrát @ 2018-01-26 19:02 UTC (permalink / raw)
To: linux-gpio
Cc: linux-serial, Linus Walleij, Greg Kroah-Hartman, Alexander Shiyan
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>
---
drivers/tty/serial/max310x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 39f635812077..efe55a1a0615 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -1318,7 +1318,7 @@ static int max310x_probe(struct device *dev, struct max310x_devtype *devtype,
/* Setup GPIO cotroller */
s->gpio.owner = THIS_MODULE;
s->gpio.parent = dev;
- s->gpio.label = dev_name(dev);
+ s->gpio.label = devtype->name;
s->gpio.direction_input = max310x_gpio_direction_input;
s->gpio.get = max310x_gpio_get;
s->gpio.direction_output= max310x_gpio_direction_output;
--
2.14.3
^ permalink raw reply related
* Re: [PATCH v6 16/36] nds32: DMA mapping API
From: Greentime Hu @ 2018-01-25 13:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Linus Walleij, Mark Rutland, Greg KH, Guo Ren
In-Reply-To: <CAK8P3a0YrwAXH8n83wf=34zmN44KgJu-JVXfQWhuquNxVmZ8Sw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi, Arnd:
2018-01-25 18:42 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
> On Thu, Jan 25, 2018 at 4:45 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> 2018-01-24 19:36 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
>>> On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> 2018-01-23 16:23 GMT+08:00 Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>>>> 2018-01-18 18:26 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
>>>>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>
>>> That looks reasonable enough, but it does depend on a number of factors,
>>> and the dma-mapping.h implementation is not just about cache flushes.
>>>
>>> As I don't know the microarchitecture, can you answer these questions:
>>>
>>> - are caches always write-back, or could they be write-through?
>> Yes, we can config it to write-back or write-through.
>
> Ok. If a WT-cache is common enough, you could optimize for that
> case by skipping the explicit writeback here and just doing a synchronizing
> instruction. Usually if the cache is configurable, one would pick the
> writeback option though, so it's probably not important.
Thank you for this suggestion.
We have optimized in cpu_dcache_wb_range() and it will be called from
cpu_dma_wb_range().
It will do nothing if it is a write-through config cache.
>>> - is the CPU physical address always the same as the address visible to the
>>> device?
>> Yes, it is always the same unless the CPU uses local memory. The
>> physical address of local memory will overlap the original bus
>> address.
>> I think the local memory case can be ignored because we don't use it for now.
>
> Ok, makes sense.
>
>>> - are there devices that can only see a subset of the physical memory?
>> All devices are able to see the whole physical memory in our current
>> SoC, but I think other SoC may support such kind of HW behavior.
>
> This is one area that might need a more complex implementation then,
> depending on what devices are used in other SoCs. For network or
> storage devices, it's usually sufficient to configure a DMA mask
> from the "dma-ranges" property of the parent bus in the device tree,
> the kernel code will then use bounce buffers.
>
> For other types of drivers, using the streaming DMA interfaces
> can require using the swiotlb helper that performs the bounce
> buffering at in place of the cache operations. With a bit of luck,
> you won't ever need to worry about it, just mentioning it here in
> case you run into that problem later.
>
> The consistent_sync() implementaiton you showed earlier should be
> good enough then. With that change,
>
> Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Thank you. :)
--
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 16/36] nds32: DMA mapping API
From: Arnd Bergmann @ 2018-01-25 10:42 UTC (permalink / raw)
To: Greentime Hu
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial, Geert Uytterhoeven, Linus Walleij, Mark Rutland,
Greg KH, Guo Ren
In-Reply-To: <CAEbi=3fwCnFXmYKPEiDiqoGFujqRD0bPrPAgqtiTkO_vuX25dQ@mail.gmail.com>
On Thu, Jan 25, 2018 at 4:45 AM, Greentime Hu <green.hu@gmail.com> wrote:
> 2018-01-24 19:36 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>> On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>> 2018-01-23 16:23 GMT+08:00 Greentime Hu <green.hu@gmail.com>:
>>>> 2018-01-18 18:26 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>
>> That looks reasonable enough, but it does depend on a number of factors,
>> and the dma-mapping.h implementation is not just about cache flushes.
>>
>> As I don't know the microarchitecture, can you answer these questions:
>>
>> - are caches always write-back, or could they be write-through?
> Yes, we can config it to write-back or write-through.
Ok. If a WT-cache is common enough, you could optimize for that
case by skipping the explicit writeback here and just doing a synchronizing
instruction. Usually if the cache is configurable, one would pick the
writeback option though, so it's probably not important.
>> - is the CPU physical address always the same as the address visible to the
>> device?
> Yes, it is always the same unless the CPU uses local memory. The
> physical address of local memory will overlap the original bus
> address.
> I think the local memory case can be ignored because we don't use it for now.
Ok, makes sense.
>> - are there devices that can only see a subset of the physical memory?
> All devices are able to see the whole physical memory in our current
> SoC, but I think other SoC may support such kind of HW behavior.
This is one area that might need a more complex implementation then,
depending on what devices are used in other SoCs. For network or
storage devices, it's usually sufficient to configure a DMA mask
from the "dma-ranges" property of the parent bus in the device tree,
the kernel code will then use bounce buffers.
For other types of drivers, using the streaming DMA interfaces
can require using the swiotlb helper that performs the bounce
buffering at in place of the cache operations. With a bit of luck,
you won't ever need to worry about it, just mentioning it here in
case you run into that problem later.
The consistent_sync() implementaiton you showed earlier should be
good enough then. With that change,
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH v6 16/36] nds32: DMA mapping API
From: Greentime Hu @ 2018-01-25 3:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial, Geert Uytterhoeven, Linus Walleij, Mark Rutland,
Greg KH, Guo Ren
In-Reply-To: <CAK8P3a30W1ph-6Owuf9yZF-bKg_bx6dJKCtiF_aRAYu9NVO3DQ@mail.gmail.com>
Hi, Arnd:
2018-01-24 19:36 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu <green.hu@gmail.com> wrote:
>> Hi, Arnd:
>>
>> 2018-01-23 16:23 GMT+08:00 Greentime Hu <green.hu@gmail.com>:
>>> Hi, Arnd:
>>>
>>> 2018-01-18 18:26 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 the DMA mapping API. It uses dma_map_ops for
>>>>> flexibility.
>>>>>
>>>>> Signed-off-by: Vincent Chen <vincentc@andestech.com>
>>>>> Signed-off-by: Greentime Hu <greentime@andestech.com>
>>>>
>>>> I'm still unhappy about the way the cache flushes are done here as discussed
>>>> before. It's not a show-stopped, but no Ack from me.
>>>
>>> How about this implementation?
>
>> I am not sure if I understand it correctly.
>> I list all the combinations.
>>
>> RAM to DEVICE
>> before DMA => writeback cache
>> after DMA => nop
>>
>> DEVICE to RAM
>> before DMA => nop
>> after DMA => invalidate cache
>>
>> static void consistent_sync(void *vaddr, size_t size, int direction, int master)
>> {
>> unsigned long start = (unsigned long)vaddr;
>> unsigned long end = start + size;
>>
>> if (master == FOR_CPU) {
>> switch (direction) {
>> case DMA_TO_DEVICE:
>> break;
>> case DMA_FROM_DEVICE:
>> case DMA_BIDIRECTIONAL:
>> cpu_dma_inval_range(start, end);
>> break;
>> default:
>> BUG();
>> }
>> } else {
>> /* FOR_DEVICE */
>> switch (direction) {
>> case DMA_FROM_DEVICE:
>> break;
>> case DMA_TO_DEVICE:
>> case DMA_BIDIRECTIONAL:
>> cpu_dma_wb_range(start, end);
>> break;
>> default:
>> BUG();
>> }
>> }
>> }
>
> That looks reasonable enough, but it does depend on a number of factors,
> and the dma-mapping.h implementation is not just about cache flushes.
>
> As I don't know the microarchitecture, can you answer these questions:
>
> - are caches always write-back, or could they be write-through?
Yes, we can config it to write-back or write-through.
> - can the cache be shared with another CPU or a device?
No, we don't support it.
> - if the cache is shared, is it always coherent, never coherent, or
> either of them?
We don't support SMP and the device will access memory through bus. I
think the cache is not shared.
> - could the same memory be visible at different physical addresses
> and have conflicting caches?
We currently don't have such kind of SoC memory map.
> - is the CPU physical address always the same as the address visible to the
> device?
Yes, it is always the same unless the CPU uses local memory. The
physical address of local memory will overlap the original bus
address.
I think the local memory case can be ignored because we don't use it for now.
> - are there devices that can only see a subset of the physical memory?
All devices are able to see the whole physical memory in our current
SoC, but I think other SoC may support such kind of HW behavior.
> - can there be an IOMMU?
No.
> - are there write-buffers in the CPU that might need to get flushed before
> flushing the cache?
Yes, there are write-buffers in front of CPU caches but it should be
transparent to SW. We don't need to flush it.
> - could cache lines be loaded speculatively or with read-ahead while
> a buffer is owned by a device?
No.
^ permalink raw reply
* Re: [v2, 7/7] tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP
From: Evan Green @ 2018-01-24 23:07 UTC (permalink / raw)
To: corbet, andy.gross, david.brown, robh+dt, mark.rutland, wsa,
gregkh
Cc: Karthikeyan Ramasubramanian, linux-doc, linux-arm-msm, devicetree,
linux-i2c, linux-serial, jslaby, Girish Mahadevan, Sagar Dharia
In-Reply-To: <1515805547-22816-8-git-send-email-kramasub@codeaurora.org>
On Fri, Jan 12, 2018 at 5:05 PM, Karthikeyan Ramasubramanian
<kramasub@codeaurora.org> wrote:
> +static int get_clk_cfg(unsigned long clk_freq, unsigned long *ser_clk)
> +{
> + unsigned long root_freq[] = {7372800, 14745600, 19200000, 29491200,
> + 32000000, 48000000, 64000000, 80000000, 96000000, 100000000};
This table should be static const, right?
^ permalink raw reply
* Re: [v2, 5/7] i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller
From: Evan Green @ 2018-01-24 23:07 UTC (permalink / raw)
To: corbet, andy.gross, david.brown, robh+dt, mark.rutland, wsa,
gregkh
Cc: Karthikeyan Ramasubramanian, linux-doc, linux-arm-msm, devicetree,
linux-i2c, linux-serial, jslaby, Sagar Dharia, Girish Mahadevan
In-Reply-To: <1515805547-22816-6-git-send-email-kramasub@codeaurora.org>
On Fri, Jan 12, 2018 at 5:05 PM, Karthikeyan Ramasubramanian
<kramasub@codeaurora.org> wrote:
> This bus driver supports the GENI based i2c hardware controller in the
> Qualcomm SOCs. The Qualcomm Generic Interface (GENI) is a programmable
> module supporting a wide range of serial interfaces including I2C. The
> driver supports FIFO mode and DMA mode of transfer and switches modes
> dynamically depending on the size of the transfer.
>
> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
> Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
> Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
> ---
> drivers/i2c/busses/Kconfig | 10 +
> drivers/i2c/busses/Makefile | 1 +
> drivers/i2c/busses/i2c-qcom-geni.c | 656 +++++++++++++++++++++++++++++++++++++
> 3 files changed, 667 insertions(+)
> create mode 100644 drivers/i2c/busses/i2c-qcom-geni.c
Newbie again, throwing in my two cents.
> +static inline void qcom_geni_i2c_conf(struct geni_i2c_dev *gi2c, int dfs)
> +{
> + struct geni_i2c_clk_fld *itr = geni_i2c_clk_map + gi2c->clk_fld_idx;
> +
> + geni_write_reg(dfs, gi2c->base, SE_GENI_CLK_SEL);
> +
> + geni_write_reg((itr->clk_div << 4) | 1, gi2c->base, GENI_SER_M_CLK_CFG);
> + geni_write_reg(((itr->t_high << 20) | (itr->t_low << 10) |
> + itr->t_cycle), gi2c->base, SE_I2C_SCL_COUNTERS);
It would be great to get these register field shifts defined, as
they're otherwise fairly opaque.
> +static irqreturn_t geni_i2c_irq(int irq, void *dev)
> +{
> + struct geni_i2c_dev *gi2c = dev;
> + int i, j;
> + u32 m_stat = readl_relaxed(gi2c->base + SE_GENI_M_IRQ_STATUS);
> + u32 rx_st = readl_relaxed(gi2c->base + SE_GENI_RX_FIFO_STATUS);
> + u32 dm_tx_st = readl_relaxed(gi2c->base + SE_DMA_TX_IRQ_STAT);
> + u32 dm_rx_st = readl_relaxed(gi2c->base + SE_DMA_RX_IRQ_STAT);
> + u32 dma = readl_relaxed(gi2c->base + SE_GENI_DMA_MODE_EN);
> + struct i2c_msg *cur = gi2c->cur;
> +
> + if (!cur || (m_stat & M_CMD_FAILURE_EN) ||
> + (dm_rx_st & (DM_I2C_CB_ERR)) ||
> + (m_stat & M_CMD_ABORT_EN)) {
> +
> + if (m_stat & M_GP_IRQ_1_EN)
> + geni_i2c_err(gi2c, I2C_NACK);
> + if (m_stat & M_GP_IRQ_3_EN)
> + geni_i2c_err(gi2c, I2C_BUS_PROTO);
> + if (m_stat & M_GP_IRQ_4_EN)
> + geni_i2c_err(gi2c, I2C_ARB_LOST);
> + if (m_stat & M_CMD_OVERRUN_EN)
> + geni_i2c_err(gi2c, GENI_OVERRUN);
> + if (m_stat & M_ILLEGAL_CMD_EN)
> + geni_i2c_err(gi2c, GENI_ILLEGAL_CMD);
> + if (m_stat & M_CMD_ABORT_EN)
> + geni_i2c_err(gi2c, GENI_ABORT_DONE);
> + if (m_stat & M_GP_IRQ_0_EN)
> + geni_i2c_err(gi2c, GP_IRQ0);
> +
> + if (!dma)
> + writel_relaxed(0, (gi2c->base +
> + SE_GENI_TX_WATERMARK_REG));
The writes to the TX_WATERMARK_REG here and a little further down in
the irq handler stick out to me. A comment as to why poking at the
watermark register is necessary here would be very helpful.
-Evan
^ permalink raw reply
* Re: [v2,3/7] soc: qcom: Add GENI based QUP Wrapper driver
From: Evan Green @ 2018-01-24 23:06 UTC (permalink / raw)
To: corbet-T1hC0tSOHrs, andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wsa-z923LK4zBo2bacvFa/9K2g,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: Karthikeyan Ramasubramanian, 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: <1515805547-22816-4-git-send-email-kramasub-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Fri, Jan 12, 2018 at 5:05 PM, Karthikeyan Ramasubramanian
<kramasub-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> This driver manages the Generic Interface (GENI) firmware based Qualcomm
> Universal Peripheral (QUP) Wrapper. GENI based QUP is the next generation
> programmable module composed of multiple Serial Engines (SE) and supports
> a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. This
> driver also enables managing the serial interface independent aspects of
> Serial Engines.
>
> Signed-off-by: Karthikeyan Ramasubramanian <kramasub-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Sagar Dharia <sdharia-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Girish Mahadevan <girishm-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> drivers/soc/qcom/Kconfig | 8 +
> drivers/soc/qcom/Makefile | 1 +
> drivers/soc/qcom/qcom-geni-se.c | 1016 +++++++++++++++++++++++++++++++++++++++
> include/linux/qcom-geni-se.h | 807 +++++++++++++++++++++++++++++++
> 4 files changed, 1832 insertions(+)
> create mode 100644 drivers/soc/qcom/qcom-geni-se.c
> create mode 100644 include/linux/qcom-geni-se.h
I'm a newbie here, just starting to get up to speed. Please forgive
any indiscretions. But I am interested in this driver, so I'm throwing
in my minor comments.
> +/**
> + * geni_se_setup_m_cmd() - Setup the primary sequencer
> + * @base: Base address of the serial engine's register block.
> + * @cmd: Command/Operation to setup in the primary sequencer.
> + * @params: Parameter for the sequencer command.
> + *
> + * This function is used to configure the primary sequencer with the
> + * command and its assoicated parameters.
> + */
> +void geni_se_setup_m_cmd(void __iomem *base, u32 cmd, u32 params);
> +
> +/**
> + * geni_se_setup_s_cmd() - Setup the secondary sequencer
> + * @base: Base address of the serial engine's register block.
> + * @cmd: Command/Operation to setup in the secondary sequencer.
> + * @params: Parameter for the sequencer command.
> + *
> + * This function is used to configure the secondary sequencer with the
> + * command and its assoicated parameters.
> + */
> +void geni_se_setup_s_cmd(void __iomem *base, u32 cmd, u32 params);
> +
s/assoicated/associated/ (twice)
> +/**
> + * geni_se_tx_dma_prep() - Prepare the Serial Engine for TX DMA transfer
> + * @wrapper_dev: QUP Wrapper Device to which the TX buffer is mapped.
> + * @base: Base address of the SE register block.
> + * @tx_buf: Pointer to the TX buffer.
> + * @tx_len: Length of the TX buffer.
> + * @tx_dma: Pointer to store the mapped DMA address.
> + *
> + * This function is used to prepare the buffers for DMA TX.
> + *
> + * Return: 0 on success, standard Linux error codes on error/failure.
> + */
> +int geni_se_tx_dma_prep(struct device *wrapper_dev, void __iomem *base,
> + void *tx_buf, int tx_len, dma_addr_t *tx_dma)
> +{
> + int ret;
> +
> + if (unlikely(!wrapper_dev || !base || !tx_buf || !tx_len || !tx_dma))
> + return -EINVAL;
> +
> + ret = geni_se_map_buf(wrapper_dev, tx_dma, tx_buf, tx_len,
> + DMA_TO_DEVICE);
> + if (ret)
> + return ret;
> +
> + geni_write_reg(7, base, SE_DMA_TX_IRQ_EN_SET);
> + geni_write_reg((u32)(*tx_dma), base, SE_DMA_TX_PTR_L);
> + geni_write_reg((u32)((*tx_dma) >> 32), base, SE_DMA_TX_PTR_H);
> + geni_write_reg(1, base, SE_DMA_TX_ATTR);
Bjorn touched on this, but as someone trying to understand what's
going on it would be great to see #defines for the magic values in
here (7 and 1)
> +void geni_se_get_packing_config(int bpw, int pack_words, bool msb_to_lsb,
> + unsigned long *cfg0, unsigned long *cfg1)
> +{
> + u32 cfg[4] = {0};
> + int len;
> + int temp_bpw = bpw;
> + int idx_start = (msb_to_lsb ? (bpw - 1) : 0);
> + int idx = idx_start;
> + int idx_delta = (msb_to_lsb ? -BITS_PER_BYTE : BITS_PER_BYTE);
> + int ceil_bpw = ((bpw & (BITS_PER_BYTE - 1)) ?
> + ((bpw & ~(BITS_PER_BYTE - 1)) + BITS_PER_BYTE) : bpw);
> + int iter = (ceil_bpw * pack_words) >> 3;
Is the shift by 3 here really meant to divide by BITS_PER_BYTE? It
might be clearer to divide by BITS_PER_BYTE and let the compiler
convert that into a shift.
> + int i;
> +
> + if (unlikely(iter <= 0 || iter > 4)) {
> + *cfg0 = 0;
> + *cfg1 = 0;
> + return;
> + }
> +
> + for (i = 0; i < iter; i++) {
> + len = (temp_bpw < BITS_PER_BYTE) ?
> + (temp_bpw - 1) : BITS_PER_BYTE - 1;
> + cfg[i] = ((idx << 5) | (msb_to_lsb << 4) | (len << 1));
...more magic numbers here. These are register bitfields? It would be
great to get the field shifts defined.
> + idx = ((temp_bpw - BITS_PER_BYTE) <= 0) ?
> + ((i + 1) * BITS_PER_BYTE) + idx_start :
> + idx + idx_delta;
> + temp_bpw = ((temp_bpw - BITS_PER_BYTE) <= 0) ?
> + bpw : (temp_bpw - BITS_PER_BYTE);
> + }
> + cfg[iter - 1] |= 1;
> + *cfg0 = cfg[0] | (cfg[1] << 10);
> + *cfg1 = cfg[2] | (cfg[3] << 10);
> +}
...more magic shifts here.
> +void geni_se_config_packing(void __iomem *base, int bpw,
> + int pack_words, bool msb_to_lsb)
> +{
> + unsigned long cfg0, cfg1;
> +
> + geni_se_get_packing_config(bpw, pack_words, msb_to_lsb, &cfg0, &cfg1);
> + geni_write_reg(cfg0, base, SE_GENI_TX_PACKING_CFG0);
> + geni_write_reg(cfg1, base, SE_GENI_TX_PACKING_CFG1);
> + geni_write_reg(cfg0, base, SE_GENI_RX_PACKING_CFG0);
> + geni_write_reg(cfg1, base, SE_GENI_RX_PACKING_CFG1);
> + if (pack_words || bpw == 32)
> + geni_write_reg((bpw >> 4), base, SE_GENI_BYTE_GRAN);
> +}
...Same here for the bpw >> 4.
Thanks,
Evan
--
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: RCU stall in 8250 serial driver Linux 4.15-rc1
From: Andy Shevchenko @ 2018-01-24 16:40 UTC (permalink / raw)
To: Alan Cox
Cc: Shankara Pailoor, Greg KH, Jiri Slaby, LKML, syzkaller,
linux-serial
In-Reply-To: <20180123155229.2035e674@alans-desktop>
On Tue, Jan 23, 2018 at 5:52 PM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
> On Wed, 17 Jan 2018 09:24:32 -0800
> Shankara Pailoor <sp3485@columbia.edu> wrote:
>
>> Hi Greg,
>>
>> Sorry for that. Here is the stack trace. C Program below
>
>
>
>> serial_in drivers/tty/serial/8250/8250.h:111 [inline]
>> wait_for_xmitr+0x8a/0x1d0 drivers/tty/serial/8250/8250_port.c:2033
>> serial8250_console_putchar+0x19/0x50 drivers/tty/serial/8250/8250_port.c:3170
>> uart_console_write+0x98/0xc0 drivers/tty/serial/serial_core.c:1858
>
> The console is spinning in polled mode trying to write data to the
> console port, which it seems has gotten a bit stuck. Could be the
> hypervisor hits some kind of buffering limit, could be hypervisor
> interface broke.
>
> Either way the console interface is supposed to stall the machine to
> ensure the bytes always get out and if your serial port jams or gets
> massively behind then this will happen.
+1
https://lkml.org/lkml/2017/12/21/480
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v6 16/36] nds32: DMA mapping API
From: Arnd Bergmann @ 2018-01-24 11:36 UTC (permalink / raw)
To: Greentime Hu
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Linus Walleij, Mark Rutland, Greg KH, Guo Ren
In-Reply-To: <CAEbi=3d46tXacnnU+RJGMw+KR1O=NaVjO+NW3cxUjAN==V51iw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi, Arnd:
>
> 2018-01-23 16:23 GMT+08:00 Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>> Hi, Arnd:
>>
>> 2018-01-18 18:26 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> From: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>>>
>>>> This patch adds support for the DMA mapping API. It uses dma_map_ops for
>>>> flexibility.
>>>>
>>>> Signed-off-by: Vincent Chen <vincentc-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>>> Signed-off-by: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>>
>>> I'm still unhappy about the way the cache flushes are done here as discussed
>>> before. It's not a show-stopped, but no Ack from me.
>>
>> How about this implementation?
> I am not sure if I understand it correctly.
> I list all the combinations.
>
> RAM to DEVICE
> before DMA => writeback cache
> after DMA => nop
>
> DEVICE to RAM
> before DMA => nop
> after DMA => invalidate cache
>
> static void consistent_sync(void *vaddr, size_t size, int direction, int master)
> {
> unsigned long start = (unsigned long)vaddr;
> unsigned long end = start + size;
>
> if (master == FOR_CPU) {
> switch (direction) {
> case DMA_TO_DEVICE:
> break;
> case DMA_FROM_DEVICE:
> case DMA_BIDIRECTIONAL:
> cpu_dma_inval_range(start, end);
> break;
> default:
> BUG();
> }
> } else {
> /* FOR_DEVICE */
> switch (direction) {
> case DMA_FROM_DEVICE:
> break;
> case DMA_TO_DEVICE:
> case DMA_BIDIRECTIONAL:
> cpu_dma_wb_range(start, end);
> break;
> default:
> BUG();
> }
> }
> }
That looks reasonable enough, but it does depend on a number of factors,
and the dma-mapping.h implementation is not just about cache flushes.
As I don't know the microarchitecture, can you answer these questions:
- are caches always write-back, or could they be write-through?
- can the cache be shared with another CPU or a device?
- if the cache is shared, is it always coherent, never coherent, or
either of them?
- could the same memory be visible at different physical addresses
and have conflicting caches?
- is the CPU physical address always the same as the address visible to the
device?
- are there devices that can only see a subset of the physical memory?
- can there be an IOMMU?
- are there write-buffers in the CPU that might need to get flushed before
flushing the cache?
- could cache lines be loaded speculatively or with read-ahead while
a buffer is owned by a device?
Arnd
--
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: Arnd Bergmann @ 2018-01-24 11:13 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-u79uwXL29TY76Z2rM5mHXA,
Geert Uytterhoeven, Linus Walleij, Mark Rutland, Greg KH, Guo Ren
In-Reply-To: <CAJsyPhyGpJVQegd7ns9oZOjM=XsGVixCQaH9nT_jOQsSpyRs+g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Jan 24, 2018 at 1:56 AM, Vincent Chen <deanbo422-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 2018-01-18 18:30 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> From: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>>
>>> This patch adds support for signal handling.
>>>
>>> Signed-off-by: Vincent Chen <vincentc-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>> Signed-off-by: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>
>> 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
--
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 07/36] nds32: Exception handling
From: Arnd Bergmann @ 2018-01-24 11:10 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: <CAK8P3a1mwKLi2Cj43EQvwodPCQVwWfW5gjNtf+DLdyb8T49OWw@mail.gmail.com>
On Wed, Jan 24, 2018 at 12:09 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Jan 24, 2018 at 11:53 AM, Vincent Chen <deanbo422@gmail.com> wrote:
>> 2018-01-18 18:14 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> Ok. I still wonder about the kernel part of this though: is it a good idea
> for user space to configure whether the kernel does unaligned
> accesses? I would think that the kernel should just be fixed in such
> a case.
To clarify: I'm asking only about unaligned accesses from kernel code itself,
which is generally considered a bug when
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is disabled.
Arnd
^ permalink raw reply
* Re: [PATCH v6 07/36] nds32: Exception handling
From: Arnd Bergmann @ 2018-01-24 11:09 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: <CAJsyPhx1B75GJCD2a_=m92ipq3oYsXxMGq9Bg9eCw_ALavWKMg@mail.gmail.com>
On Wed, Jan 24, 2018 at 11:53 AM, Vincent Chen <deanbo422@gmail.com> wrote:
> 2018-01-18 18:14 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 includes the exception/interrupt entries, pt_reg structure and
>>> related accessors.
>>>
>>> Signed-off-by: Vincent Chen <vincentc@andestech.com>
>>> Signed-off-by: Greentime Hu <greentime@andestech.com>
>>
>> Here it would be good to have a more detailed explanation about the alignment
>> trap handling. I remember discussing it with you before, but don't remember
>> the exact outcome. In particular you should explain here why you need to
>> handle alignment traps in the first place, and what the expected defaults
>> are (e.g. always disabled unless a user requests it, or always enabled) and
>> what kind of code runs into the traps (e.g. buggy kernel code, correct
>> kernel code, buggy user space code etc).
>>
>> Arnd
>
>
> Dear Arnd:
>
> I am plans to add the following description in the git commit's comment
>
> Andes processors cannot load/store information which is not naturally aligned
> on the bus, i.e., loading a 4 byte data whose start address must be divisible
> by 4. If unaligned data accessing is happened, data unaligned exception will be
> triggered and user will get SIGSEGV or kernel oops according to the unaligned
> address. In order to make user able to load/store data from an unaligned
> address, software load /store emulation is implemented in
> arch/nds32/mm/alignment.c to handle data unaligned exception.
>
> Unaligned accessing handling is disable by default because of it is not
> a normal case. User can follow the steps below to enable this feature.
>
> A. Compile time:
> 1. Enable kernel config CONFIG_ALIGNMENT_TRAP
> B. Run time:
> 1. Enter /proc/sys/nds32/unaligned_acess folder
> 2.
> a. Write ‘1’ to file enable_mode to enable unaligned accessing handling
> for user space
> b. Write ‘2’ to file enable_mode to enable unaligned accessing handling
> for kernel space
> c. Write ‘3’ to file enable_mode to enable unaligned accessing handling
> for user and kernel space
> d. Write '0' to file enable_mode to disable all unaligned
> accessing handling
> 3.
> a. Write ‘1’ to file debug to show which unaligned address is addressed
> b. Write ‘0’ to file debug to disable all information
>
> However, unaligned accessing handler can’t work on following conditions.
> A. The corresponding mode for unaligned address is not enabled.
> B. This unaligned address is not accessible such as protection violation.
> On these conditions, the default behaviors for data unaligned
> exception still happen.
Ok. I still wonder about the kernel part of this though: is it a good idea
for user space to configure whether the kernel does unaligned
accesses? I would think that the kernel should just be fixed in such
a case.
Arnd
^ permalink raw reply
* Re: [PATCH v6 07/36] nds32: Exception handling
From: Vincent Chen @ 2018-01-24 10:53 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-u79uwXL29TY76Z2rM5mHXA,
Geert Uytterhoeven, Linus Walleij, Mark Rutland, Greg KH, Guo Ren
In-Reply-To: <CAK8P3a1ZZsB7MVZ8sEPzkVcNUJh3-MB_ApmPi+DUF1rc9h8pXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-18 18:14 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> From: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>
>> This patch includes the exception/interrupt entries, pt_reg structure and
>> related accessors.
>>
>> Signed-off-by: Vincent Chen <vincentc-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>> Signed-off-by: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>
> Here it would be good to have a more detailed explanation about the alignment
> trap handling. I remember discussing it with you before, but don't remember
> the exact outcome. In particular you should explain here why you need to
> handle alignment traps in the first place, and what the expected defaults
> are (e.g. always disabled unless a user requests it, or always enabled) and
> what kind of code runs into the traps (e.g. buggy kernel code, correct
> kernel code, buggy user space code etc).
>
> Arnd
Dear Arnd:
I am plans to add the following description in the git commit's comment
Andes processors cannot load/store information which is not naturally aligned
on the bus, i.e., loading a 4 byte data whose start address must be divisible
by 4. If unaligned data accessing is happened, data unaligned exception will be
triggered and user will get SIGSEGV or kernel oops according to the unaligned
address. In order to make user able to load/store data from an unaligned
address, software load /store emulation is implemented in
arch/nds32/mm/alignment.c to handle data unaligned exception.
Unaligned accessing handling is disable by default because of it is not
a normal case. User can follow the steps below to enable this feature.
A. Compile time:
1. Enable kernel config CONFIG_ALIGNMENT_TRAP
B. Run time:
1. Enter /proc/sys/nds32/unaligned_acess folder
2.
a. Write ‘1’ to file enable_mode to enable unaligned accessing handling
for user space
b. Write ‘2’ to file enable_mode to enable unaligned accessing handling
for kernel space
c. Write ‘3’ to file enable_mode to enable unaligned accessing handling
for user and kernel space
d. Write '0' to file enable_mode to disable all unaligned
accessing handling
3.
a. Write ‘1’ to file debug to show which unaligned address is addressed
b. Write ‘0’ to file debug to disable all information
However, unaligned accessing handler can’t work on following conditions.
A. The corresponding mode for unaligned address is not enabled.
B. This unaligned address is not accessible such as protection violation.
On these conditions, the default behaviors for data unaligned
exception still happen.
Thanks
Vincent
--
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-01-24 0:56 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-u79uwXL29TY76Z2rM5mHXA,
Geert Uytterhoeven, Linus Walleij, Mark Rutland, Greg KH, Guo Ren
In-Reply-To: <CAK8P3a2HR6be9Fm+o1Oq-V5p51xEiuhbyqkgVWprD5BxuU29xQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-18 18:30 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> From: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>
>> This patch adds support for signal handling.
>>
>> Signed-off-by: Vincent Chen <vincentc-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>> Signed-off-by: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>
> 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.
>
> Arnd
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?
Thanks.
Vincent
--
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 1/2] Bluetooth: hci_bcm: Remove platform_device support
From: Ferry Toth @ 2018-01-23 23:49 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Marcel Holtmann, Hans de Goede, Gustavo F. Padovan, Johan Hedberg,
Bluez mailing list, linux-serial, ACPI Devel Maling List,
Lukas Wunner
In-Reply-To: <1516623321.7000.1175.camel@linux.intel.com>
Op maandag 22 januari 2018 13:15:21 CET schreef Andy Shevchenko:
> On Mon, 2018-01-22 at 13:01 +0100, Marcel Holtmann wrote:
> > > > > Anyways it looks like this will be really hard to do without
> > > > > access
> > > > > to the hardware.
> > > >
> > > > I can do a BAT.
> > >
> > > Right, sorry I was not clear, when I was talking about hardware
> > > access I was not (not only) referring to testing.
> > >
> > > The problem is that to figure out how to hook all this together
> > > will require poking around on the hardware, looking in sysfs,
> > > finding
> > > some id we can use in a pci_serdev_register_devices() to add to
> > > drivers/tty/serdev/core.c so that it only turns the serial port on
> > > the Edison into a serdev and not somewhere else, etc.
> > >
> > > But thinking about this more, I too have higher priority items on
> > > my TODO list, so as much as I would like to see this cleaned up,
> > > lets shelf this for now until you have time to look into this.
> > >
> > > When you do find time, if you've any questions I'm happy to help.
> >
> > so in theory the Edison board has SFI. Problem is just that I am not
> > sure the SFI on the board is fully correct and contains enough
> > information to identify the serial port correctly.
>
> Unfortunately SFI was so badly designed that board (hard coded) data is
> needed.
>
> > If no one is willing to help port this over to serdev, then one option
> > is just to rip it out and see who complains.
>
> Me in the first place. + I guess at least couple of users as of my
> knowledge. + Undefined amount of swindled users of Edison who is trying
> or already did a switch to vanilla kernel.
>
> > Or include a version that is trying its best and see who reports
> >
> > issues and who helps to fix it. I am now regretting that I accepted
> > the Edison support in the first place, but sadly serdev was not yet
> > fully baked at that point.
>
> +Cc: Ferry, who might be interested in the helping with it.
I would be glad to help. Keep in mind I'm not a kernel developer and need
someone to hold my hand. All this in my free time of course, but can
spend a few evenings per week.
Nevertheless I have an Edison dual booting 4.15.0-rc8 with poky pyro user
space. So I can easily apply patches and test.
--
Ferry Toth
^ permalink raw reply
* Re: RCU stall in 8250 serial driver Linux 4.15-rc1
From: Alan Cox @ 2018-01-23 15:52 UTC (permalink / raw)
To: Shankara Pailoor; +Cc: Greg KH, jslaby, LKML, syzkaller, linux-serial
In-Reply-To: <CAASgV=tRY1ioh4vZi3ZyugDJzCiADwo+Mg+HNoEwCzAaV_G=jQ@mail.gmail.com>
On Wed, 17 Jan 2018 09:24:32 -0800
Shankara Pailoor <sp3485@columbia.edu> wrote:
> Hi Greg,
>
> Sorry for that. Here is the stack trace. C Program below
> serial_in drivers/tty/serial/8250/8250.h:111 [inline]
> wait_for_xmitr+0x8a/0x1d0 drivers/tty/serial/8250/8250_port.c:2033
> serial8250_console_putchar+0x19/0x50 drivers/tty/serial/8250/8250_port.c:3170
> uart_console_write+0x98/0xc0 drivers/tty/serial/serial_core.c:1858
The console is spinning in polled mode trying to write data to the
console port, which it seems has gotten a bit stuck. Could be the
hypervisor hits some kind of buffering limit, could be hypervisor
interface broke.
Either way the console interface is supposed to stall the machine to
ensure the bytes always get out and if your serial port jams or gets
massively behind then this will happen.
Alan
^ permalink raw reply
* Re: [PATCH] acpi, spcr: Make SPCR available to x86
From: Prarit Bhargava @ 2018-01-23 12:41 UTC (permalink / raw)
To: Timur Tabi, linux-kernel
Cc: linux-acpi, linux-doc, linux-arm-kernel, linux-pm, linux-serial,
Bhupesh Sharma, Lv Zheng, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, Jonathan Corbet, Catalin Marinas,
Will Deacon, graeme.gregory, mark.salter
In-Reply-To: <745c9e29-f0b4-775b-28f7-8712cdc90fe1@codeaurora.org>
On 01/22/2018 04:49 PM, Timur Tabi wrote:
> On 01/18/2018 09:09 AM, Prarit Bhargava wrote:
>> if (acpi_disabled) {
>> - if (earlycon_init_is_deferred)
>> + if (earlycon_acpi_spcr_enable)
>
> This patch works for me, so I can ACK it, but first you might want to rename
> earlycon_acpi_spcr_enable, because these two lines don't make much sense.
>
> "If ACPI is disabled, and ACPI SCPR is enabled, then ...."
>
> If ACPI is disabled, then how can a variable called "earlycon_acpi_spcr_enable"
> be true?
>
> Would it make more sense to rename it to earlycon_spcr_enable?
>
acpi_disabled is a global runtime flag that can be set via "acpi=off" on the
command line. It does not disable the tables, only the reading and interpreting
of the data in the tables.
P.
^ permalink raw reply
* Re: [PATCH v6 16/36] nds32: DMA mapping API
From: Greentime Hu @ 2018-01-23 11:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Linus Walleij, Mark Rutland, Greg KH, Guo Ren
In-Reply-To: <CAEbi=3cYynvFS2GDzj5Oav_5LtHPdBfBWh9c=mFT0PxeOLX9sQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi, Arnd:
2018-01-23 16:23 GMT+08:00 Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> Hi, Arnd:
>
> 2018-01-18 18:26 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> From: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>>
>>> This patch adds support for the DMA mapping API. It uses dma_map_ops for
>>> flexibility.
>>>
>>> Signed-off-by: Vincent Chen <vincentc-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>> Signed-off-by: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>
>> I'm still unhappy about the way the cache flushes are done here as discussed
>> before. It's not a show-stopped, but no Ack from me.
>
> How about this implementation?
>
> static void
> nds32_dma_sync_single_for_cpu(struct device *dev, dma_addr_t handle,
> size_t size, enum dma_data_direction dir)
> {
> switch (direction) {
> case DMA_TO_DEVICE: /* writeback only */
> break;
> case DMA_FROM_DEVICE: /* invalidate only */
> case DMA_BIDIRECTIONAL: /* writeback and invalidate */
> cpu_dma_inval_range(start, end);
> break;
> default:
> BUG();
> }
> }
>
> static void
> nds32_dma_sync_single_for_device(struct device *dev, dma_addr_t handle,
> size_t size, enum dma_data_direction dir)
> {
> switch (direction) {
> case DMA_FROM_DEVICE: /* invalidate only */
> break;
> case DMA_TO_DEVICE: /* writeback only */
> case DMA_BIDIRECTIONAL: /* writeback and invalidate */
> cpu_dma_wb_range(start, end);
> break;
> default:
> BUG();
> }
> }
I am not sure if I understand it correctly.
I list all the combinations.
RAM to DEVICE
before DMA => writeback cache
after DMA => nop
DEVICE to RAM
before DMA => nop
after DMA => invalidate cache
static void consistent_sync(void *vaddr, size_t size, int direction, int master)
{
unsigned long start = (unsigned long)vaddr;
unsigned long end = start + size;
if (master == FOR_CPU) {
switch (direction) {
case DMA_TO_DEVICE:
break;
case DMA_FROM_DEVICE:
case DMA_BIDIRECTIONAL:
cpu_dma_inval_range(start, end);
break;
default:
BUG();
}
} else {
/* FOR_DEVICE */
switch (direction) {
case DMA_FROM_DEVICE:
break;
case DMA_TO_DEVICE:
case DMA_BIDIRECTIONAL:
cpu_dma_wb_range(start, end);
break;
default:
BUG();
}
}
}
static void
nds32_dma_sync_single_for_cpu(struct device *dev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
{
consistent_sync((void *)phys_to_virt(handle), size, dir, FOR_CPU);
}
static void
nds32_dma_sync_single_for_device(struct device *dev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
{
consistent_sync((void *)phys_to_virt(handle), size, dir, FOR_DEVICE);
}
static dma_addr_t nds32_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
enum dma_data_direction dir,
unsigned long attrs)
{
if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
consistent_sync((void *)(page_address(page) + offset),
size, dir, FOR_DEVICE);
return page_to_phys(page) + offset;
}
static void nds32_dma_unmap_page(struct device *dev, dma_addr_t handle,
size_t size, enum dma_data_direction dir,
unsigned long attrs)
{
if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
consistent_sync(phys_to_virt(handle), size, dir, FOR_CPU);
}
--
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 16/36] nds32: DMA mapping API
From: Greentime Hu @ 2018-01-23 8:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial, Geert Uytterhoeven, Linus Walleij, Mark Rutland,
Greg KH, Guo Ren
In-Reply-To: <CAK8P3a0-Vf9CRZzdXCxpuQoWgMhYWgO6Hy2KuP-gOKttoSGESA@mail.gmail.com>
Hi, Arnd:
2018-01-18 18:26 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 the DMA mapping API. It uses dma_map_ops for
>> flexibility.
>>
>> Signed-off-by: Vincent Chen <vincentc@andestech.com>
>> Signed-off-by: Greentime Hu <greentime@andestech.com>
>
> I'm still unhappy about the way the cache flushes are done here as discussed
> before. It's not a show-stopped, but no Ack from me.
How about this implementation?
static void
nds32_dma_sync_single_for_cpu(struct device *dev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
{
switch (direction) {
case DMA_TO_DEVICE: /* writeback only */
break;
case DMA_FROM_DEVICE: /* invalidate only */
case DMA_BIDIRECTIONAL: /* writeback and invalidate */
cpu_dma_inval_range(start, end);
break;
default:
BUG();
}
}
static void
nds32_dma_sync_single_for_device(struct device *dev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
{
switch (direction) {
case DMA_FROM_DEVICE: /* invalidate only */
break;
case DMA_TO_DEVICE: /* writeback only */
case DMA_BIDIRECTIONAL: /* writeback and invalidate */
cpu_dma_wb_range(start, end);
break;
default:
BUG();
}
}
^ permalink raw reply
* Re: [PATCH v6 22/36] nds32: Debugging support
From: Arnd Bergmann @ 2018-01-23 8:21 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: <CAJsyPhwPsgMoReEaijkL6SAM6Q_fTL3BK9opa3yTaLtEE1PNTA@mail.gmail.com>
On Tue, Jan 23, 2018 at 8:28 AM, Vincent Chen <deanbo422@gmail.com> wrote:
> 2018-01-18 18:37 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>
>>
>> It appears that you are implementing the old-style ptrace handling
>> with architecture specific commands. Please have a look at how
>> this is done in risc-v or arm64. If this takes more too much time
>> to address, I'd suggest using an empty stub function for sys_ptrace
>> and adding it back at a later point, but not send the current version
>> upstream.
>>
>
> After referring to risc-v and arm64, I realize that PTRACE_GETREGSET
> and PTRACE_SETREGSET is used to replace arch specific command.
> The needed port for the two ptrace commands had done in current
> version patch.
>
> Could I keep them and just removing the code for old-style ptrace
> handling in the next version patch?
The important part is to not merge a user space interface into the upstream
kernel that we still want to change. It's clear that it takes some time to
update gdb and other programs using the ptrace interface, so I'd suggest
to simply not have any ptrace interface submitted for inclusion until that
is complete.
In the meantime, you can keep the existing version as an add-on kernel
patch, you probably have other patches that are not ready to get merged
yet, so just keep this one in the same tree as the others.
Arnd
^ permalink raw reply
* Re: [PATCH v2] serdev: add method to set parity
From: Marcel Holtmann @ 2018-01-23 8:16 UTC (permalink / raw)
To: Ulrich Hecht
Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Johan Hovold,
Sebastian Reichel, Bluez mailing list, Rob Herring,
Martin Blumenstingl, Greg Kroah-Hartman,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
wsa-z923LK4zBo2bacvFa/9K2g, geert-Td1EMuHUCqxL1ZNQvxDV9g
In-Reply-To: <1516643792-22840-1-git-send-email-ulrich.hecht+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Ulrich,
> Adds serdev_device_set_parity() and an implementation for ttyport.
> The interface uses an enum with the values SERIAL_PARITY_NONE,
> SERIAL_PARITY_EVEN and SERIAL_PARITY_ODD.
>
> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Reviewed-by: Sebastian Reichel <sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> ---
>
> Hi!
>
> This revision addresses Johan's comments (see below for details) and adds
> Sebastian's Reviewed-by tag. Thank you for your reviews!
>
> CU
> Uli
>
>
> Changes since v1:
> - added Reviewed-by tag
> - expanded commit message
> - shuffled stuff around to keep line-setting bits together
> - clear CMSPAR
> - (hopefully) detect errors correctly by checking tty->termios after call
> to tty_set_termios().
>
>
> drivers/tty/serdev/core.c | 12 ++++++++++++
> drivers/tty/serdev/serdev-ttyport.c | 24 ++++++++++++++++++++++++
> include/linux/serdev.h | 10 ++++++++++
> 3 files changed, 46 insertions(+)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v6 22/36] nds32: Debugging support
From: Vincent Chen @ 2018-01-23 7:28 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-u79uwXL29TY76Z2rM5mHXA,
Geert Uytterhoeven, Linus Walleij, Mark Rutland, Greg KH, Guo Ren
In-Reply-To: <CAK8P3a2HKWHxmkcx5Lf3VFT6yErppXY+brmGr7k2KBLeXgvuFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-18 18:37 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> From: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>
>> This patch adds ptrace support.
>>
>> Signed-off-by: Vincent Chen <vincentc-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>> Signed-off-by: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>
> I must have missed this patch earlier, unfortunately I don't think
> this is ready:
>
>> +long arch_ptrace(struct task_struct *child, long request, unsigned long addr,
>> + unsigned long data)
>> +{
>> + int ret;
>> +
>> + switch (request) {
>> + case PTRACE_PEEKUSR:
>> + ret =
>> + ptrace_read_user(child, addr, (unsigned long __user *)data);
>> + break;
>> +
>> + case PTRACE_POKEUSR:
>> + ret = ptrace_write_user(child, addr, data);
>> + break;
>> +
>> + case PTRACE_GETREGS:
>> + ret = ptrace_getregs(child, (void __user *)data);
>> + break;
>> +
>> + case PTRACE_SETREGS:
>> + ret = ptrace_setregs(child, (void __user *)data);
>> + break;
>> +
>> + case PTRACE_GETFPREGS:
>> + ret = ptrace_getfpregs(child, (void __user *)data);
>> + break;
>> +
>> + case PTRACE_SETFPREGS:
>> + ret = ptrace_setfpregs(child, (void __user *)data);
>> + break;
>> +
>> + default:
>> + ret = ptrace_request(child, request, addr, data);
>> + break;
>> + }
>> +
>> + return ret;
>> +}
>
> It appears that you are implementing the old-style ptrace handling
> with architecture specific commands. Please have a look at how
> this is done in risc-v or arm64. If this takes more too much time
> to address, I'd suggest using an empty stub function for sys_ptrace
> and adding it back at a later point, but not send the current version
> upstream.
>
> Arnd
Dear Arnd:
Thanks for your comments.
After referring to risc-v and arm64, I realize that PTRACE_GETREGSET
and PTRACE_SETREGSET is used to replace arch specific command.
The needed port for the two ptrace commands had done in current
version patch.
Could I keep them and just removing the code for old-style ptrace
handling in the next version patch?
Thanks
Vincent
--
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 v2] serdev: add method to set parity
From: Greg Kroah-Hartman @ 2018-01-23 7:00 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Ulrich Hecht, Rob Herring, linux-renesas-soc, linux-serial,
Johan Hovold, Sebastian Reichel, Bluez mailing list,
Martin Blumenstingl, magnus.damm, laurent.pinchart, wsa, geert
In-Reply-To: <33F02495-73E7-47A6-B10B-FA6940F6DE63@holtmann.org>
On Mon, Jan 22, 2018 at 07:23:00PM +0100, Marcel Holtmann wrote:
> Hi Rob,
>
> > Adds serdev_device_set_parity() and an implementation for ttyport.
> > The interface uses an enum with the values SERIAL_PARITY_NONE,
> > SERIAL_PARITY_EVEN and SERIAL_PARITY_ODD.
> >
> > Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
> > Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> > ---
> >
> > Hi!
> >
> > This revision addresses Johan's comments (see below for details) and adds
> > Sebastian's Reviewed-by tag. Thank you for your reviews!
> >
> > CU
> > Uli
> >
> >
> > Changes since v1:
> > - added Reviewed-by tag
> > - expanded commit message
> > - shuffled stuff around to keep line-setting bits together
> > - clear CMSPAR
> > - (hopefully) detect errors correctly by checking tty->termios after call
> > to tty_set_termios().
> >
> >
> > drivers/tty/serdev/core.c | 12 ++++++++++++
> > drivers/tty/serdev/serdev-ttyport.c | 24 ++++++++++++++++++++++++
> > include/linux/serdev.h | 10 ++++++++++
> > 3 files changed, 46 insertions(+)
>
> if there are no objections, I would like to just take this through bluetooth-next tree.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
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