* [PATCH 03/14] serial: lantiq: Get serial id from dts
From: Songjun Wu @ 2018-09-24 10:27 UTC (permalink / raw)
To: yixin.zhu, chuanhua.lei, hauke.mehrtens
Cc: Songjun Wu, Greg Kroah-Hartman, linux-kernel, linux-serial,
Jiri Slaby
In-Reply-To: <20180924102803.30263-1-songjun.wu@linux.intel.com>
Get serial id from dts, also keep backward compatible when dts is not
updated.
Signed-off-by: Songjun Wu <songjun.wu@linux.intel.com>
---
drivers/tty/serial/lantiq.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 044128277248..66c671677761 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -688,7 +688,7 @@ lqasc_probe(struct platform_device *pdev)
struct ltq_uart_port *ltq_port;
struct uart_port *port;
struct resource *mmres, irqres[3];
- int line = 0;
+ int line;
int ret;
mmres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -699,9 +699,20 @@ lqasc_probe(struct platform_device *pdev)
return -ENODEV;
}
- /* check if this is the console port */
- if (mmres->start != CPHYSADDR(LTQ_EARLY_ASC))
- line = 1;
+ /* get serial id */
+ line = of_alias_get_id(node, "serial");
+ if (line < 0) {
+ if (IS_ENABLED(CONFIG_LANTIQ)) {
+ if (mmres->start == CPHYSADDR(LTQ_EARLY_ASC))
+ line = 0;
+ else
+ line = 1;
+ } else {
+ dev_err(&pdev->dev, "failed to get alias id, errno %d\n",
+ line);
+ return line;
+ }
+ }
if (lqasc_port[line]) {
dev_err(&pdev->dev, "port %d already allocated\n", line);
--
2.11.0
^ permalink raw reply related
* [PATCH 00/14] serial: langtiq: Add CCF suppport
From: Songjun Wu @ 2018-09-24 10:27 UTC (permalink / raw)
To: yixin.zhu, chuanhua.lei, hauke.mehrtens
Cc: Songjun Wu, devicetree, linux-serial, James Hogan, linux-mips,
Jiri Slaby, linux-kernel, Thomas Gleixner, Philippe Ombredanne,
Paul Burton, Rob Herring, Kate Stewart, Greg Kroah-Hartman,
Mark Rutland, Ralf Baechle
This patch series is for adding common clock framework support
for langtiq serial driver, mainly includes:
1) Add common clock framework support.
2) Modify the dts file according to the DT conventions.
3) Replace the platform dependent functions with kernel functions
Songjun Wu (14):
MIPS: dts: Change upper case to lower case
MIPS: dts: Add aliases node for lantiq danube serial
serial: lantiq: Get serial id from dts
serial: lantiq: Change ltq_w32_mask to asc_update_bits
MIPS: lantiq: Unselect SWAP_IO_SPACE when LANTIQ is selected
serial: lantiq: Use readl/writel instead of ltq_r32/ltq_w32
serial: lantiq: Rename fpiclk to freqclk
serial: lantiq: Replace clk_enable/clk_disable with clk generic API
serial: lantiq: Add CCF support
serial: lantiq: Reorder the head files
include: Add lantiq.h in include/linux/
serial: lantiq: Replace lantiq_soc.h with lantiq.h
serial: lantiq: Change init_lqasc to static declaration
dt-bindings: serial: lantiq: Add optional properties for CCF
.../devicetree/bindings/serial/lantiq_asc.txt | 15 +++
arch/mips/Kconfig | 1 -
arch/mips/boot/dts/lantiq/danube.dtsi | 42 +++---
arch/mips/boot/dts/lantiq/easy50712.dts | 18 ++-
drivers/tty/serial/lantiq.c | 145 ++++++++++++---------
include/linux/lantiq.h | 23 ++++
6 files changed, 155 insertions(+), 89 deletions(-)
create mode 100644 include/linux/lantiq.h
--
2.11.0
^ permalink raw reply
* Re: [PATCH 0/2] gpiolib: Fix issues introduced by fast bitmap processing path
From: Marek Szyprowski @ 2018-09-24 9:43 UTC (permalink / raw)
To: Janusz Krzysztofik, Linus Walleij
Cc: Jonathan Corbet, Miguel Ojeda Sandonis, Peter Korsgaard,
Peter Rosin, Ulf Hansson, Andrew Lunn, Florian Fainelli,
David S. Miller, Dominik Brodowski, Greg Kroah-Hartman,
Kishon Vijay Abraham I, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, Hartmut Knaack, Peter Meerwald-Stadler,
Jiri Slaby, Willy Tarreau, Geert Uytterhoeven
In-Reply-To: <20180923235336.22148-1-jmkrzyszt@gmail.com>
Hi Janusz,
On 2018-09-24 01:53, Janusz Krzysztofik wrote:
> While investigating possible reasons of GPIO fast bitmap processing
> related boot hang on Samsung Snow Chromebook, reported by Marek
> Szyprowski (thanks!), I've discovered one coding bug, addressed by
> PATCH 1/2 of this series, and one potential regression introduced at
> design level of the solution, hopefully fixed by PATCH 2/2. See
> commit messages for details.
>
> Janusz Krzysztofik (2):
> gpiolib: Fix missing updates of bitmap index
> gpiolib: Fix array members of same chip processed separately
>
> The fixes should resolve the boot hang observed by Marek, however the
> second change excludes that particular case from fast bitmap processing
> and restores the old behaviour.
I confirm, that the above 2 patches fixes boot issue on Samsung Snow
Chromebook with next-20180920.
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Hence, it is possible still another
> issue which have had an influence on that boot hang exists in the code.
> In order to fully verify the fix, it would have to be tested on a
> platform where an array of GPIO descriptors is used which starts from
> at least two consecutive pins of one GPIO chip in hardware order,
> starting ftom 0, followed by one or more pins belonging to other
> chip(s).
>
> In order to verify if separate calls to .set() chip callback for each
> pin instead of one call to .set_multiple() is actually the reason of
> boot hang on Samsung Snow Chromebook, the affected driver -
> drivers/mmc/core/pwrseq_simple.c - would have to be temporarily
> modified for testing purposes so it calls gpiod_set_value() for each
> pin instead of gpiod_set_array_value() for all of them. If that would
> also result in boot hang, we could be sure the issue was really the
> one addressed by the second fix. Marek, could you please try to
> perform such test?
Yes, I've just tested next-20180920 only with the first patch from this
patchset and the mentioned change to drivers/mmc/core/pwrseq_simple.c.
It boots fine, so indeed the issue is in handling of arrays of gpios.
Just to be sure I did it right, this is my change to the mentioned file:
diff --git a/drivers/mmc/core/pwrseq_simple.c
b/drivers/mmc/core/pwrseq_simple.c
index 7f882a2bb872..9397dc1f2e38 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -38,16 +38,11 @@ static void mmc_pwrseq_simple_set_gpios_value(struct
mmc_pwrseq_simple *pwrseq,
int value)
{
struct gpio_descs *reset_gpios = pwrseq->reset_gpios;
+ int i;
- if (!IS_ERR(reset_gpios)) {
- DECLARE_BITMAP(values, BITS_PER_TYPE(value));
- int nvalues = reset_gpios->ndescs;
-
- values[0] = value;
-
- gpiod_set_array_value_cansleep(nvalues, reset_gpios->desc,
- reset_gpios->info, values);
- }
+ if (!IS_ERR(reset_gpios))
+ for (i = 0; i < reset_gpios->ndescs; i++)
+ gpiod_set_value_cansleep(reset_gpios->desc[i], value);
}
static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply related
* Re: [PATCH 2/2] gpiolib: Fix array members of same chip processed separately
From: Linus Walleij @ 2018-09-24 8:13 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Jonathan Corbet, Miguel Ojeda Sandonis, Peter Korsgaard,
Peter Rosin, Ulf Hansson, Andrew Lunn, Florian Fainelli,
David S. Miller, Dominik Brodowski, Greg KH, kishon,
Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Hartmut Knaack, Peter Meerwald, Jiri Slaby, Willy Tarreau,
Geert Uytterhoeven, Sebastien Bourdelin
In-Reply-To: <20180923235336.22148-3-jmkrzyszt@gmail.com>
On Mon, Sep 24, 2018 at 1:52 AM Janusz Krzysztofik <jmkrzyszt@gmail.com> wrote:
> New code introduced by commit bf9346f5d47b ("gpiolib: Identify arrays
> matching GPIO hardware") forcibly tries to find an array member which
> has its array index number equal to its hardware pin number and set
> up an array info for possible fast bitmap processing of all arrray
> pins belonging to that chip which also satisfy that numbering rule.
>
> Depending on array content, it may happen that consecutive array
> members which belong to the same chip but don't have array indexes
> equal to their pin hardware numbers will be split into groups, some of
> them processed together via the fast bitmap path, and rest of them
> separetely. However, applications may expect all those pins being
> processed together with a single call to .set_multiple() chip callback,
> like that was done before the change.
>
> Limit applicability of fast bitmap processing path to cases where all
> pins of consecutive array members starting from 0 which belong to the
> same chip have their hardware numbers equal to their corresponding
> array indexes. That should still speed up processing of applications
> using whole GPIO banks as I/O ports, while not breaking simultaneous
> manipulation of consecutive pins of the same chip which don't follow
> the equal numbering rule.
>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Patch applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] gpiolib: Fix missing updates of bitmap index
From: Linus Walleij @ 2018-09-24 8:11 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Jonathan Corbet, Miguel Ojeda Sandonis, Peter Korsgaard,
Peter Rosin, Ulf Hansson, Andrew Lunn, Florian Fainelli,
David S. Miller, Dominik Brodowski, Greg KH, kishon,
Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Hartmut Knaack, Peter Meerwald, Jiri Slaby, Willy Tarreau,
Geert Uytterhoeven, Sebastien Bourdelin
In-Reply-To: <20180923235336.22148-2-jmkrzyszt@gmail.com>
On Mon, Sep 24, 2018 at 1:52 AM Janusz Krzysztofik <jmkrzyszt@gmail.com> wrote:
> In new code introduced by commit b17566a6b08b ("gpiolib: Implement fast
> processing path in get/set array"), bitmap index is not updated with
> next found zero bit position as it should while skipping over pins
> already processed via fast bitmap path, possibly resulting in an
> infinite loop. Fix it.
>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Patch applied!
Thanks for working on getting this into shape!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [RESEND PATCH v3 2/2] serial: uartps: Change uart ID port allocation
From: Geert Uytterhoeven @ 2018-09-24 7:37 UTC (permalink / raw)
To: Michal Simek
Cc: Linux Kernel Mailing List, Michal Simek, Greg KH, Jiri Slaby,
open list:SERIAL DRIVERS, Linux ARM
In-Reply-To: <39e840d1f727fe6338ea14b882ca9bf831f53e32.1537443710.git.michal.simek@xilinx.com>
Hi Michal,
On Thu, Sep 20, 2018 at 1:42 PM Michal Simek <michal.simek@xilinx.com> wrote:
> For IPs which have alias algorightm all the time using that alias and
> minor number. It means serial20 alias ends up as ttyPS20.
>
> If alias is not setup for probed IP instance the first unused position is
> used but that needs to be checked if it is really empty because another
> instance doesn't need to be probed at that time. of_alias_get_alias_list()
> fills alias bitmap which exactly shows which ID is free.
> If alias pointing to different not compatible IP, it is free to use.
>
> cdns_get_id() call is placed below structure allocation to simplify
> error path.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
JFTR, for sh-sci, I used a different approach, as all ports in the static DTB
can have an alias (if aliases are needed at all), and only DT overlays cannot
have them. Cfr. commit 7678f4c20fa7670f ("serial: sh-sci: Add support for
dynamic instances").
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
* [PATCH 2/2] gpiolib: Fix array members of same chip processed separately
From: Janusz Krzysztofik @ 2018-09-23 23:53 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Corbet, Miguel Ojeda Sandonis, Peter Korsgaard,
Peter Rosin, Ulf Hansson, Andrew Lunn, Florian Fainelli,
David S. Miller, Dominik Brodowski, Greg Kroah-Hartman,
Kishon Vijay Abraham I, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, Hartmut Knaack, Peter Meerwald-Stadler,
Jiri Slaby, Willy Tarreau, Geert Uytterhoeven
In-Reply-To: <20180923235336.22148-1-jmkrzyszt@gmail.com>
New code introduced by commit bf9346f5d47b ("gpiolib: Identify arrays
matching GPIO hardware") forcibly tries to find an array member which
has its array index number equal to its hardware pin number and set
up an array info for possible fast bitmap processing of all arrray
pins belonging to that chip which also satisfy that numbering rule.
Depending on array content, it may happen that consecutive array
members which belong to the same chip but don't have array indexes
equal to their pin hardware numbers will be split into groups, some of
them processed together via the fast bitmap path, and rest of them
separetely. However, applications may expect all those pins being
processed together with a single call to .set_multiple() chip callback,
like that was done before the change.
Limit applicability of fast bitmap processing path to cases where all
pins of consecutive array members starting from 0 which belong to the
same chip have their hardware numbers equal to their corresponding
array indexes. That should still speed up processing of applications
using whole GPIO banks as I/O ports, while not breaking simultaneous
manipulation of consecutive pins of the same chip which don't follow
the equal numbering rule.
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
---
Documentation/driver-api/gpio/board.rst | 19 +++++++++++++-----
drivers/gpio/gpiolib.c | 35 +++++++++++++++++++++++----------
2 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/Documentation/driver-api/gpio/board.rst b/Documentation/driver-api/gpio/board.rst
index c66821e033c2..a0f294e2e250 100644
--- a/Documentation/driver-api/gpio/board.rst
+++ b/Documentation/driver-api/gpio/board.rst
@@ -202,9 +202,18 @@ mapped to the device determines if the array qualifies for fast bitmap
processing. If yes, a bitmap is passed over get/set array functions directly
between a caller and a respective .get/set_multiple() callback of a GPIO chip.
-In order to qualify for fast bitmap processing, the pin mapping must meet the
+In order to qualify for fast bitmap processing, the array must meet the
following requirements:
-- it must belong to the same chip as other 'fast' pins of the function,
-- its index within the function must match its hardware number within the chip.
-
-Open drain and open source pins are excluded from fast bitmap output processing.
+- pin hardware number of array member 0 must also be 0,
+- pin hardware numbers of consecutive array members which belong to the same
+ chip as member 0 does must also match their array indexes.
+
+Otherwise fast bitmap processing path is not used in order to avoid consecutive
+pins which belong to the same chip but are not in hardware order being processed
+separately.
+
+If the array applies for fast bitmap processing path, pins which belong to
+different chips than member 0 does, as well as those with indexes different from
+their hardware pin numbers, are excluded from the fast path, both input and
+output. Moreover, open drain and open source pins are excluded from fast bitmap
+output processing.
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 7d9536a79a66..6ae13e3e05f1 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -4376,11 +4376,10 @@ struct gpio_descs *__must_check gpiod_get_array(struct device *dev,
chip = gpiod_to_chip(desc);
/*
- * Select a chip of first array member
- * whose index matches its pin hardware number
- * as a candidate for fast bitmap processing.
+ * If pin hardware number of array member 0 is also 0, select
+ * its chip as a candidate for fast bitmap processing path.
*/
- if (!array_info && gpio_chip_hwgpio(desc) == descs->ndescs) {
+ if (descs->ndescs == 0 && gpio_chip_hwgpio(desc) == 0) {
struct gpio_descs *array;
bitmap_size = BITS_TO_LONGS(chip->ngpio > count ?
@@ -4414,14 +4413,30 @@ struct gpio_descs *__must_check gpiod_get_array(struct device *dev,
count - descs->ndescs);
descs->info = array_info;
}
- /*
- * Unmark members which don't qualify for fast bitmap
- * processing (different chip, not in hardware order)
- */
- if (array_info && (chip != array_info->chip ||
- gpio_chip_hwgpio(desc) != descs->ndescs)) {
+ /* Unmark array members which don't belong to the 'fast' chip */
+ if (array_info && array_info->chip != chip) {
__clear_bit(descs->ndescs, array_info->get_mask);
__clear_bit(descs->ndescs, array_info->set_mask);
+ }
+ /*
+ * Detect array members which belong to the 'fast' chip
+ * but their pins are not in hardware order.
+ */
+ else if (array_info &&
+ gpio_chip_hwgpio(desc) != descs->ndescs) {
+ /*
+ * Don't use fast path if all array members processed so
+ * far belong to the same chip as this one but its pin
+ * hardware number is different from its array index.
+ */
+ if (bitmap_full(array_info->get_mask, descs->ndescs)) {
+ array_info = NULL;
+ } else {
+ __clear_bit(descs->ndescs,
+ array_info->get_mask);
+ __clear_bit(descs->ndescs,
+ array_info->set_mask);
+ }
} else if (array_info) {
/* Exclude open drain or open source from fast output */
if (gpiochip_line_is_open_drain(chip, descs->ndescs) ||
--
2.16.4
^ permalink raw reply related
* [PATCH 1/2] gpiolib: Fix missing updates of bitmap index
From: Janusz Krzysztofik @ 2018-09-23 23:53 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Corbet, Miguel Ojeda Sandonis, Peter Korsgaard,
Peter Rosin, Ulf Hansson, Andrew Lunn, Florian Fainelli,
David S. Miller, Dominik Brodowski, Greg Kroah-Hartman,
Kishon Vijay Abraham I, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, Hartmut Knaack, Peter Meerwald-Stadler,
Jiri Slaby, Willy Tarreau, Geert Uytterhoeven
In-Reply-To: <20180923235336.22148-1-jmkrzyszt@gmail.com>
In new code introduced by commit b17566a6b08b ("gpiolib: Implement fast
processing path in get/set array"), bitmap index is not updated with
next found zero bit position as it should while skipping over pins
already processed via fast bitmap path, possibly resulting in an
infinite loop. Fix it.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
---
drivers/gpio/gpiolib.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index a53d17745d21..7d9536a79a66 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2880,8 +2880,8 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
__set_bit(hwgpio, mask);
if (array_info)
- find_next_zero_bit(array_info->get_mask,
- array_size, i);
+ i = find_next_zero_bit(array_info->get_mask,
+ array_size, i);
else
i++;
} while ((i < array_size) &&
@@ -2905,7 +2905,8 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
trace_gpio_value(desc_to_gpio(desc), 1, value);
if (array_info)
- find_next_zero_bit(array_info->get_mask, i, j);
+ j = find_next_zero_bit(array_info->get_mask, i,
+ j);
else
j++;
}
@@ -3192,8 +3193,8 @@ int gpiod_set_array_value_complex(bool raw, bool can_sleep,
}
if (array_info)
- find_next_zero_bit(array_info->set_mask,
- array_size, i);
+ i = find_next_zero_bit(array_info->set_mask,
+ array_size, i);
else
i++;
} while ((i < array_size) &&
--
2.16.4
^ permalink raw reply related
* [PATCH 0/2] gpiolib: Fix issues introduced by fast bitmap processing path
From: Janusz Krzysztofik @ 2018-09-23 23:53 UTC (permalink / raw)
To: Linus Walleij
Cc: Andrew Lunn, Ulf Hansson, linux-doc, Tony Lindgren,
Dominik Brodowski, Peter Rosin, netdev, linux-i2c,
Peter Meerwald-Stadler, Marek Szyprowski, devel, Florian Fainelli,
Jonathan Corbet, Janusz Krzysztofik, Krzysztof Kozlowski,
Kishon Vijay Abraham I, linux-iio, Peter Korsgaard,
Geert Uytterhoeven, linux-serial, Jiri Slaby, Michael Hennerich,
Uwe Kleine-König, linux-gpio
In-Reply-To: <2785169.v6aIfS3K2k@z50>
While investigating possible reasons of GPIO fast bitmap processing
related boot hang on Samsung Snow Chromebook, reported by Marek
Szyprowski (thanks!), I've discovered one coding bug, addressed by
PATCH 1/2 of this series, and one potential regression introduced at
design level of the solution, hopefully fixed by PATCH 2/2. See
commit messages for details.
Janusz Krzysztofik (2):
gpiolib: Fix missing updates of bitmap index
gpiolib: Fix array members of same chip processed separately
The fixes should resolve the boot hang observed by Marek, however the
second change excludes that particular case from fast bitmap processing
and restores the old behaviour. Hence, it is possible still another
issue which have had an influence on that boot hang exists in the code.
In order to fully verify the fix, it would have to be tested on a
platform where an array of GPIO descriptors is used which starts from
at least two consecutive pins of one GPIO chip in hardware order,
starting ftom 0, followed by one or more pins belonging to other
chip(s).
In order to verify if separate calls to .set() chip callback for each
pin instead of one call to .set_multiple() is actually the reason of
boot hang on Samsung Snow Chromebook, the affected driver -
drivers/mmc/core/pwrseq_simple.c - would have to be temporarily
modified for testing purposes so it calls gpiod_set_value() for each
pin instead of gpiod_set_array_value() for all of them. If that would
also result in boot hang, we could be sure the issue was really the
one addressed by the second fix. Marek, could you please try to
perform such test?
Thanks,
Janusz
diffstat:
Documentation/driver-api/gpio/board.rst | 19 +++++++++----
drivers/gpio/gpiolib.c | 46 +++++++++++++++++++++-----------
2 files changed, 45 insertions(+), 20 deletions(-)
^ permalink raw reply
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Janusz Krzysztofik @ 2018-09-23 10:43 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Andrew Lunn, Ulf Hansson, linux-doc, linux-iio, Linus Walleij,
Dominik Brodowski, Peter Rosin, netdev, linux-i2c,
Peter Meerwald-Stadler, devel, Florian Fainelli, Jonathan Corbet,
Janusz Krzysztofik, Krzysztof Kozlowski, Kishon Vijay Abraham I,
Tony Lindgren, Lukas Wunner, Geert Uytterhoeven, linux-serial,
Jiri Slaby, Michael Hennerich, Uwe Kleine-König, linux-gpio
In-Reply-To: <20180921141409eucas1p190a47e2608429870d23516ee5e75c191~Wb8z_FmwI1466414664eucas1p1F@eucas1p1.samsung.com>
On Friday, September 21, 2018 4:14:06 PM CEST Marek Szyprowski wrote:
> Hi Janusz,
>
>
> On 2018-09-21 12:51, Janusz Krzysztofik wrote:
> > 2018-09-21 10:18 GMT+02:00, Marek Szyprowski <m.szyprowski@samsung.com>:
> >> On 2018-09-20 18:21, Janusz Krzysztofik wrote:
> >>> On Thursday, September 20, 2018 5:48:22 PM CEST Janusz Krzysztofik wrote:
> >>>> On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski
wrote:
> >>>>> On 2018-09-02 14:01, Janusz Krzysztofik wrote:
> >>>>>> Certain GPIO descriptor arrays returned by gpio_get_array() may
> >>>>>> contain
> >>>>>> information on direct mapping of array members to pins of a single
> >>>>>> GPIO
> >>>>>> chip in hardware order. In such cases, bitmaps of values can be
> >>>>>> passed
> >>>>>> directly from/to the chip's .get/set_multiple() callbacks without
> >>>>>> wasting time on iterations.
> >>>>>>
> >>>>>> Add respective code to gpiod_get/set_array_bitmap_complex()
functions.
> >>>>>> Pins not applicable for fast path are processed as before, skipping
> >>>>>> over the 'fast' ones.
> >>>>>>
> >>>>>> Cc: Jonathan Corbet <corbet@lwn.net>
> >>>>>> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
> >>>>> I've just noticed that this patch landed in today's linux-next. Sadly
> >>>>> it
> >>>>> breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
> >>>>> device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
> >>>>>
> >>>>> Booting hangs after detecting MMC cards. Reverting this patch fixes the
> >>>>> boot. I will try later to add some debugs and investigate it further
> >>>>> what
> >>>>> really happens when booting hangs.
> >>>> Hi Marek,
> >>>>
> >>>> Thanks for reporting. Could you please try the following fix?
> >>> Hi again,
> >>>
> >>> I realized the patch was not correct, j, not i, should be updated in
> >>> second
> >>> hunk. Please try the following one.
> >>>
> >>> Thanks,
> >>> Janusz
> >>>
> >>> >From a919c504850f6cb40e8e81267a3a37537f7c4fd4 Mon Sep 17 00:00:00 2001
> >>> From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
> >>> Date: Thu, 20 Sep 2018 17:37:21 +0200
> >>> Subject: [PATCH] gpiolib: Fix bitmap index not updated
> >>> While skipping fast path bits, bitmap index is not updated with next
> >>> found zero bit position. Fix it.
> >>>
> >>> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
> >> This one also doesn't help. A quick compare of logs with this version and
> >> a working system shows, that with your patch (and fix) there are no calls
> >> to
> >> gpx0-2 pin (which are a part of mmc pwrseq), what causes mmc failure. If
> >> you need any more information (what kind of logs will help?), let me
know.
> > There is a debug message on array_info content available at the end of
> > gpiod_get_array(), could you please activate it and post the message so
> > we can understand better what is going on?
>
> With debug enabled on next-20180919:
> [ 2.499153] pwrseq_simple mmc3_pwrseq: GPIO array info: chip=gpx0,
> size=2, get_mask=2, set_mask=2, invert_mask=2
Looks good to me, i..e., in line with what one could expect. However, ...
> On next-20180920 I get no this message and booting hangs.
>
> Same with next-20180920 + your second fix from this thread.
>
> I will try to debug this more on Monday.
>
> > On the other hand, I've had a look your device-tree configuration and
> > it looks like that specific setup won't benefit from the fast bitmap path.
> > You have pin 2 at position 0 and pin 1 at position 1 of the array.
> > Hence, the fast bitmap path covers only pin 1, and pin 2 is processed
> > by the old path with apparently buggy code for skipping over fast pins.
> >
> > As a temporary workaround, you could try to revert the order of pins in
> > your dts file (pin 1 at position 0, pin 2 at 1) and the mmc pwrseq code
> > should work for you again by taking the original old path, not skipping
> > over fast pins. Results of such check may also help us to better
> > understand and resolve the issue.
>
> Changing the order of mmc pwrseq gpio pins fixes boot hang.
Not being able to discover more coding bugs in the code modified by the series,
I'm wondering if the reason for the issue you are observing comes from the
fact both pins are no longer manipulated together within a single
.set_multiple() chip callback. I'm working on a fix which prevents from that.
Thanks,
Janusz
^ permalink raw reply
* Re: [PATCH] ARM: add serial.h and set BASE_BAUD to 0
From: Rafał Miłecki @ 2018-09-21 14:36 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Hauke Mehrtens, Greg Kroah-Hartman, Rafał Miłecki,
linux-kernel, Michal Simek, bcm-kernel-feedback-list,
linux-serial, Jiri Slaby, Eugeniy Paltsev, linux-arm-kernel
In-Reply-To: <20180921135913.GM30658@n2100.armlinux.org.uk>
On 2018-09-21 15:59, Russell King - ARM Linux wrote:
> On Thu, Sep 20, 2018 at 10:13:57PM +0200, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> For years arm has been using serial.h from asm-generic which sets
>> BASE_BAUD value to the (1843200 / 16). This is incorrect as:
>> 1) This value obviously isn't correct for all devices
>> 2) There are no device specific serial.h with
>> CONFIG_ARCH_MULTIPLATFORM
>
> This goes back a long way. The BASE_BAUD definition is the base baud
> for 8250 compatible UARTs _only_, no others.
>
> However, as of 182ead3e418a ("earlycon: Remove hardcoded port->uartclk
> initialization in of_setup_earlycon"), port->uartclk is no longer
> initialised using BASE_BAUD. As acknowledged in 814453adea7d
> ("earlycon: Initialize port->uartclk based on clock-frequency
> property")
> the initialisation using BASE_BAUD was bogus, and there is now the
> clock-frequency DT property which should be present to set this up.
Thanks a lot for looking at that. I was not aware of the commit
182ead3e418a ("earlycon: Remove hardcoded port->uartclk initialization
in of_setup_earlycon"), too bad it wasn't marked for stable.
I simply assumed that
port->uartclk = BASE_BAUD * 16;
is correct and that has poisoned all my further reasoning.
I've just confirmed that backporting 182ead3e418a to the 4.14 fixes the
problem for me (it results in the same 8250_early.c behavior as setting
BASE_BAUD to 0).
I'm planning to backport both:
182ead3e418a ("earlycon: Remove hardcoded port->uartclk initialization
in of_setup_earlycon")
814453adea7d ("earlycon: Initialize port->uartclk based on
clock-frequency property")
to 4.14+ as they fix regression triggered (not to say "caused") by the
commit 31cb9a8575ca0 ("earlycon: initialise baud field of earlycon
device structure").
Please DROP my serial.h patch and thanks again.
> Now, setting BASE_BAUD to zero as per your patch will break the
> 8250 serial driver - this relies on BASE_BAUD being set to the
> current value, and yes, ARM hardware that uses this will break. So
> this is not a solution.
>
> The only solution is that BASE_BAUD must not be abused - it must not
> be used by non-8250 hardware, and thankfully there are already
> solutions in the kernel (such as clock-frequency) to allow the clock
> rate to be specified.
Somehow my serial console kept working with BASE_BAUD set to 0. I'm not
sure why.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Marek Szyprowski @ 2018-09-21 14:14 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Linus Walleij, Jonathan Corbet, Miguel Ojeda Sandonis,
Peter Korsgaard, Peter Rosin, Ulf Hansson, Andrew Lunn,
Florian Fainelli, David S. Miller, Dominik Brodowski,
Greg Kroah-Hartman, Kishon Vijay Abraham I, Lars-Peter Clausen,
Michael Hennerich, Jonathan Cameron, Hartmut Knaack,
Peter Meerwald-Stadler, Jiri Slaby, Willy Tarreau
In-Reply-To: <CAGfqbt7xJxGbq3oOJp9S0Sg7Z9=T6Dy52MDNWSDdsU==kPt1KQ@mail.gmail.com>
Hi Janusz,
On 2018-09-21 12:51, Janusz Krzysztofik wrote:
> 2018-09-21 10:18 GMT+02:00, Marek Szyprowski <m.szyprowski@samsung.com>:
>> On 2018-09-20 18:21, Janusz Krzysztofik wrote:
>>> On Thursday, September 20, 2018 5:48:22 PM CEST Janusz Krzysztofik wrote:
>>>> On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski wrote:
>>>>> On 2018-09-02 14:01, Janusz Krzysztofik wrote:
>>>>>> Certain GPIO descriptor arrays returned by gpio_get_array() may
>>>>>> contain
>>>>>> information on direct mapping of array members to pins of a single
>>>>>> GPIO
>>>>>> chip in hardware order. In such cases, bitmaps of values can be
>>>>>> passed
>>>>>> directly from/to the chip's .get/set_multiple() callbacks without
>>>>>> wasting time on iterations.
>>>>>>
>>>>>> Add respective code to gpiod_get/set_array_bitmap_complex() functions.
>>>>>> Pins not applicable for fast path are processed as before, skipping
>>>>>> over the 'fast' ones.
>>>>>>
>>>>>> Cc: Jonathan Corbet <corbet@lwn.net>
>>>>>> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>>>>> I've just noticed that this patch landed in today's linux-next. Sadly
>>>>> it
>>>>> breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
>>>>> device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
>>>>>
>>>>> Booting hangs after detecting MMC cards. Reverting this patch fixes the
>>>>> boot. I will try later to add some debugs and investigate it further
>>>>> what
>>>>> really happens when booting hangs.
>>>> Hi Marek,
>>>>
>>>> Thanks for reporting. Could you please try the following fix?
>>> Hi again,
>>>
>>> I realized the patch was not correct, j, not i, should be updated in
>>> second
>>> hunk. Please try the following one.
>>>
>>> Thanks,
>>> Janusz
>>>
>>> >From a919c504850f6cb40e8e81267a3a37537f7c4fd4 Mon Sep 17 00:00:00 2001
>>> From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>>> Date: Thu, 20 Sep 2018 17:37:21 +0200
>>> Subject: [PATCH] gpiolib: Fix bitmap index not updated
>>> While skipping fast path bits, bitmap index is not updated with next
>>> found zero bit position. Fix it.
>>>
>>> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>> This one also doesn't help. A quick compare of logs with this version and
>> a working system shows, that with your patch (and fix) there are no calls
>> to
>> gpx0-2 pin (which are a part of mmc pwrseq), what causes mmc failure. If
>> you need any more information (what kind of logs will help?), let me know.
> There is a debug message on array_info content available at the end of
> gpiod_get_array(), could you please activate it and post the message so
> we can understand better what is going on?
With debug enabled on next-20180919:
[ 2.499153] pwrseq_simple mmc3_pwrseq: GPIO array info: chip=gpx0,
size=2, get_mask=2, set_mask=2, invert_mask=2
On next-20180920 I get no this message and booting hangs.
Same with next-20180920 + your second fix from this thread.
I will try to debug this more on Monday.
> On the other hand, I've had a look your device-tree configuration and
> it looks like that specific setup won't benefit from the fast bitmap path.
> You have pin 2 at position 0 and pin 1 at position 1 of the array.
> Hence, the fast bitmap path covers only pin 1, and pin 2 is processed
> by the old path with apparently buggy code for skipping over fast pins.
>
> As a temporary workaround, you could try to revert the order of pins in
> your dts file (pin 1 at position 0, pin 2 at 1) and the mmc pwrseq code
> should work for you again by taking the original old path, not skipping
> over fast pins. Results of such check may also help us to better
> understand and resolve the issue.
Changing the order of mmc pwrseq gpio pins fixes boot hang.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH] ARM: add serial.h and set BASE_BAUD to 0
From: Russell King - ARM Linux @ 2018-09-21 13:59 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-arm-kernel, linux-kernel, Eugeniy Paltsev,
Greg Kroah-Hartman, Jiri Slaby, linux-serial, Hauke Mehrtens,
bcm-kernel-feedback-list, Rafał Miłecki
In-Reply-To: <20180920201357.16426-1-zajec5@gmail.com>
On Thu, Sep 20, 2018 at 10:13:57PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> For years arm has been using serial.h from asm-generic which sets
> BASE_BAUD value to the (1843200 / 16). This is incorrect as:
> 1) This value obviously isn't correct for all devices
> 2) There are no device specific serial.h with CONFIG_ARCH_MULTIPLATFORM
This goes back a long way. The BASE_BAUD definition is the base baud
for 8250 compatible UARTs _only_, no others.
However, as of 182ead3e418a ("earlycon: Remove hardcoded port->uartclk
initialization in of_setup_earlycon"), port->uartclk is no longer
initialised using BASE_BAUD. As acknowledged in 814453adea7d
("earlycon: Initialize port->uartclk based on clock-frequency property")
the initialisation using BASE_BAUD was bogus, and there is now the
clock-frequency DT property which should be present to set this up.
Now, setting BASE_BAUD to zero as per your patch will break the
8250 serial driver - this relies on BASE_BAUD being set to the
current value, and yes, ARM hardware that uses this will break. So
this is not a solution.
The only solution is that BASE_BAUD must not be abused - it must not
be used by non-8250 hardware, and thankfully there are already
solutions in the kernel (such as clock-frequency) to allow the clock
rate to be specified.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Janusz Krzysztofik @ 2018-09-21 11:26 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Linus Walleij, Jonathan Corbet, Miguel Ojeda Sandonis,
Peter Korsgaard, Peter Rosin, Ulf Hansson, Andrew Lunn,
Florian Fainelli, David S. Miller, Dominik Brodowski,
Greg Kroah-Hartman, Kishon Vijay Abraham I, Lars-Peter Clausen,
Michael Hennerich, Jonathan Cameron, Hartmut Knaack,
Peter Meerwald-Stadler, Jiri Slaby, Willy Tarreau
In-Reply-To: <CAGfqbt7xJxGbq3oOJp9S0Sg7Z9=T6Dy52MDNWSDdsU==kPt1KQ@mail.gmail.com>
Hi Marek,
2018-09-21 12:51 GMT+02:00, Janusz Krzysztofik <jmkrzyszt@gmail.com>:
> Hi Marek,
>
> 2018-09-21 10:18 GMT+02:00, Marek Szyprowski <m.szyprowski@samsung.com>:
>> Hi Janusz,
>>
>> On 2018-09-20 18:21, Janusz Krzysztofik wrote:
>>> On Thursday, September 20, 2018 5:48:22 PM CEST Janusz Krzysztofik
>>> wrote:
>>>> On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski
>>>> wrote:
>>>>> On 2018-09-02 14:01, Janusz Krzysztofik wrote:
>>>>>> Certain GPIO descriptor arrays returned by gpio_get_array() may
>>>>>> contain
>>>>>> information on direct mapping of array members to pins of a single
>>>>>> GPIO
>>>>>> chip in hardware order. In such cases, bitmaps of values can be
>>>>>> passed
>>>>>> directly from/to the chip's .get/set_multiple() callbacks without
>>>>>> wasting time on iterations.
>>>>>>
>>>>>> Add respective code to gpiod_get/set_array_bitmap_complex()
>>>>>> functions.
>>>>>> Pins not applicable for fast path are processed as before, skipping
>>>>>> over the 'fast' ones.
>>>>>>
>>>>>> Cc: Jonathan Corbet <corbet@lwn.net>
>>>>>> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>>>>> I've just noticed that this patch landed in today's linux-next. Sadly
>>>>> it
>>>>> breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
>>>>> device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
>>>>>
>>>>> Booting hangs after detecting MMC cards. Reverting this patch fixes
>>>>> the
>>>>> boot. I will try later to add some debugs and investigate it further
>>>>> what
>>>>> really happens when booting hangs.
>>>> Hi Marek,
>>>>
>>>> Thanks for reporting. Could you please try the following fix?
>>> Hi again,
>>>
>>> I realized the patch was not correct, j, not i, should be updated in
>>> second
>>> hunk. Please try the following one.
>>>
>>> Thanks,
>>> Janusz
>>>
>>> >From a919c504850f6cb40e8e81267a3a37537f7c4fd4 Mon Sep 17 00:00:00 2001
>>> From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>>> Date: Thu, 20 Sep 2018 17:37:21 +0200
>>> Subject: [PATCH] gpiolib: Fix bitmap index not updated
>>> While skipping fast path bits, bitmap index is not updated with next
>>> found zero bit position. Fix it.
>>>
>>> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>>
>> This one also doesn't help. A quick compare of logs with this version and
>> a working system shows, that with your patch (and fix) there are no calls
>> to
>> gpx0-2 pin (which are a part of mmc pwrseq), what causes mmc failure. If
>> you need any more information (what kind of logs will help?), let me
>> know.
One more question. You said before that booting hanged after detecting MMC
cards. Without the fix, I could imagine it keeps iterating with index not
updated and simply never returns from gpiod_get/set_array_bitmap_complex().
Is the behaviour you observe the same with the fix applied?
Thanks,
Janusz
> There is a debug message on array_info content available at the end of
> gpiod_get_array(), could you please activate it and post the message so
> we can understand better what is going on?
>
> On the other hand, I've had a look your device-tree configuration and
> it looks like that specific setup won't benefit from the fast bitmap path.
> You have pin 2 at position 0 and pin 1 at position 1 of the array.
> Hence, the fast bitmap path covers only pin 1, and pin 2 is processed
> by the old path with apparently buggy code for skipping over fast pins.
>
> As a temporary workaround, you could try to revert the order of pins in
> your dts file (pin 1 at position 0, pin 2 at 1) and the mmc pwrseq code
> should work for you again by taking the original old path, not skipping
> over fast pins. Results of such check may also help us to better
> understand and resolve the issue.
>
> Thanks,
> Janusz
>
>>
>>> ---
>>> drivers/gpio/gpiolib.c | 7 ++++---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>>> index a53d17745d21..369bdd358fcc 100644
>>> --- a/drivers/gpio/gpiolib.c
>>> +++ b/drivers/gpio/gpiolib.c
>>> @@ -2880,7 +2880,7 @@ int gpiod_get_array_value_complex(bool raw, bool
>>> can_sleep,
>>> __set_bit(hwgpio, mask);
>>>
>>> if (array_info)
>>> - find_next_zero_bit(array_info->get_mask,
>>> + i = find_next_zero_bit(array_info->get_mask,
>>> array_size, i);
>>> else
>>> i++;
>>> @@ -2905,7 +2905,8 @@ int gpiod_get_array_value_complex(bool raw, bool
>>> can_sleep,
>>> trace_gpio_value(desc_to_gpio(desc), 1, value);
>>>
>>> if (array_info)
>>> - find_next_zero_bit(array_info->get_mask, i, j);
>>> + j = find_next_zero_bit(array_info->get_mask, i,
>>> + j);
>>> else
>>> j++;
>>> }
>>> @@ -3192,7 +3193,7 @@ int gpiod_set_array_value_complex(bool raw, bool
>>> can_sleep,
>>> }
>>>
>>> if (array_info)
>>> - find_next_zero_bit(array_info->set_mask,
>>> + i = find_next_zero_bit(array_info->set_mask,
>>> array_size, i);
>>> else
>>> i++;
>>
>> Best regards
>> --
>> Marek Szyprowski, PhD
>> Samsung R&D Institute Poland
>>
>>
>
^ permalink raw reply
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Janusz Krzysztofik @ 2018-09-21 10:51 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Andrew Lunn, Ulf Hansson, linux-doc, linux-iio, Linus Walleij,
Dominik Brodowski, Peter Rosin, netdev, linux-i2c,
Peter Meerwald-Stadler, devel, Florian Fainelli, Jonathan Corbet,
Krzysztof Kozlowski, Kishon Vijay Abraham I, Tony Lindgren,
Lukas Wunner, Geert Uytterhoeven, linux-serial, Jiri Slaby,
Michael Hennerich, Uwe Kleine-König, linux-gpio,
Russell King
In-Reply-To: <20180921081806eucas1p182d4646e8510b5f0356214af7edba11e~WXF8Ptw4M0970709707eucas1p1p@eucas1p1.samsung.com>
Hi Marek,
2018-09-21 10:18 GMT+02:00, Marek Szyprowski <m.szyprowski@samsung.com>:
> Hi Janusz,
>
> On 2018-09-20 18:21, Janusz Krzysztofik wrote:
>> On Thursday, September 20, 2018 5:48:22 PM CEST Janusz Krzysztofik wrote:
>>> On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski wrote:
>>>> On 2018-09-02 14:01, Janusz Krzysztofik wrote:
>>>>> Certain GPIO descriptor arrays returned by gpio_get_array() may
>>>>> contain
>>>>> information on direct mapping of array members to pins of a single
>>>>> GPIO
>>>>> chip in hardware order. In such cases, bitmaps of values can be
>>>>> passed
>>>>> directly from/to the chip's .get/set_multiple() callbacks without
>>>>> wasting time on iterations.
>>>>>
>>>>> Add respective code to gpiod_get/set_array_bitmap_complex() functions.
>>>>> Pins not applicable for fast path are processed as before, skipping
>>>>> over the 'fast' ones.
>>>>>
>>>>> Cc: Jonathan Corbet <corbet@lwn.net>
>>>>> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>>>> I've just noticed that this patch landed in today's linux-next. Sadly
>>>> it
>>>> breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
>>>> device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
>>>>
>>>> Booting hangs after detecting MMC cards. Reverting this patch fixes the
>>>> boot. I will try later to add some debugs and investigate it further
>>>> what
>>>> really happens when booting hangs.
>>> Hi Marek,
>>>
>>> Thanks for reporting. Could you please try the following fix?
>> Hi again,
>>
>> I realized the patch was not correct, j, not i, should be updated in
>> second
>> hunk. Please try the following one.
>>
>> Thanks,
>> Janusz
>>
>> >From a919c504850f6cb40e8e81267a3a37537f7c4fd4 Mon Sep 17 00:00:00 2001
>> From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>> Date: Thu, 20 Sep 2018 17:37:21 +0200
>> Subject: [PATCH] gpiolib: Fix bitmap index not updated
>> While skipping fast path bits, bitmap index is not updated with next
>> found zero bit position. Fix it.
>>
>> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>
> This one also doesn't help. A quick compare of logs with this version and
> a working system shows, that with your patch (and fix) there are no calls
> to
> gpx0-2 pin (which are a part of mmc pwrseq), what causes mmc failure. If
> you need any more information (what kind of logs will help?), let me know.
There is a debug message on array_info content available at the end of
gpiod_get_array(), could you please activate it and post the message so
we can understand better what is going on?
On the other hand, I've had a look your device-tree configuration and
it looks like that specific setup won't benefit from the fast bitmap path.
You have pin 2 at position 0 and pin 1 at position 1 of the array.
Hence, the fast bitmap path covers only pin 1, and pin 2 is processed
by the old path with apparently buggy code for skipping over fast pins.
As a temporary workaround, you could try to revert the order of pins in
your dts file (pin 1 at position 0, pin 2 at 1) and the mmc pwrseq code
should work for you again by taking the original old path, not skipping
over fast pins. Results of such check may also help us to better
understand and resolve the issue.
Thanks,
Janusz
>
>> ---
>> drivers/gpio/gpiolib.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>> index a53d17745d21..369bdd358fcc 100644
>> --- a/drivers/gpio/gpiolib.c
>> +++ b/drivers/gpio/gpiolib.c
>> @@ -2880,7 +2880,7 @@ int gpiod_get_array_value_complex(bool raw, bool
>> can_sleep,
>> __set_bit(hwgpio, mask);
>>
>> if (array_info)
>> - find_next_zero_bit(array_info->get_mask,
>> + i = find_next_zero_bit(array_info->get_mask,
>> array_size, i);
>> else
>> i++;
>> @@ -2905,7 +2905,8 @@ int gpiod_get_array_value_complex(bool raw, bool
>> can_sleep,
>> trace_gpio_value(desc_to_gpio(desc), 1, value);
>>
>> if (array_info)
>> - find_next_zero_bit(array_info->get_mask, i, j);
>> + j = find_next_zero_bit(array_info->get_mask, i,
>> + j);
>> else
>> j++;
>> }
>> @@ -3192,7 +3193,7 @@ int gpiod_set_array_value_complex(bool raw, bool
>> can_sleep,
>> }
>>
>> if (array_info)
>> - find_next_zero_bit(array_info->set_mask,
>> + i = find_next_zero_bit(array_info->set_mask,
>> array_size, i);
>> else
>> i++;
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
>
^ permalink raw reply
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Marek Szyprowski @ 2018-09-21 8:18 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Andrew Lunn, Ulf Hansson, linux-doc, linux-iio, Linus Walleij,
Dominik Brodowski, Peter Rosin, netdev, linux-i2c,
Peter Meerwald-Stadler, devel, Florian Fainelli, Jonathan Corbet,
Krzysztof Kozlowski, Kishon Vijay Abraham I, Tony Lindgren,
Lukas Wunner, Geert Uytterhoeven, linux-serial, Jiri Slaby,
Michael Hennerich, Uwe Kleine-König, linux-gpio,
Russell King
In-Reply-To: <15226900.TQMLYV7PZ0@z50>
Hi Janusz,
On 2018-09-20 18:21, Janusz Krzysztofik wrote:
> On Thursday, September 20, 2018 5:48:22 PM CEST Janusz Krzysztofik wrote:
>> On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski wrote:
>>> On 2018-09-02 14:01, Janusz Krzysztofik wrote:
>>>> Certain GPIO descriptor arrays returned by gpio_get_array() may contain
>>>> information on direct mapping of array members to pins of a single GPIO
>>>> chip in hardware order. In such cases, bitmaps of values can be passed
>>>> directly from/to the chip's .get/set_multiple() callbacks without
>>>> wasting time on iterations.
>>>>
>>>> Add respective code to gpiod_get/set_array_bitmap_complex() functions.
>>>> Pins not applicable for fast path are processed as before, skipping
>>>> over the 'fast' ones.
>>>>
>>>> Cc: Jonathan Corbet <corbet@lwn.net>
>>>> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>>> I've just noticed that this patch landed in today's linux-next. Sadly it
>>> breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
>>> device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
>>>
>>> Booting hangs after detecting MMC cards. Reverting this patch fixes the
>>> boot. I will try later to add some debugs and investigate it further what
>>> really happens when booting hangs.
>> Hi Marek,
>>
>> Thanks for reporting. Could you please try the following fix?
> Hi again,
>
> I realized the patch was not correct, j, not i, should be updated in second
> hunk. Please try the following one.
>
> Thanks,
> Janusz
>
> >From a919c504850f6cb40e8e81267a3a37537f7c4fd4 Mon Sep 17 00:00:00 2001
> From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
> Date: Thu, 20 Sep 2018 17:37:21 +0200
> Subject: [PATCH] gpiolib: Fix bitmap index not updated
> While skipping fast path bits, bitmap index is not updated with next
> found zero bit position. Fix it.
>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
This one also doesn't help. A quick compare of logs with this version and
a working system shows, that with your patch (and fix) there are no calls to
gpx0-2 pin (which are a part of mmc pwrseq), what causes mmc failure. If
you need any more information (what kind of logs will help?), let me know.
> ---
> drivers/gpio/gpiolib.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index a53d17745d21..369bdd358fcc 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -2880,7 +2880,7 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
> __set_bit(hwgpio, mask);
>
> if (array_info)
> - find_next_zero_bit(array_info->get_mask,
> + i = find_next_zero_bit(array_info->get_mask,
> array_size, i);
> else
> i++;
> @@ -2905,7 +2905,8 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
> trace_gpio_value(desc_to_gpio(desc), 1, value);
>
> if (array_info)
> - find_next_zero_bit(array_info->get_mask, i, j);
> + j = find_next_zero_bit(array_info->get_mask, i,
> + j);
> else
> j++;
> }
> @@ -3192,7 +3193,7 @@ int gpiod_set_array_value_complex(bool raw, bool can_sleep,
> }
>
> if (array_info)
> - find_next_zero_bit(array_info->set_mask,
> + i = find_next_zero_bit(array_info->set_mask,
> array_size, i);
> else
> i++;
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* RE: [PATCH] serial: imx: restore handshaking irq for imx1
From: Andy Duan @ 2018-09-21 1:18 UTC (permalink / raw)
To: Uwe Kleine-König, Greg Kroah-Hartman, Jiri Slaby
Cc: YueHaibing, linux-serial@vger.kernel.org, kernel@pengutronix.de,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
Leonard Crestez
In-Reply-To: <20180920121117.19041-1-u.kleine-koenig@pengutronix.de>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Sent: 2018年9月20日 20:11
> Back in 2015 when irda was dropped from the driver imx1 was broken.
> This change reintroduces the support for the third interrupt of the UART.
>
> Fixes: afe9cbb1a6ad ("serial: imx: drop support for IRDA")
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/tty/serial/imx.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index
> 4e853570ea80..554a69db1bca 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -2350,6 +2350,14 @@ static int imx_uart_probe(struct
> platform_device *pdev)
> ret);
> return ret;
> }
> +
> + ret = devm_request_irq(&pdev->dev, rtsirq, imx_uart_rtsint, 0,
> + dev_name(&pdev->dev), sport);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to request rts irq: %d\n",
> + ret);
> + return ret;
> + }
> } else {
> ret = devm_request_irq(&pdev->dev, rxirq, imx_uart_int, 0,
> dev_name(&pdev->dev), sport);
> --
> 2.18.0
Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
^ permalink raw reply
* [PATCH] ARM: add serial.h and set BASE_BAUD to 0
From: Rafał Miłecki @ 2018-09-20 20:13 UTC (permalink / raw)
To: Russell King
Cc: linux-arm-kernel, linux-kernel, Eugeniy Paltsev,
Greg Kroah-Hartman, Jiri Slaby, linux-serial, Hauke Mehrtens,
bcm-kernel-feedback-list, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
For years arm has been using serial.h from asm-generic which sets
BASE_BAUD value to the (1843200 / 16). This is incorrect as:
1) This value obviously isn't correct for all devices
2) There are no device specific serial.h with CONFIG_ARCH_MULTIPLATFORM
That value breaks early serial console e.g. on Broadcom Northstar boards
(CONFIG_ARCH_BCM_5301X) which need BASE_BAUD = (99532800 / 16).
The problem remained unnoticed until 4.14 and the commit 31cb9a8575ca0
("earlycon: initialise baud field of earlycon device structure").
Above commit started filling "baud" in the "struct earlycon_device" (it
seems to be a correct behavior) and changed behavior of the 8250/16550
early console driver. Starting with 4.14 kernel's 8250_early.c sets UART
divisor if both: "uartclk" and "baud" are set. Having wrong value for
BASE_BAUD (and so "uartclk") results in broken console setup.
Solution to that has been introduced in commit 0ff3ab701963 ("serial:
8250_early: Only set divisor if valid clk & baud") and requires setting
BASE_BAUD (and so "uartclk") to 0.
A change similar to this action has been pushed for MIPS in the commit
c8ec2041f549 ("MIPS: Add custom serial.h with BASE_BAUD override for
generic kernel"). Another platform using 0 for BASE_BAUD is s390.
Fixes: 31cb9a8575ca ("earlycon: initialise baud field of earlycon device structure")
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
This problem has been originally reported by me in the e-mail:
ns16550 earlycon baud broken on BCM5301X since commit 31cb9a8575ca0 ("earlycon: initialise baud field of earlycon device structure")
https://www.spinics.net/lists/arm-kernel/msg644295.html
---
arch/arm/include/asm/serial.h | 8 ++++++++
1 file changed, 8 insertions(+)
create mode 100644 arch/arm/include/asm/serial.h
diff --git a/arch/arm/include/asm/serial.h b/arch/arm/include/asm/serial.h
new file mode 100644
index 000000000000..e12f262290ad
--- /dev/null
+++ b/arch/arm/include/asm/serial.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ARM_SERIAL_H
+#define _ASM_ARM_SERIAL_H
+
+/* ARM kernels support multiple devices so there isn't a single valid value. */
+#define BASE_BAUD 0
+
+#endif /* _ASM_ARM_SERIAL_H */
--
2.13.7
^ permalink raw reply related
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Dan Carpenter @ 2018-09-20 18:05 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Andrew Lunn, Ulf Hansson, linux-doc, linux-iio, Linus Walleij,
Dominik Brodowski, Yegor Yefremov, David S. Miller, linux-i2c,
Peter Meerwald-Stadler, Marek Szyprowski, devel, Florian Fainelli,
Jonathan Corbet, Krzysztof Kozlowski, Kishon Vijay Abraham I,
Tony Lindgren, Peter Korsgaard, Geert Uytterhoeven, linux-serial,
Jiri Slaby, Michael Hennerich, Uwe Kleine-König
In-Reply-To: <9860023.SlBYqtbjDV@z50>
On Thu, Sep 20, 2018 at 05:48:22PM +0200, Janusz Krzysztofik wrote:
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index a53d17745d21..5bc3447949c9 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -2880,7 +2880,7 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
> __set_bit(hwgpio, mask);
>
> if (array_info)
> - find_next_zero_bit(array_info->get_mask,
> + i = find_next_zero_bit(array_info->get_mask,
> array_size, i);
We could mark find_next_zero_bit() and friends as a __must_check
functions so we avoid this bug in the future. I have a more complicated
idea how to detect these bugs in a generic way using Smatch but it will
take longer to implement.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Janusz Krzysztofik @ 2018-09-20 16:21 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Andrew Lunn, Ulf Hansson, linux-doc, linux-iio, Linus Walleij,
Dominik Brodowski, Peter Rosin, netdev, linux-i2c,
Peter Meerwald-Stadler, devel, Florian Fainelli, Jonathan Corbet,
Janusz Krzysztofik, Krzysztof Kozlowski, Kishon Vijay Abraham I,
Tony Lindgren, Lukas Wunner, Geert Uytterhoeven, linux-serial,
Jiri Slaby, Michael Hennerich, Uwe Kleine-König, linux-gpio
In-Reply-To: <9860023.SlBYqtbjDV@z50>
On Thursday, September 20, 2018 5:48:22 PM CEST Janusz Krzysztofik wrote:
> On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski wrote:
> > Hi All,
> >
> > On 2018-09-02 14:01, Janusz Krzysztofik wrote:
> > > Certain GPIO descriptor arrays returned by gpio_get_array() may contain
> > > information on direct mapping of array members to pins of a single GPIO
> > > chip in hardware order. In such cases, bitmaps of values can be passed
> > > directly from/to the chip's .get/set_multiple() callbacks without
> > > wasting time on iterations.
> > >
> > > Add respective code to gpiod_get/set_array_bitmap_complex() functions.
> > > Pins not applicable for fast path are processed as before, skipping
> > > over the 'fast' ones.
> > >
> > > Cc: Jonathan Corbet <corbet@lwn.net>
> > > Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
> >
> > I've just noticed that this patch landed in today's linux-next. Sadly it
> > breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
> > device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
> >
> > Booting hangs after detecting MMC cards. Reverting this patch fixes the
> > boot. I will try later to add some debugs and investigate it further what
> > really happens when booting hangs.
>
> Hi Marek,
>
> Thanks for reporting. Could you please try the following fix?
Hi again,
I realized the patch was not correct, j, not i, should be updated in second
hunk. Please try the following one.
Thanks,
Janusz
>From a919c504850f6cb40e8e81267a3a37537f7c4fd4 Mon Sep 17 00:00:00 2001
From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Date: Thu, 20 Sep 2018 17:37:21 +0200
Subject: [PATCH] gpiolib: Fix bitmap index not updated
While skipping fast path bits, bitmap index is not updated with next
found zero bit position. Fix it.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
---
drivers/gpio/gpiolib.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index a53d17745d21..369bdd358fcc 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2880,7 +2880,7 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
__set_bit(hwgpio, mask);
if (array_info)
- find_next_zero_bit(array_info->get_mask,
+ i = find_next_zero_bit(array_info->get_mask,
array_size, i);
else
i++;
@@ -2905,7 +2905,8 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
trace_gpio_value(desc_to_gpio(desc), 1, value);
if (array_info)
- find_next_zero_bit(array_info->get_mask, i, j);
+ j = find_next_zero_bit(array_info->get_mask, i,
+ j);
else
j++;
}
@@ -3192,7 +3193,7 @@ int gpiod_set_array_value_complex(bool raw, bool can_sleep,
}
if (array_info)
- find_next_zero_bit(array_info->set_mask,
+ i = find_next_zero_bit(array_info->set_mask,
array_size, i);
else
i++;
--
2.16.4
^ permalink raw reply related
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Linus Walleij @ 2018-09-20 15:49 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Janusz Krzysztofik, Jonathan Corbet, Miguel Ojeda Sandonis,
Peter Korsgaard, Peter Rosin, Ulf Hansson, Andrew Lunn,
Florian Fainelli, David S. Miller, Dominik Brodowski, Greg KH,
kishon, Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Hartmut Knaack, Peter Meerwald, Jiri Slaby, Willy Tarreau,
Geert Uytterhoeven
In-Reply-To: <20180920101151eucas1p221f5a1715b8556bb9d99bf08fe09ce6f~WE-_cEf4l0754207542eucas1p27@eucas1p2.samsung.com>
On Thu, Sep 20, 2018 at 3:11 AM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> I've just noticed that this patch landed in today's linux-next. Sadly it
> breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
> device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
Thanks for testing on this platform!
> Booting hangs after detecting MMC cards. Reverting this patch fixes the
> boot. I will try later to add some debugs and investigate it further what
> really happens when booting hangs.
How typical. I hope we can fix it, because this should mean speedups
for your platform.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Janusz Krzysztofik @ 2018-09-20 15:48 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Linus Walleij, Jonathan Corbet, Miguel Ojeda Sandonis,
Peter Korsgaard, Peter Rosin, Ulf Hansson, Andrew Lunn,
Florian Fainelli, David S. Miller, Dominik Brodowski,
Greg Kroah-Hartman, Kishon Vijay Abraham I, Lars-Peter Clausen,
Michael Hennerich, Jonathan Cameron, Hartmut Knaack,
Peter Meerwald-Stadler, Jiri Slaby, Willy Tarreau
In-Reply-To: <20180920101151eucas1p221f5a1715b8556bb9d99bf08fe09ce6f~WE-_cEf4l0754207542eucas1p27@eucas1p2.samsung.com>
On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski wrote:
> Hi All,
>
> On 2018-09-02 14:01, Janusz Krzysztofik wrote:
> > Certain GPIO descriptor arrays returned by gpio_get_array() may contain
> > information on direct mapping of array members to pins of a single GPIO
> > chip in hardware order. In such cases, bitmaps of values can be passed
> > directly from/to the chip's .get/set_multiple() callbacks without
> > wasting time on iterations.
> >
> > Add respective code to gpiod_get/set_array_bitmap_complex() functions.
> > Pins not applicable for fast path are processed as before, skipping
> > over the 'fast' ones.
> >
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>
> I've just noticed that this patch landed in today's linux-next. Sadly it
> breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
> device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
>
> Booting hangs after detecting MMC cards. Reverting this patch fixes the
> boot. I will try later to add some debugs and investigate it further what
> really happens when booting hangs.
Hi Marek,
Thanks for reporting. Could you please try the following fix?
Thanks,
Janusz
>From d7ecd435bfb4972766b63ac383a43875700c7452 Mon Sep 17 00:00:00 2001
From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Date: Thu, 20 Sep 2018 17:37:21 +0200
Subject: [PATCH] gpiolib: Fix bitmap index not updated
While skipping fast path bits, bitmap index is not updated with next
found zero bit position. Fix it.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
---
drivers/gpio/gpiolib.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index a53d17745d21..5bc3447949c9 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2880,7 +2880,7 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
__set_bit(hwgpio, mask);
if (array_info)
- find_next_zero_bit(array_info->get_mask,
+ i = find_next_zero_bit(array_info->get_mask,
array_size, i);
else
i++;
@@ -2905,7 +2905,8 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
trace_gpio_value(desc_to_gpio(desc), 1, value);
if (array_info)
- find_next_zero_bit(array_info->get_mask, i, j);
+ i = find_next_zero_bit(array_info->get_mask, i,
+ j);
else
j++;
}
@@ -3192,7 +3193,7 @@ int gpiod_set_array_value_complex(bool raw, bool can_sleep,
}
if (array_info)
- find_next_zero_bit(array_info->set_mask,
+ i = find_next_zero_bit(array_info->set_mask,
array_size, i);
else
i++;
--
2.16.4
^ permalink raw reply related
* [PATCH v1] tty: serial: imx: enable IDDMAEN for the last tail data
From: Robin Gong @ 2018-09-20 15:26 UTC (permalink / raw)
To: jslaby, fugang.duan, linux-serial; +Cc: linux-kernel, linux-imx
enable IDDMAEN in UCR4 to let sdma script has the chance to detect
the idle status and transfer the last tail data with the interrupt
notifying uart driver.Otherwise, the last dma done interrupt of the
tail data in rxfifo whose size is less than watermark may never be
received by uart driver.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/tty/serial/imx.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 239c0fa..bbb1693 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1278,7 +1278,7 @@ static int imx_uart_dma_init(struct imx_port *sport)
static void imx_uart_enable_dma(struct imx_port *sport)
{
- u32 ucr1;
+ u32 ucr1, ucr4;
imx_uart_setup_ufcr(sport, TXTL_DMA, RXTL_DMA);
@@ -1287,18 +1287,26 @@ static void imx_uart_enable_dma(struct imx_port *sport)
ucr1 |= UCR1_RXDMAEN | UCR1_TXDMAEN | UCR1_ATDMAEN;
imx_uart_writel(sport, ucr1, UCR1);
+ ucr4 = imx_uart_readl(sport, UCR4);
+ ucr4 |= UCR4_IDDMAEN;
+ imx_uart_writel(sport, ucr4, UCR4);
+
sport->dma_is_enabled = 1;
}
static void imx_uart_disable_dma(struct imx_port *sport)
{
- u32 ucr1;
+ u32 ucr1, ucr4;
/* clear UCR1 */
ucr1 = imx_uart_readl(sport, UCR1);
ucr1 &= ~(UCR1_RXDMAEN | UCR1_TXDMAEN | UCR1_ATDMAEN);
imx_uart_writel(sport, ucr1, UCR1);
+ ucr4 = imx_uart_readl(sport, UCR4);
+ ucr4 &= ~UCR4_IDDMAEN;
+ imx_uart_writel(sport, ucr4, UCR4);
+
imx_uart_setup_ufcr(sport, TXTL_DEFAULT, RXTL_DEFAULT);
sport->dma_is_enabled = 0;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] serial: imx: restore handshaking irq for imx1
From: Leonard Crestez @ 2018-09-20 12:17 UTC (permalink / raw)
To: jslaby@suse.com, u.kleine-koenig@pengutronix.de,
gregkh@linuxfoundation.org
Cc: yuehaibing@huawei.com, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel@pengutronix.de, Andy Duan,
kernel-janitors@vger.kernel.org
In-Reply-To: <20180920121117.19041-1-u.kleine-koenig@pengutronix.de>
On Thu, 2018-09-20 at 14:11 +0200, Uwe Kleine-König wrote:
> Back in 2015 when irda was dropped from the driver imx1 was broken. This
> change reintroduces the support for the third interrupt of the UART.
>
> Fixes: afe9cbb1a6ad ("serial: imx: drop support for IRDA")
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
I'm not sure if anyone has imx1 hardware handy can is willing to test
this CTS/RTS but the fix is pretty obviously correct.
^ permalink raw reply
* [PATCH] serial: imx: restore handshaking irq for imx1
From: Uwe Kleine-König @ 2018-09-20 12:11 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: YueHaibing, linux-serial, kernel, kernel-janitors, linux-kernel,
Leonard Crestez, Andy Duan
In-Reply-To: <20180920071957.xnwni4lqb5kgncfc@pengutronix.de>
Back in 2015 when irda was dropped from the driver imx1 was broken. This
change reintroduces the support for the third interrupt of the UART.
Fixes: afe9cbb1a6ad ("serial: imx: drop support for IRDA")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/tty/serial/imx.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 4e853570ea80..554a69db1bca 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2350,6 +2350,14 @@ static int imx_uart_probe(struct platform_device *pdev)
ret);
return ret;
}
+
+ ret = devm_request_irq(&pdev->dev, rtsirq, imx_uart_rtsint, 0,
+ dev_name(&pdev->dev), sport);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to request rts irq: %d\n",
+ ret);
+ return ret;
+ }
} else {
ret = devm_request_irq(&pdev->dev, rxirq, imx_uart_int, 0,
dev_name(&pdev->dev), sport);
--
2.18.0
^ 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