* [soc:imx/defconfig] BUILD SUCCESS 5b4bf802427e3f49b9bca5e02ec7154e4d3d63ad
From: kbuild test robot @ 2020-05-26 18:56 UTC (permalink / raw)
To: Shawn Guo; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git imx/defconfig
branch HEAD: 5b4bf802427e3f49b9bca5e02ec7154e4d3d63ad ARM: imx_v6_v7_defconfig: extend RN5T618 PMIC family support
elapsed time: 9433m
configs tested: 205
configs skipped: 115
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
sparc allyesconfig
mips allyesconfig
m68k allyesconfig
arm davinci_all_defconfig
mips db1xxx_defconfig
c6x defconfig
arm64 alldefconfig
sh sh2007_defconfig
sh se7722_defconfig
arc vdk_hs38_defconfig
arm gemini_defconfig
sh sdk7786_defconfig
h8300 defconfig
arm u8500_defconfig
parisc generic-32bit_defconfig
sparc64 allyesconfig
mips lasat_defconfig
h8300 h8s-sim_defconfig
m68k m5208evb_defconfig
sh ecovec24_defconfig
sh se7721_defconfig
mips sb1250_swarm_defconfig
powerpc ps3_defconfig
sh r7780mp_defconfig
arm sama5_defconfig
sh se7712_defconfig
arm iop32x_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
i386 randconfig-a001-20200520
i386 randconfig-a004-20200520
i386 randconfig-a006-20200520
i386 randconfig-a003-20200520
i386 randconfig-a002-20200520
i386 randconfig-a005-20200520
i386 randconfig-a001-20200526
i386 randconfig-a004-20200526
i386 randconfig-a003-20200526
i386 randconfig-a002-20200526
i386 randconfig-a005-20200526
i386 randconfig-a006-20200519
i386 randconfig-a005-20200519
i386 randconfig-a001-20200519
i386 randconfig-a003-20200519
i386 randconfig-a004-20200519
i386 randconfig-a002-20200519
i386 randconfig-a006-20200526
i386 randconfig-a001-20200524
i386 randconfig-a004-20200524
i386 randconfig-a006-20200524
i386 randconfig-a003-20200524
i386 randconfig-a002-20200524
i386 randconfig-a005-20200524
x86_64 randconfig-a003-20200519
x86_64 randconfig-a005-20200519
x86_64 randconfig-a004-20200519
x86_64 randconfig-a006-20200519
x86_64 randconfig-a002-20200519
x86_64 randconfig-a001-20200519
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
x86_64 randconfig-a015-20200526
x86_64 randconfig-a013-20200526
x86_64 randconfig-a016-20200526
x86_64 randconfig-a012-20200526
x86_64 randconfig-a014-20200526
x86_64 randconfig-a011-20200526
x86_64 randconfig-a013-20200524
x86_64 randconfig-a015-20200524
x86_64 randconfig-a016-20200524
x86_64 randconfig-a012-20200524
x86_64 randconfig-a014-20200524
x86_64 randconfig-a011-20200524
x86_64 randconfig-a015-20200522
x86_64 randconfig-a013-20200522
x86_64 randconfig-a016-20200522
x86_64 randconfig-a012-20200522
x86_64 randconfig-a014-20200522
x86_64 randconfig-a011-20200522
x86_64 randconfig-a002-20200521
x86_64 randconfig-a006-20200521
x86_64 randconfig-a005-20200521
x86_64 randconfig-a004-20200521
x86_64 randconfig-a003-20200521
x86_64 randconfig-a001-20200521
i386 randconfig-a013-20200520
i386 randconfig-a012-20200520
i386 randconfig-a015-20200520
i386 randconfig-a011-20200520
i386 randconfig-a016-20200520
i386 randconfig-a014-20200520
i386 randconfig-a013-20200522
i386 randconfig-a012-20200522
i386 randconfig-a015-20200522
i386 randconfig-a011-20200522
i386 randconfig-a016-20200522
i386 randconfig-a014-20200522
i386 randconfig-a013-20200526
i386 randconfig-a015-20200526
i386 randconfig-a012-20200526
i386 randconfig-a011-20200526
i386 randconfig-a016-20200526
i386 randconfig-a014-20200526
i386 randconfig-a013-20200521
i386 randconfig-a012-20200521
i386 randconfig-a015-20200521
i386 randconfig-a011-20200521
i386 randconfig-a016-20200521
i386 randconfig-a014-20200521
i386 randconfig-a012-20200519
i386 randconfig-a014-20200519
i386 randconfig-a016-20200519
i386 randconfig-a011-20200519
i386 randconfig-a015-20200519
i386 randconfig-a013-20200519
i386 randconfig-a013-20200524
i386 randconfig-a015-20200524
i386 randconfig-a012-20200524
i386 randconfig-a011-20200524
i386 randconfig-a016-20200524
i386 randconfig-a014-20200524
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allyesconfig
um allmodconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
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] arm64: vdso32: force vdso32 to be compiled as -marm
From: Stephen Boyd @ 2020-05-26 18:55 UTC (permalink / raw)
To: Catalin Marinas, Nick Desaulniers, Will Deacon
Cc: Naohiro Aota, Stephen Boyd, Masahiro Yamada, Nick Desaulniers,
linux-kernel, Manoj Gupta, Luis Lozano, Nathan Chancellor,
Vincenzo Frascino, linux-arm-kernel
In-Reply-To: <20200526173117.155339-1-ndesaulniers@google.com>
Quoting Nick Desaulniers (2020-05-26 10:31:14)
> Custom toolchains that modify the default target to -mthumb cannot
> compile the arm64 compat vdso32, as
> arch/arm64/include/asm/vdso/compat_gettimeofday.h
> contains assembly that's invalid in -mthumb. Force the use of -marm,
> always.
>
> Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1084372
> Cc: Stephen Boyd <swboyd@google.com>
> Reported-by: Luis Lozano <llozano@google.com>
> Tested-by: Manoj Gupta <manojgupta@google.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Rob Herring @ 2020-05-26 18:28 UTC (permalink / raw)
To: Dongchun Zhu
Cc: mark.rutland, devicetree, andriy.shevchenko, louis.kuo,
srv_heupstream, linus.walleij, shengnan.wang, tfiga, bgolaszewski,
sj.huang, drinkcat, linux-mediatek, sakari.ailus, matthias.bgg,
bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20200523084103.31276-2-dongchun.zhu@mediatek.com>
On Sat, May 23, 2020 at 04:41:02PM +0800, Dongchun Zhu wrote:
> Add DT bindings documentation for Omnivision OV02A10 image sensor.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> .../bindings/media/i2c/ovti,ov02a10.yaml | 172 +++++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 179 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> new file mode 100644
> index 0000000..56f31b5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> @@ -0,0 +1,172 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> +
> +maintainers:
> + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> +
> +description: |-
> + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> + image sensor, which is the latest production derived from Omnivision's CMOS
> + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> + sensor output is available via CSI-2 serial data output.
> +
> +properties:
> + compatible:
> + const: ovti,ov02a10
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: top mux camtg clock
> + - description: divider clock
> +
> + clock-names:
> + items:
> + - const: eclk
> + - const: freq_mux
> +
> + clock-frequency:
> + description:
> + Frequency of the eclk clock in Hertz.
> +
> + dovdd-supply:
> + description:
> + Definition of the regulator used as Digital I/O voltage supply.
> +
> + avdd-supply:
> + description:
> + Definition of the regulator used as Analog voltage supply.
> +
> + dvdd-supply:
> + description:
> + Definition of the regulator used as Digital core voltage supply.
> +
> + powerdown-gpios:
> + description:
> + Must be the device tree identifier of the GPIO connected to the
> + PD_PAD pin. This pin is used to place the OV02A10 into Standby mode
> + or Shutdown mode. As the line is active low, it should be
> + marked GPIO_ACTIVE_LOW.
Need to define how many GPIOs ('maxItems: 1')
> +
> + reset-gpios:
> + description:
> + Must be the device tree identifier of the GPIO connected to the
> + RST_PD pin. If specified, it will be asserted during driver probe.
> + As the line is active high, it should be marked GPIO_ACTIVE_HIGH.
Here too.
> +
> + rotation:
> + description:
> + Definition of the sensor's placement.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum:
> + - 0 # Sensor Mounted Upright
> + - 180 # Sensor Mounted Upside Down
> + default: 0
> +
> + ovti,mipi-tx-speed:
> + description:
> + Indication of MIPI transmission speed select, which is to control D-PHY
> + timing setting by adjusting MIPI clock voltage to improve the clock
> + driver capability.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum:
> + - 0 # 20MHz - 30MHz
> + - 1 # 30MHz - 50MHz
> + - 2 # 50MHz - 75MHz
> + - 3 # 75MHz - 100MHz
> + - 4 # 100MHz - 130MHz
> + default: 3
> +
> + # See ../video-interfaces.txt for details
> + port:
> + type: object
> + additionalProperties: false
Should have a description of what data the port has.
> +
> + properties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + data-lanes:
> + maxItems: 1
> +
> + link-frequencies: true
> + remote-endpoint: true
> +
> + required:
> + - data-lanes
> + - link-frequencies
> + - remote-endpoint
> +
> + required:
> + - endpoint
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - clock-frequency
> + - dovdd-supply
> + - avdd-supply
> + - dvdd-supply
> + - powerdown-gpios
> + - reset-gpios
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +
> + #include <dt-bindings/clock/mt8183-clk.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov02a10: camera-sensor@3d {
> + compatible = "ovti,ov02a10";
> + reg = <0x3d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&clk_24m_cam>;
> +
> + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> + clock-names = "eclk", "freq_mux";
> + clock-frequency = <24000000>;
> +
> + rotation = <180>;
> + ovti,mipi-tx-speed = <4>;
> +
> + dovdd-supply = <&mt6358_vcamio_reg>;
> + avdd-supply = <&mt6358_vcama1_reg>;
> + dvdd-supply = <&mt6358_vcn18_reg>;
> +
> + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + wcam_out: endpoint {
> + data-lanes = <1>;
> + link-frequencies = /bits/ 64 <390000000>;
> + remote-endpoint = <&mipi_in_wcam>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e64e5db..63a2335 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> S: Maintained
> F: drivers/char/pcmcia/cm4040_cs.*
>
> +OMNIVISION OV02A10 SENSOR DRIVER
> +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +T: git git://linuxtv.org/media_tree.git
> +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> +
> OMNIVISION OV13858 SENSOR DRIVER
> M: Sakari Ailus <sakari.ailus@linux.intel.com>
> L: linux-media@vger.kernel.org
> --
> 2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 3/3] serial: 8250_dw: Fix common clocks usage race condition
From: Serge Semin @ 2020-05-26 18:12 UTC (permalink / raw)
To: Thomas Bogendoerfer, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko
Cc: Arnd Bergmann, linux-kernel, Russell King, Maxime Ripard,
Alexey Malahov, Serge Semin, Serge Semin, linux-serial,
linux-mips, Will Deacon, linux-arm-kernel
In-Reply-To: <20200526181227.1889-1-Sergey.Semin@baikalelectronics.ru>
The race condition may happen if the UART reference clock is shared with
some other device (on Baikal-T1 SoC it's another DW UART port). In this
case if that device changes the clock rate while serial console is using
it the DW 8250 UART port might not only end up with an invalid uartclk
value saved, but may also experience a distorted output data since
baud-clock could have been changed. In order to fix this lets at least
try to adjust the 8250 port setting like UART clock rate in case if the
reference clock rate change is discovered. The driver will call the new
method to update 8250 UART port clock rate settings. It's done by means of
the clock event notifier registered at the port startup and unregistered
in the shutdown callback method.
Note 1. In order to avoid deadlocks we had to execute the UART port update
method in a dedicated deferred work. This is due to (in my opinion
redundant) the clock update implemented in the dw8250_set_termios()
method.
Note 2. Before the ref clock is manually changed by the custom
set_termios() function we swap the port uartclk value with new rate
adjusted to be suitable for the requested baud. It is necessary in
order to effectively disable a functionality of the ref clock events
handler for the current UART port, since uartclk update will be done
a bit further in the generic serial8250_do_set_termios() function.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-mips@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
Changelog v2:
- Move exclusive ref clock lock/unlock precudures to the 8250 port
startup/shutdown methods.
- The changelog message has also been slightly modified due to the
alteration.
- Remove Alexey' SoB tag.
- Cc someone from ARM who might be concerned regarding this change.
- Cc someone from Clocks Framework to get their comments on this patch.
Changelog v3:
- Refactor the original patch to adjust the UART port divisor instead of
requesting an exclusive ref clock utilization.
Changelog v5:
- Refactor dw8250_clk_work_cb() function cheking the clk_get_rate()
return value for being erroneous and exit if it is.
- Don't update p->uartclk on the port startup. It will be updated later in
the same procedure at the set_termios() function being invoked by the
serial_core anyway.
---
drivers/tty/serial/8250/8250_dw.c | 105 +++++++++++++++++++++++++++++-
1 file changed, 102 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index 12866083731d..fa59c026270f 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -19,6 +19,8 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/platform_device.h>
+#include <linux/workqueue.h>
+#include <linux/notifier.h>
#include <linux/slab.h>
#include <linux/acpi.h>
#include <linux/clk.h>
@@ -43,6 +45,8 @@ struct dw8250_data {
int msr_mask_off;
struct clk *clk;
struct clk *pclk;
+ struct notifier_block clk_notifier;
+ struct work_struct clk_work;
struct reset_control *rst;
unsigned int skip_autocfg:1;
@@ -54,6 +58,16 @@ static inline struct dw8250_data *to_dw8250_data(struct dw8250_port_data *data)
return container_of(data, struct dw8250_data, data);
}
+static inline struct dw8250_data *clk_to_dw8250_data(struct notifier_block *nb)
+{
+ return container_of(nb, struct dw8250_data, clk_notifier);
+}
+
+static inline struct dw8250_data *work_to_dw8250_data(struct work_struct *work)
+{
+ return container_of(work, struct dw8250_data, clk_work);
+}
+
static inline int dw8250_modify_msr(struct uart_port *p, int offset, int value)
{
struct dw8250_data *d = to_dw8250_data(p->private_data);
@@ -260,6 +274,46 @@ static int dw8250_handle_irq(struct uart_port *p)
return 0;
}
+static void dw8250_clk_work_cb(struct work_struct *work)
+{
+ struct dw8250_data *d = work_to_dw8250_data(work);
+ struct uart_8250_port *up;
+ unsigned long rate;
+
+ rate = clk_get_rate(d->clk);
+ if (rate <= 0)
+ return;
+
+ up = serial8250_get_port(d->data.line);
+
+ serial8250_update_uartclk(&up->port, rate);
+}
+
+static int dw8250_clk_notifier_cb(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct dw8250_data *d = clk_to_dw8250_data(nb);
+
+ /*
+ * We have no choice but to defer the uartclk update due to two
+ * deadlocks. First one is caused by a recursive mutex lock which
+ * happens when clk_set_rate() is called from dw8250_set_termios().
+ * Second deadlock is more tricky and is caused by an inverted order of
+ * the clk and tty-port mutexes lock. It happens if clock rate change
+ * is requested asynchronously while set_termios() is executed between
+ * tty-port mutex lock and clk_set_rate() function invocation and
+ * vise-versa. Anyway if we didn't have the reference clock alteration
+ * in the dw8250_set_termios() method we wouldn't have needed this
+ * deferred event handling complication.
+ */
+ if (event == POST_RATE_CHANGE) {
+ queue_work(system_unbound_wq, &d->clk_work);
+ return NOTIFY_OK;
+ }
+
+ return NOTIFY_DONE;
+}
+
static void
dw8250_do_pm(struct uart_port *port, unsigned int state, unsigned int old)
{
@@ -283,9 +337,16 @@ static void dw8250_set_termios(struct uart_port *p, struct ktermios *termios,
clk_disable_unprepare(d->clk);
rate = clk_round_rate(d->clk, baud * 16);
if (rate > 0) {
- ret = clk_set_rate(d->clk, rate);
- if (!ret)
- p->uartclk = rate;
+ /*
+ * Premilinary set the uartclk to the new clock rate so the
+ * clock update event handler caused by the clk_set_rate()
+ * calling wouldn't actually update the UART divisor since
+ * we about to do this anyway.
+ */
+ swap(p->uartclk, rate);
+ ret = clk_set_rate(d->clk, p->uartclk);
+ if (ret)
+ swap(p->uartclk, rate);
}
clk_prepare_enable(d->clk);
@@ -312,6 +373,39 @@ static void dw8250_set_ldisc(struct uart_port *p, struct ktermios *termios)
serial8250_do_set_ldisc(p, termios);
}
+static int dw8250_startup(struct uart_port *p)
+{
+ struct dw8250_data *d = to_dw8250_data(p->private_data);
+ int ret;
+
+ /*
+ * Some platforms may provide a reference clock shared between several
+ * devices. In this case before using the serial port first we have to
+ * make sure that any clock state change is known to the UART port at
+ * least post factum.
+ */
+ if (d->clk) {
+ ret = clk_notifier_register(d->clk, &d->clk_notifier);
+ if (ret)
+ dev_warn(p->dev, "Failed to set the clock notifier\n");
+ }
+
+ return serial8250_do_startup(p);
+}
+
+static void dw8250_shutdown(struct uart_port *p)
+{
+ struct dw8250_data *d = to_dw8250_data(p->private_data);
+
+ serial8250_do_shutdown(p);
+
+ if (d->clk) {
+ clk_notifier_unregister(d->clk, &d->clk_notifier);
+
+ flush_work(&d->clk_work);
+ }
+}
+
/*
* dw8250_fallback_dma_filter will prevent the UART from getting just any free
* channel on platforms that have DMA engines, but don't have any channels
@@ -407,6 +501,8 @@ static int dw8250_probe(struct platform_device *pdev)
p->serial_out = dw8250_serial_out;
p->set_ldisc = dw8250_set_ldisc;
p->set_termios = dw8250_set_termios;
+ p->startup = dw8250_startup;
+ p->shutdown = dw8250_shutdown;
p->membase = devm_ioremap(dev, regs->start, resource_size(regs));
if (!p->membase)
@@ -468,6 +564,9 @@ static int dw8250_probe(struct platform_device *pdev)
if (IS_ERR(data->clk))
return PTR_ERR(data->clk);
+ INIT_WORK(&data->clk_work, dw8250_clk_work_cb);
+ data->clk_notifier.notifier_call = dw8250_clk_notifier_cb;
+
err = clk_prepare_enable(data->clk);
if (err)
dev_warn(dev, "could not enable optional baudclk: %d\n", err);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 2/3] serial: 8250_dw: Simplify the ref clock rate setting procedure
From: Serge Semin @ 2020-05-26 18:12 UTC (permalink / raw)
To: Thomas Bogendoerfer, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko
Cc: Arnd Bergmann, linux-kernel, Russell King, Maxime Ripard,
Alexey Malahov, Serge Semin, Serge Semin, linux-serial,
linux-mips, Will Deacon, linux-arm-kernel
In-Reply-To: <20200526181227.1889-1-Sergey.Semin@baikalelectronics.ru>
Really instead of twice checking the clk_round_rate() return value
we could do it once, and if it isn't error the clock rate can be changed.
By doing so we decrease a number of ret-value tests and remove a weird
goto-based construction implemented in the dw8250_set_termios() method.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-mips@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
Changelog v3:
- This is a new patch.
---
drivers/tty/serial/8250/8250_dw.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index aab3cccc6789..12866083731d 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -282,20 +282,13 @@ static void dw8250_set_termios(struct uart_port *p, struct ktermios *termios,
clk_disable_unprepare(d->clk);
rate = clk_round_rate(d->clk, baud * 16);
- if (rate < 0)
- ret = rate;
- else if (rate == 0)
- ret = -ENOENT;
- else
+ if (rate > 0) {
ret = clk_set_rate(d->clk, rate);
+ if (!ret)
+ p->uartclk = rate;
+ }
clk_prepare_enable(d->clk);
- if (ret)
- goto out;
-
- p->uartclk = rate;
-
-out:
p->status &= ~UPSTAT_AUTOCTS;
if (termios->c_cflag & CRTSCTS)
p->status |= UPSTAT_AUTOCTS;
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 1/3] serial: 8250: Add 8250 port clock update method
From: Serge Semin @ 2020-05-26 18:12 UTC (permalink / raw)
To: Thomas Bogendoerfer, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-kernel, Arnd Bergmann, linux-mips, Russell King,
Maxime Ripard, Alexey Malahov, Serge Semin, Serge Semin,
linux-serial, Andy Shevchenko, Will Deacon, linux-arm-kernel
In-Reply-To: <20200526181227.1889-1-Sergey.Semin@baikalelectronics.ru>
Some platforms can be designed in a way so the UART port reference clock
might be asynchronously changed at some point. In Baikal-T1 SoC this may
happen due to the reference clock being shared between two UART ports, on
the Allwinner SoC the reference clock is derived from the CPU clock, so
any CPU frequency change should get to be known/reflected by/in the UART
controller as well. But it's not enough to just update the
uart_port->uartclk field of the corresponding UART port, the 8250
controller reference clock divisor should be altered so to preserve
current baud rate setting. All of these things is done in a coherent
way by calling the serial8250_update_uartclk() method provided in this
patch. Though note that it isn't supposed to be called from within the
UART port callbacks because the locks using to the protect the UART port
data are already taken in there.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-mips@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
Changelog v4:
- Export serial8250_update_uartclk() symbol for GPL modules only.
---
drivers/tty/serial/8250/8250_port.c | 38 +++++++++++++++++++++++++++++
include/linux/serial_8250.h | 2 ++
2 files changed, 40 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 4d83c85a7389..5596868c8832 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2628,6 +2628,44 @@ static unsigned int serial8250_get_baud_rate(struct uart_port *port,
(port->uartclk + tolerance) / 16);
}
+/*
+ * Note in order to avoid the tty port mutex deadlock don't use the next method
+ * within the uart port callbacks. Primarily it's supposed to be utilized to
+ * handle a sudden reference clock rate change.
+ */
+void serial8250_update_uartclk(struct uart_port *port, unsigned int uartclk)
+{
+ struct uart_8250_port *up = up_to_u8250p(port);
+ unsigned int baud, quot, frac = 0;
+ struct ktermios *termios;
+ unsigned long flags;
+
+ mutex_lock(&port->state->port.mutex);
+
+ if (port->uartclk == uartclk)
+ goto out_lock;
+
+ port->uartclk = uartclk;
+ termios = &port->state->port.tty->termios;
+
+ baud = serial8250_get_baud_rate(port, termios, NULL);
+ quot = serial8250_get_divisor(port, baud, &frac);
+
+ spin_lock_irqsave(&port->lock, flags);
+
+ uart_update_timeout(port, termios->c_cflag, baud);
+
+ serial8250_set_divisor(port, baud, quot, frac);
+ serial_port_out(port, UART_LCR, up->lcr);
+ serial8250_out_MCR(up, UART_MCR_DTR | UART_MCR_RTS);
+
+ spin_unlock_irqrestore(&port->lock, flags);
+
+out_lock:
+ mutex_unlock(&port->state->port.mutex);
+}
+EXPORT_SYMBOL_GPL(serial8250_update_uartclk);
+
void
serial8250_do_set_termios(struct uart_port *port, struct ktermios *termios,
struct ktermios *old)
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index 6545f8cfc8fa..2b70f736b091 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -155,6 +155,8 @@ extern int early_serial_setup(struct uart_port *port);
extern int early_serial8250_setup(struct earlycon_device *device,
const char *options);
+extern void serial8250_update_uartclk(struct uart_port *port,
+ unsigned int uartclk);
extern void serial8250_do_set_termios(struct uart_port *port,
struct ktermios *termios, struct ktermios *old);
extern void serial8250_do_set_ldisc(struct uart_port *port,
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 0/3] serial: 8250_dw: Fix ref clock usage
From: Serge Semin @ 2020-05-26 18:12 UTC (permalink / raw)
To: Thomas Bogendoerfer, Greg Kroah-Hartman, Jiri Slaby
Cc: Maxime Ripard, Alexey Kolotnikov, Vadim Vlasov, Maxim Kaurkin,
Ramil Zaripov, linux-mips, linux-kernel, Russell King,
Serge Semin, Alexey Malahov, Serge Semin, Arnd Bergmann,
Pavel Parkhomenko, Ekaterina Skachko, linux-serial,
Andy Shevchenko, Will Deacon, linux-arm-kernel
Greg, Jiri, the merge window is upon us, please review/merge in/whatever
the rest of the patches.
It might be dangerous if an UART port reference clock rate is suddenly
changed. In particular the 8250 port drivers (and AFAICS most of the tty
drivers using common clock framework clocks) rely either on the
exclusive reference clock utilization or on the ref clock rate being
always constant. Needless to say that it turns out not true and if some
other service suddenly changes the clock rate behind an UART port driver
back it's no good. So the port might not only end up with an invalid
uartclk value saved, but may also experience a distorted output/input
data since such action will effectively update the programmed baud-clock.
We discovered such problem on Baikal-T1 SoC where two DW 8250 ports have
got a shared reference clock. Allwinner SoC is equipped with an UART,
which clock is derived from the CPU PLL clock source, so the CPU frequency
change might be propagated down up to the serial port reference clock.
This patchset provides a way to fix the problem to the 8250 serial port
controllers and mostly fixes it for the DW 8250-compatible UART. I say
mostly because due to not having a facility to pause/stop and resume/
restart on-going transfers we implemented the UART clock rate update
procedure executed post factum of the actual reference clock rate change.
In addition the patchset includes a few fixes we discovered when were
working the issue. First one concerns the maximum baud rate setting used
to determine a serial port baud based on the current UART port clock rate.
Another one simplifies the ref clock rate setting procedure a bit.
This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
0e698dfa2822 ("Linux 5.7-rc4")
tag: v5.7-rc4
Changelog v3:
- Refactor the original patch to adjust the UART port divisor instead of
requesting an exclusive ref clock utilization.
Changelog v4:
- Discard commit b426bf0fb085 ("serial: 8250: Fix max baud limit in generic
8250 port") since Greg has already merged it into the tty-next branch.
- Use EXPORT_SYMBOL_GPL() for the serial8250_update_uartclk() method.
Changelog v5:
- Refactor dw8250_clk_work_cb() function cheking the clk_get_rate()
return value for being erroneous and exit if it is.
- Don't update p->uartclk in the port startup. It will be updated later in
the same procedure at the set_termios() function being invoked by the
serial_core anyway.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
Cc: Alexey Kolotnikov <Alexey.Kolotnikov@baikalelectronics.ru>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Cc: Ekaterina Skachko <Ekaterina.Skachko@baikalelectronics.ru>
Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
Cc: Alexey Kolotnikov <Alexey.Kolotnikov@baikalelectronics.ru>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-mips@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (3):
serial: 8250: Add 8250 port clock update method
serial: 8250_dw: Simplify the ref clock rate setting procedure
serial: 8250_dw: Fix common clocks usage race condition
drivers/tty/serial/8250/8250_dw.c | 116 +++++++++++++++++++++++++---
drivers/tty/serial/8250/8250_port.c | 38 +++++++++
include/linux/serial_8250.h | 2 +
3 files changed, 144 insertions(+), 12 deletions(-)
--
2.26.2
_______________________________________________
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 v9 08/10] dt-bindings: ufs: Add DT binding documentation for ufs
From: Rob Herring @ 2020-05-26 18:08 UTC (permalink / raw)
To: Alim Akhtar
Cc: devicetree, linux-samsung-soc, linux-scsi, martin.petersen,
linux-kernel, krzk, kwmad.kim, avri.altman, cang, stanley.chu,
linux-arm-kernel
In-Reply-To: <20200514003914.26052-9-alim.akhtar@samsung.com>
On Thu, May 14, 2020 at 06:09:12AM +0530, Alim Akhtar wrote:
> This patch adds DT binding for samsung ufs hci
Subject should indicate this is for Samsung in some way.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> ---
> .../bindings/ufs/samsung,exynos-ufs.yaml | 91 +++++++++++++++++++
> 1 file changed, 91 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
>
> diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
> new file mode 100644
> index 000000000000..eaa64cc32d52
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
> @@ -0,0 +1,91 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/ufs/samsung,exynos-ufs.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung SoC series UFS host controller Device Tree Bindings
> +
> +maintainers:
> + - Alim Akhtar <alim.akhtar@samsung.com>
> +
> +description: |
> + Each Samsung UFS host controller instance should have its own node.
> + This binding define Samsung specific binding other then what is used
> + in the common ufshcd bindings
> + [1] Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> +
> +properties:
> +
> + compatible:
> + enum:
> + - samsung,exynos7-ufs
> +
> + reg:
> + items:
> + - description: HCI register
> + - description: vendor specific register
> + - description: unipro register
> + - description: UFS protector register
> +
> + reg-names:
> + items:
> + - const: hci
> + - const: vs_hci
> + - const: unipro
> + - const: ufsp
> +
> + clocks:
> + maxItems: 2
maxItems is redundant.
> + items:
> + - description: ufs link core clock
> + - description: unipro main clock
> +
> + clock-names:
> + maxItems: 2
Here too.
> + items:
> + - const: core_clk
> + - const: sclk_unipro_main
> +
> + interrupts:
> + maxItems: 1
> +
> + phys:
> + maxItems: 1
> +
> + phy-names:
> + maxItems: 1
What's the name? (Though a name is kind of pointless when there is only
1.)
With those fixed,
Reviewed-by: Rob Herring <robh@kernel.org>
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - phys
> + - phy-names
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/exynos7-clk.h>
> +
> + ufs: ufs@15570000 {
> + compatible = "samsung,exynos7-ufs";
> + reg = <0x15570000 0x100>,
> + <0x15570100 0x100>,
> + <0x15571000 0x200>,
> + <0x15572000 0x300>;
> + reg-names = "hci", "vs_hci", "unipro", "ufsp";
> + interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clock_fsys1 ACLK_UFS20_LINK>,
> + <&clock_fsys1 SCLK_UFSUNIPRO20_USER>;
> + clock-names = "core_clk", "sclk_unipro_main";
> + pinctrl-names = "default";
> + pinctrl-0 = <&ufs_rst_n &ufs_refclk_out>;
> + phys = <&ufs_phy>;
> + phy-names = "ufs-phy";
> + };
> +...
> --
> 2.17.1
>
_______________________________________________
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] ARM: mm: Simplify act_mm macro
From: Linus Walleij @ 2020-05-26 18:08 UTC (permalink / raw)
To: Russell King - ARM Linux admin; +Cc: Linux ARM
In-Reply-To: <20200526143756.GZ1551@shell.armlinux.org.uk>
On Tue, May 26, 2020 at 4:37 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Tue, May 26, 2020 at 04:32:49PM +0200, Linus Walleij wrote:
> > The act_mm assembly macro is actually partly reimplementing
> > get_thread_info so let's just use that.
> >
> > Suggested-by: Russell King <linux@armlinux.org.uk>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> > arch/arm/mm/proc-macros.S | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
> > index 60ac7c5999a9..65eaea85d3d6 100644
> > --- a/arch/arm/mm/proc-macros.S
> > +++ b/arch/arm/mm/proc-macros.S
> > @@ -5,7 +5,6 @@
> > * VMA_VM_FLAGS
> > * VM_EXEC
> > */
> > -#include <linux/const.h>
> > #include <asm/asm-offsets.h>
> > #include <asm/thread_info.h>
> >
> > @@ -31,9 +30,7 @@
> > * act_mm - get current->active_mm
> > */
> > .macro act_mm, rd
> > - bic \rd, sp, #(THREAD_SIZE - 1) & ~63
> > - bic \rd, \rd, #63
> > - ldr \rd, [\rd, #TI_TASK]
> > + get_thread_info \rd
>
> This is not quite the same thing.
>
> get_thread_info loads into \rd the address of the thread_info structure.
> That's what the two bic instructions are doing. The LDR is then loading
> the address of the task_struct into \rd.
>
> > .if (TSK_ACTIVE_MM > IMM12_MASK)
> > add \rd, \rd, #TSK_ACTIVE_MM & ~IMM12_MASK
> > .endif
>
> So this change alters which structure \rd is pointing to.
Oh I see it. I need to keep the last ldr \rd, [\rd, #TI_TASK].
Strange that it wasn't crashing on me, I guess I was lucky.
I'll respin, thanks!
(The plan is to also make a patch to get_thread_info to use
bic like you pointed out, I'm just slow with my assembly.)
Yours,
Linus Walleij
_______________________________________________
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 v15 02/11] dt-bindings: soc: Add MT8183 power dt-bindings
From: Rob Herring @ 2020-05-26 18:03 UTC (permalink / raw)
To: Weiyi Lu
Cc: devicetree, Nicolas Boichat, srv_heupstream, James Liao,
Enric Balletbo Serra, linux-kernel, Fan Chen, linux-mediatek,
Sascha Hauer, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1590051985-29149-3-git-send-email-weiyi.lu@mediatek.com>
On Thu, 21 May 2020 17:06:15 +0800, Weiyi Lu wrote:
> Add power dt-bindings of MT8183 and introduces "BASIC" and
> "SUBSYS" clock types in binding document.
> The "BASIC" type is compatible to the original power control with
> clock name [a-z]+[0-9]*, e.g. mm, vpu1.
> The "SUBSYS" type is used for bus protection control with clock
> name [a-z]+-[0-9]+, e.g. isp-0, cam-1.
> And add an optional "mediatek,smi" property for phandle to smi-common
> node.
>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> ---
> .../devicetree/bindings/soc/mediatek/scpsys.txt | 21 ++++++++++++++---
> include/dt-bindings/power/mt8183-power.h | 26 ++++++++++++++++++++++
> 2 files changed, 44 insertions(+), 3 deletions(-)
> create mode 100644 include/dt-bindings/power/mt8183-power.h
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 v15 01/11] dt-bindings: mediatek: Add property to mt8183 smi-common
From: Rob Herring @ 2020-05-26 18:02 UTC (permalink / raw)
To: Weiyi Lu
Cc: devicetree, Nicolas Boichat, srv_heupstream, James Liao,
Enric Balletbo Serra, linux-kernel, Fan Chen, linux-mediatek,
Sascha Hauer, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1590051985-29149-2-git-send-email-weiyi.lu@mediatek.com>
On Thu, 21 May 2020 17:06:14 +0800, Weiyi Lu wrote:
> For scpsys driver using regmap based syscon driver API.
>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> ---
> .../devicetree/bindings/memory-controllers/mediatek,smi-common.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
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] arm64: dts: imx8mm-beacon: Fix voltages on LDO1 and LDO2
From: Daniel Baluta @ 2020-05-26 17:43 UTC (permalink / raw)
To: Adam Ford
Cc: Devicetree List, Fabio Estevam, Sascha Hauer, aford,
Linux Kernel Mailing List, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Shawn Guo, linux-arm-kernel
In-Reply-To: <20200526170939.104111-1-aford173@gmail.com>
On Tue, May 26, 2020 at 8:11 PM Adam Ford <aford173@gmail.com> wrote:
>
> LDO1 and LDO2 settings are wrong and case the voltage to go above the
> maximum level of 2.15V permitted by the SoC to 3.0V.
>
> This patch is based on work done on the i.MX8M Mini-EVK which utilizes
> the same fix.
>
> Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit")
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
No need for a new line between fixes and signed-off-by.
With that:
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
_______________________________________________
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 v4 3/3] serial: 8250_dw: Fix common clocks usage race condition
From: Serge Semin @ 2020-05-26 17:41 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Thomas Bogendoerfer, linux-kernel, Arnd Bergmann,
Greg Kroah-Hartman, Russell King, Serge Semin, Alexey Malahov,
Maxime Ripard, linux-serial, Jiri Slaby, linux-mips, Will Deacon,
linux-arm-kernel
In-Reply-To: <20200526165701.GX1634618@smile.fi.intel.com>
On Tue, May 26, 2020 at 07:57:01PM +0300, Andy Shevchenko wrote:
> On Tue, May 26, 2020 at 07:03:16PM +0300, Serge Semin wrote:
> > The race condition may happen if the UART reference clock is shared with
> > some other device (on Baikal-T1 SoC it's another DW UART port). In this
> > case if that device changes the clock rate while serial console is using
> > it the DW 8250 UART port might not only end up with an invalid uartclk
> > value saved, but may also experience a distorted output data since
> > baud-clock could have been changed. In order to fix this lets at least
> > try to adjust the 8250 port setting like UART clock rate in case if the
> > reference clock rate change is discovered. The driver will call the new
> > method to update 8250 UART port clock rate settings. It's done by means of
> > the clock event notifier registered at the port startup and unregistered
> > in the shutdown callback method.
> >
> > Note 1. In order to avoid deadlocks we had to execute the UART port update
> > method in a dedicated deferred work. This is due to (in my opinion
> > redundant) the clock update implemented in the dw8250_set_termios()
> > method.
> > Note 2. Before the ref clock is manually changed by the custom
> > set_termios() function we swap the port uartclk value with new rate
> > adjusted to be suitable for the requested baud. It is necessary in
> > order to effectively disable a functionality of the ref clock events
> > handler for the current UART port, since uartclk update will be done
> > a bit further in the generic serial8250_do_set_termios() function.
>
> ...
>
> > +static void dw8250_clk_work_cb(struct work_struct *work)
> > +{
> > + struct dw8250_data *d = work_to_dw8250_data(work);
> > + struct uart_8250_port *up;
> > + unsigned long rate;
> > +
> > + rate = clk_get_rate(d->clk);
>
> > + if (rate) {
>
> if (rate <= 0)
> return;
>
> ?
Ok. Though there isn't point in a function consisting of a few lines.
>
> > + up = serial8250_get_port(d->data.line);
> > +
> > + serial8250_update_uartclk(&up->port, rate);
> > + }
> > +}
>
> ...
>
> > +static int dw8250_startup(struct uart_port *p)
> > +{
> > + struct dw8250_data *d = to_dw8250_data(p->private_data);
> > + int ret;
> > +
> > + /*
> > + * Some platforms may provide a reference clock shared between several
> > + * devices. In this case before using the serial port first we have to
> > + * make sure that any clock state change is known to the UART port at
> > + * least post factum.
> > + */
>
> > + if (d->clk) {
>
> Do you need this?
Yes, I do. The same way as clk_get_rate() needs this.
>
> > + ret = clk_notifier_register(d->clk, &d->clk_notifier);
>
> Okay, seems clk_notifier_register() and its counterpart should be fixed for
> optional clocks.
In order to use the clk_get_rate() function we need to make sure the clk isn't
optional otherwise -EINVAL will be returned, which is indistinguishable from
any another error. The same situation is for the clk_notifier_register() and
clk_notifier_unregister() counterpart.
>
> > + if (ret)
> > + dev_warn(p->dev, "Failed to set the clock notifier\n");
>
> So, what does this warning mean on the platforms which does not need notifier
> at all
It means "The clk-notifier subsystem is broken. Though if reference clock rate
doesn't change, it won't a problem." Due to the last statement we print a
warning, but not an error message.
> (i.o.w. all but baikal)?
No. As we discussed earlier in the previous pacthset versions there are another
platforms with shared reference clocks behind the DW APB UART, like: Allwinner SoCs,
RPi 3/4, etc.
>
> > + /*
> > + * Get current reference clock rate to make sure the UART port
> > + * is equipped with an up-to-date value before it's started up.
> > + */
>
> Why? We call ->set_termios() for it, no?
This makes sense. Thanks. I'll remove this part.
-Sergey
>
> > + p->uartclk = clk_get_rate(d->clk);
> > + if (!p->uartclk) {
> > + dev_err(p->dev, "Clock rate not defined\n");
> > + return -EINVAL;
> > + }
> > + }
> > +
> > + return serial8250_do_startup(p);
> > +}
> > +
> > +static void dw8250_shutdown(struct uart_port *p)
> > +{
> > + struct dw8250_data *d = to_dw8250_data(p->private_data);
> > +
> > + serial8250_do_shutdown(p);
> > +
>
> > + if (d->clk) {
>
> Ditto.
>
> > + clk_notifier_unregister(d->clk, &d->clk_notifier);
> > +
> > + flush_work(&d->clk_work);
> > + }
> > +}
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
_______________________________________________
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 v4 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings
From: Ben Levinsky @ 2020-05-26 17:40 UTC (permalink / raw)
To: Rob Herring
Cc: ohad@wizery.com, mark.rutland@arm.com, devicetree@vger.kernel.org,
Stefano Stabellini, linux-remoteproc@vger.kernel.org,
linux-kernel@vger.kernel.org, bjorn.andersson@linaro.org,
Jolly Shah, Rajan Vaja, Michal Simek,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200511221755.GA13585@bogus>
Hi Rob,
The Xilinx R5 Remoteproc driver has been around for a long time -- admittedly we should have upstreamed it long ago. The driver in the current form is using an "classic" remoteproc device tree node as described here.
I am working with Stefano to come up with an appropriate System Device Tree representation but it is not going to be ready right away. Our preference would be to upstream the remoteproc node and driver in their current forms while system device tree is maturing.
Will also update as per your below comments in a v5 too.
Best Regards,
Ben Levinsky
-----Original Message-----
From: Rob Herring <robh@kernel.org>
Sent: Monday, May 11, 2020 3:18 PM
To: Ben Levinsky <BLEVINSK@xilinx.com>
Cc: ohad@wizery.com; bjorn.andersson@linaro.org; Michal Simek <michals@xilinx.com>; Jolly Shah <JOLLYS@xilinx.com>; Rajan Vaja <RAJANV@xilinx.com>; mark.rutland@arm.com; linux-remoteproc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Jason Wu <j.wu@xilinx.com>; Jiaying Liang <jliang@xilinx.com>
Subject: Re: [PATCH v4 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings
On Fri, Apr 24, 2020 at 10:36:09AM -0700, Ben Levinsky wrote:
> Add binding for ZynqMP R5 OpenAMP.
>
> Represent the RPU domain resources in one device node. Each RPU
> processor is a subnode of the top RPU domain node.
This needs to be sorted out as part of the system DT effort that Xilinx is working on. I can't see this binding co-existing with it.
>
> Signed-off-by: Ben Levinsky <ben.levinsky@xilinx.com>
> Signed-off-by: Jason Wu <j.wu@xilinx.com>
> Signed-off-by: Wendy Liang <jliang@xilinx.com>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
> Changes since v2:
> - update zynqmp_r5 yaml parsing to not raise warnings for extra
> information in children of R5 node. The warning "node has a unit
> name, but no reg or ranges property" will still be raised though
> as this particular node is needed to describe the
> '#address-cells' and '#size-cells' information.
> Changes since 3:
> - remove warning '/example-0/rpu@ff9a0000/r5@0:
> node has a unit name, but no reg or ranges property'
> by adding reg to r5 node.
> ---
>
> .../remoteproc/xilinx,zynqmp-r5-remoteproc.yaml | 127 +++++++++++++++++++++
> 1 file changed, 127 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remotepr
> oc.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remote
> proc.yaml
> b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remote
> proc.yaml
> new file mode 100644
> index 0000000..41520b6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-re
> +++ moteproc.yaml
> @@ -0,0 +1,127 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Xilinx R5 remote processor controller bindings
> +
> +description:
> + This document defines the binding for the remoteproc component that
> +loads and
> + boots firmwares on the Xilinx Zynqmp and Versal family chipset.
> +
> +maintainers:
> + - Ed Mooring <ed.mooring@xilinx.com>
> + - Ben Levinsky <ben.levinsky@xilinx.com>
> +
> +properties:
> + compatible:
> + const: "xlnx,zynqmp-r5-remoteproc-1.0"
> +
> + core_conf:
> + description:
> + R5 core configuration (valid string - split or lock-step)
> + maxItems: 1
> +
> + interrupts:
> + description:
> + Interrupt mapping for remoteproc IPI. It is required if the
> + user uses the remoteproc driver with the RPMsg kernel driver.
> + maxItems: 6
> +
> + memory-region:
> + maxItems: 4
> + minItems: 4
> + pnode-id:
> + maxItems: 1
What is this?
[Ben Levinsky] I will description for this. This is used by the Xilinx power management code later on when configuring the RPU.
> + mboxes:
> + maxItems: 2
> + mbox-names:
> + maxItems: 2
> +
> + r5@0:
> + type: object
> + required:
> + - '#address-cells'
> + - '#size-cells'
> + - pnode-id
> +examples:
> + - |
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + rpu0vdev0vring0: rpu0vdev0vring0@3ed40000 {
> + no-map;
> + reg = <0x3ed40000 0x4000>;
> + };
> + rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 {
> + no-map;
> + reg = <0x3ed44000 0x4000>;
> + };
> + rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 {
> + no-map;
> + reg = <0x3ed48000 0x100000>;
> + };
> + rproc_0_reserved: rproc@3ed000000 {
> + no-map;
> + reg = <0x3ed00000 0x40000>;
> + };
> + };
> + rpu: rpu@ff9a0000 {
> + compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + core_conf = "split";
If split, then where is the 2nd core?
[Ben Levinsky] Will fix, I will add second core in v5.
> + reg = <0xFF9A0000 0x10000>;
> + r5_0: r5@0 {
Unit-addresses are based on 'reg' values.
[Ben Levinsky] Will fix this, thanks
> + ranges;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xFF9A0100 0x1000>;
> + memory-region = <&rproc_0_reserved>, <&rpu0vdev0buffer>, <&rpu0vdev0vring0>, <&rpu0vdev0vring1>;
> + pnode-id = <0x7>;
> + mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>;
> + mbox-names = "tx", "rx";
> + tcm_0_a: tcm_0@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xFFE00000 0x10000>;
> + pnode-id = <0xf>;
These nodes probably need some sort of compatible. And don't the TCMs have different addresses for R5 vs. the A cores?
[Ben Levinsky] I can add a compatible. The addressesing here is absolute (i.e. 0xffex-xxxx ) as it is used from point of view of A core here.
> + };
> + tcm_0_b: tcm_0@1 {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + reg = <0xFFE20000 0x10000>;
> + pnode-id = <0x10>;
> + };
> + };
> + };
> +
> +
> + zynqmp_ipi1 {
> + compatible = "xlnx,zynqmp-ipi-mailbox";
> + interrupt-parent = <&gic>;
> + interrupts = <0 29 4>;
> + xlnx,ipi-id = <7>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + /* APU<->RPU0 IPI mailbox controller */
> + ipi_mailbox_rpu0: mailbox@ff90000 {
> + reg = <0xff990600 0x20>,
> + <0xff990620 0x20>,
> + <0xff9900c0 0x20>,
> + <0xff9900e0 0x20>;
> + reg-names = "local_request_region",
> + "local_response_region",
> + "remote_request_region",
> + "remote_response_region";
> + #mbox-cells = <1>;
> + xlnx,ipi-id = <1>;
> + };
> + };
> +
> +...
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v15 00/11] Convert PWM period and duty cycle to u64
From: Guru Das Srinagesh @ 2020-05-26 17:35 UTC (permalink / raw)
To: linux-pwm, Thierry Reding, Uwe Kleine-König
Cc: linux-arm-kernel, Guru Das Srinagesh, Daniel Thompson,
Arnd Bergmann, David Collins, Stephen Boyd, linux-kernel,
Geert Uytterhoeven, Dan Carpenter, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck
Because period and duty cycle are defined in the PWM framework structs as ints
with units of nanoseconds, the maximum time duration that can be set is limited
to ~2.147 seconds. Consequently, applications desiring to set greater time
periods via the PWM framework are not be able to do so - like, for instance,
causing an LED to blink at an interval of 5 seconds.
Redefining the period and duty cycle struct members in the core PWM framework
structs as u64 values will enable larger time durations to be set and solve
this problem. Such a change to the framework mandates that drivers using these
struct members (and corresponding helper functions) also be modified correctly
in order to prevent compilation errors.
This patch series introduces the changes to all the drivers first, followed by
the framework change at the very end so that when the latter is applied, all
the drivers are in good shape and there are no compilation errors.
Changes from v14:
- Collected Uwe's Acked-by for the pwm core patch.
- Addressed comments in pwm-clps711x.c.
Changes from v13:
- Pruned cc-list and added same (reduced) set of reviewers to all patches.
- Added Lee Jones' Acked-by to the pwm_bl.c patch.
- Added Jani Nikula's Acked-by to intel-panel.c patch.
- Added Stephen Boyd's Acked-by to pwm-clk.c patch.
- Addressed Geert's review comments in clps711x.c patch.
Changes from v12:
- Rebased to tip of for-next
- Collected Acked-by for sun4i
- Reworked patch for intel-panel.c due to rebase, dropped Jani's Acked-by as
a result
Changes from v11:
- Rebased to tip of for-next.
- Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
- Squished stm32-lp.c change with final patch in series
- sun4i: Used nsecs_to_jiffies()
- imx27: Added overflow handling logic
- clps711x: Corrected the if condition for skipping the division
- clk: pwm: Reverted to v8 version, added check to prevent division-by-zero
Changes from v10:
- Carefully added back all the "Reviewed-by: " and "Acked-by: " tags received
so far that had gotten missed in v9. No other changes.
Changes from v9:
- Gathered the received "Reviewed-by: " tag
- Added back the clk-pwm.c patch because kbuild test robot complained [3]
and addressed received review comments.
- clps711x: Addressed review comments.
Changes from v8:
- Gathered all received "Acked-by: " and "Reviewed-by: " tags
- Dropped patch to clk-pwm.c for reasons mentiond in [2]
- Expanded audience of unreviewed patches
Changes from v7:
- Changed commit messages of all patches to be brief and to the point.
- Added explanation of change in cover letter.
- Dropped change to pwm-sti.c as upon review it was unnecessary as struct
pwm_capture is not being modified in the PWM core.
Changes from v6:
- Split out the driver changes out into separate patches, one patch per file
for ease of reviewing.
Changes from v5:
- Dropped the conversion of struct pwm_capture to u64 for reasons mentioned
in https://www.spinics.net/lists/linux-pwm/msg11541.html
Changes from v4:
- Split the patch into two: one for changes to the drivers, and the actual
switch to u64 for ease of reverting should the need arise.
- Re-examined the patch and made the following corrections:
* intel_panel.c:
DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be
64-bit in this case).
* pwm-sti.c:
do_div -> div_u64 (do_div is optimized only for x86 architectures, and
div_u64's comment block suggests to use this as much as possible).
Changes from v3:
- Rebased to current tip of for-next.
Changes from v2:
- Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot
- Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c
Changes from v1:
- Fixed compilation errors seen when compiling for different archs.
v1:
- Reworked the change pushed upstream earlier [1] so as to not add an
extension to an obsolete API. With this change, pwm_ops->apply() can be
used to set pwm_state parameters as usual.
[1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
[2] https://lore.kernel.org/lkml/20200312190859.GA19605@xxxxxxxxxxxxxx/
[3] https://www.spinics.net/lists/linux-pwm/msg11906.html
[4] https://www.spinics.net/lists/linux-pwm/msg11986.html
Guru Das Srinagesh (11):
drm/i915: Use 64-bit division macro
hwmon: pwm-fan: Use 64-bit division macro
ir-rx51: Use 64-bit division macro
pwm: clps711x: Use 64-bit division macro
pwm: pwm-imx-tpm: Use 64-bit division macro
pwm: imx27: Use 64-bit division macro and function
pwm: sifive: Use 64-bit division macro
pwm: sun4i: Use nsecs_to_jiffies to avoid a division
backlight: pwm_bl: Use 64-bit division function
clk: pwm: Use 64-bit division function
pwm: core: Convert period and duty cycle to u64
drivers/clk/clk-pwm.c | 7 +++-
drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
drivers/hwmon/pwm-fan.c | 2 +-
drivers/media/rc/ir-rx51.c | 3 +-
drivers/pwm/core.c | 14 ++++----
drivers/pwm/pwm-clps711x.c | 2 +-
drivers/pwm/pwm-imx-tpm.c | 2 +-
drivers/pwm/pwm-imx27.c | 53 +++++++++++++++++++++++++-----
drivers/pwm/pwm-sifive.c | 2 +-
drivers/pwm/pwm-stm32-lp.c | 2 +-
drivers/pwm/pwm-sun4i.c | 2 +-
drivers/pwm/sysfs.c | 8 ++---
drivers/video/backlight/pwm_bl.c | 3 +-
include/linux/pwm.h | 12 +++----
14 files changed, 79 insertions(+), 35 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v15 08/11] pwm: sun4i: Use nsecs_to_jiffies to avoid a division
From: Guru Das Srinagesh @ 2020-05-26 17:35 UTC (permalink / raw)
To: linux-pwm, Thierry Reding, Uwe Kleine-König
Cc: linux-arm-kernel, Guru Das Srinagesh, Daniel Thompson,
Arnd Bergmann, David Collins, Stephen Boyd, linux-kernel,
Geert Uytterhoeven, Dan Carpenter, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck
In-Reply-To: <cover.1590514331.git.gurus@codeaurora.org>
Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using nsecs_to_jiffies() which
does away with the need for a division operation.
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/pwm/pwm-sun4i.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 5c677c5..1694e69 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -285,7 +285,7 @@ static int sun4i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
val = (duty & PWM_DTY_MASK) | PWM_PRD(period);
sun4i_pwm_writel(sun4i_pwm, val, PWM_CH_PRD(pwm->hwpwm));
sun4i_pwm->next_period[pwm->hwpwm] = jiffies +
- usecs_to_jiffies(cstate.period / 1000 + 1);
+ nsecs_to_jiffies(cstate.period + 1000);
if (state->polarity != PWM_POLARITY_NORMAL)
ctrl &= ~BIT_CH(PWM_ACT_STATE, pwm->hwpwm);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 11/11] pwm: core: Convert period and duty cycle to u64
From: Guru Das Srinagesh @ 2020-05-26 17:35 UTC (permalink / raw)
To: linux-pwm, Thierry Reding, Uwe Kleine-König
Cc: linux-arm-kernel, Guru Das Srinagesh, Daniel Thompson,
Arnd Bergmann, David Collins, Stephen Boyd, linux-kernel,
Geert Uytterhoeven, Dan Carpenter, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck
In-Reply-To: <cover.1590514331.git.gurus@codeaurora.org>
Because period and duty cycle are defined as ints with units of
nanoseconds, the maximum time duration that can be set is limited to
~2.147 seconds. Change their definitions to u64 in the structs of the
PWM framework so that higher durations may be set.
Also use the right format specifiers in debug prints in both core.c as
well as pwm-stm32-lp.c.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/core.c | 14 +++++++-------
drivers/pwm/pwm-stm32-lp.c | 2 +-
drivers/pwm/sysfs.c | 8 ++++----
include/linux/pwm.h | 12 ++++++------
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index bca0496..a2ff6dd 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -510,12 +510,12 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
last->period > s2.period &&
last->period <= state->period)
dev_warn(chip->dev,
- ".apply didn't pick the best available period (requested: %u, applied: %u, possible: %u)\n",
+ ".apply didn't pick the best available period (requested: %llu, applied: %llu, possible: %llu)\n",
state->period, s2.period, last->period);
if (state->enabled && state->period < s2.period)
dev_warn(chip->dev,
- ".apply is supposed to round down period (requested: %u, applied: %u)\n",
+ ".apply is supposed to round down period (requested: %llu, applied: %llu)\n",
state->period, s2.period);
if (state->enabled &&
@@ -524,14 +524,14 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
last->duty_cycle > s2.duty_cycle &&
last->duty_cycle <= state->duty_cycle)
dev_warn(chip->dev,
- ".apply didn't pick the best available duty cycle (requested: %u/%u, applied: %u/%u, possible: %u/%u)\n",
+ ".apply didn't pick the best available duty cycle (requested: %llu/%llu, applied: %llu/%llu, possible: %llu/%llu)\n",
state->duty_cycle, state->period,
s2.duty_cycle, s2.period,
last->duty_cycle, last->period);
if (state->enabled && state->duty_cycle < s2.duty_cycle)
dev_warn(chip->dev,
- ".apply is supposed to round down duty_cycle (requested: %u/%u, applied: %u/%u)\n",
+ ".apply is supposed to round down duty_cycle (requested: %llu/%llu, applied: %llu/%llu)\n",
state->duty_cycle, state->period,
s2.duty_cycle, s2.period);
@@ -558,7 +558,7 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
(s1.enabled && s1.period != last->period) ||
(s1.enabled && s1.duty_cycle != last->duty_cycle)) {
dev_err(chip->dev,
- ".apply is not idempotent (ena=%d pol=%d %u/%u) -> (ena=%d pol=%d %u/%u)\n",
+ ".apply is not idempotent (ena=%d pol=%d %llu/%llu) -> (ena=%d pol=%d %llu/%llu)\n",
s1.enabled, s1.polarity, s1.duty_cycle, s1.period,
last->enabled, last->polarity, last->duty_cycle,
last->period);
@@ -1284,8 +1284,8 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
if (state.enabled)
seq_puts(s, " enabled");
- seq_printf(s, " period: %u ns", state.period);
- seq_printf(s, " duty: %u ns", state.duty_cycle);
+ seq_printf(s, " period: %llu ns", state.period);
+ seq_printf(s, " duty: %llu ns", state.duty_cycle);
seq_printf(s, " polarity: %s",
state.polarity ? "inverse" : "normal");
diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
index 67fca62..134c146 100644
--- a/drivers/pwm/pwm-stm32-lp.c
+++ b/drivers/pwm/pwm-stm32-lp.c
@@ -61,7 +61,7 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,
do_div(div, NSEC_PER_SEC);
if (!div) {
/* Clock is too slow to achieve requested period. */
- dev_dbg(priv->chip.dev, "Can't reach %u ns\n", state->period);
+ dev_dbg(priv->chip.dev, "Can't reach %llu ns\n", state->period);
return -EINVAL;
}
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 2389b86..449dbc0 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -42,7 +42,7 @@ static ssize_t period_show(struct device *child,
pwm_get_state(pwm, &state);
- return sprintf(buf, "%u\n", state.period);
+ return sprintf(buf, "%llu\n", state.period);
}
static ssize_t period_store(struct device *child,
@@ -52,10 +52,10 @@ static ssize_t period_store(struct device *child,
struct pwm_export *export = child_to_pwm_export(child);
struct pwm_device *pwm = export->pwm;
struct pwm_state state;
- unsigned int val;
+ u64 val;
int ret;
- ret = kstrtouint(buf, 0, &val);
+ ret = kstrtou64(buf, 0, &val);
if (ret)
return ret;
@@ -77,7 +77,7 @@ static ssize_t duty_cycle_show(struct device *child,
pwm_get_state(pwm, &state);
- return sprintf(buf, "%u\n", state.duty_cycle);
+ return sprintf(buf, "%llu\n", state.duty_cycle);
}
static ssize_t duty_cycle_store(struct device *child,
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 2635b2a..a13ff38 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -39,7 +39,7 @@ enum pwm_polarity {
* current PWM hardware state.
*/
struct pwm_args {
- unsigned int period;
+ u64 period;
enum pwm_polarity polarity;
};
@@ -56,8 +56,8 @@ enum {
* @enabled: PWM enabled status
*/
struct pwm_state {
- unsigned int period;
- unsigned int duty_cycle;
+ u64 period;
+ u64 duty_cycle;
enum pwm_polarity polarity;
bool enabled;
};
@@ -107,13 +107,13 @@ static inline bool pwm_is_enabled(const struct pwm_device *pwm)
return state.enabled;
}
-static inline void pwm_set_period(struct pwm_device *pwm, unsigned int period)
+static inline void pwm_set_period(struct pwm_device *pwm, u64 period)
{
if (pwm)
pwm->state.period = period;
}
-static inline unsigned int pwm_get_period(const struct pwm_device *pwm)
+static inline u64 pwm_get_period(const struct pwm_device *pwm)
{
struct pwm_state state;
@@ -128,7 +128,7 @@ static inline void pwm_set_duty_cycle(struct pwm_device *pwm, unsigned int duty)
pwm->state.duty_cycle = duty;
}
-static inline unsigned int pwm_get_duty_cycle(const struct pwm_device *pwm)
+static inline u64 pwm_get_duty_cycle(const struct pwm_device *pwm)
{
struct pwm_state state;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 10/11] clk: pwm: Use 64-bit division function
From: Guru Das Srinagesh @ 2020-05-26 17:35 UTC (permalink / raw)
To: linux-pwm, Thierry Reding, Uwe Kleine-König
Cc: linux-arm-kernel, Guru Das Srinagesh, Daniel Thompson,
Arnd Bergmann, David Collins, Stephen Boyd, linux-kernel,
Geert Uytterhoeven, Dan Carpenter, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck
In-Reply-To: <cover.1590514331.git.gurus@codeaurora.org>
Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by using div64_u64() to handle a
64-bit divisor.
Also ensure that divide-by-zero (with fixed_rate as denominator) does
not happen with an explicit check with probe failure as a consequence.
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Stephen Boyd <sboyd@kernel.org>
---
drivers/clk/clk-pwm.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
index 87fe0b0e..86f2e2d 100644
--- a/drivers/clk/clk-pwm.c
+++ b/drivers/clk/clk-pwm.c
@@ -89,7 +89,12 @@ static int clk_pwm_probe(struct platform_device *pdev)
}
if (of_property_read_u32(node, "clock-frequency", &clk_pwm->fixed_rate))
- clk_pwm->fixed_rate = NSEC_PER_SEC / pargs.period;
+ clk_pwm->fixed_rate = div64_u64(NSEC_PER_SEC, pargs.period);
+
+ if (!clk_pwm->fixed_rate) {
+ dev_err(&pdev->dev, "fixed_rate cannot be zero\n");
+ return -EINVAL;
+ }
if (pargs.period != NSEC_PER_SEC / clk_pwm->fixed_rate &&
pargs.period != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm->fixed_rate)) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 04/11] pwm: clps711x: Use 64-bit division macro
From: Guru Das Srinagesh @ 2020-05-26 17:35 UTC (permalink / raw)
To: linux-pwm, Thierry Reding, Uwe Kleine-König
Cc: linux-arm-kernel, Guru Das Srinagesh, Daniel Thompson,
Arnd Bergmann, David Collins, Stephen Boyd, linux-kernel,
Geert Uytterhoeven, Dan Carpenter, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck
In-Reply-To: <cover.1590514331.git.gurus@codeaurora.org>
Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to
handle a 64-bit divisor.
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
drivers/pwm/pwm-clps711x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
index 924d39a..ba9500a 100644
--- a/drivers/pwm/pwm-clps711x.c
+++ b/drivers/pwm/pwm-clps711x.c
@@ -43,7 +43,7 @@ static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v)
static unsigned int clps711x_get_duty(struct pwm_device *pwm, unsigned int v)
{
/* Duty cycle 0..15 max */
- return DIV_ROUND_CLOSEST(v * 0xf, pwm->args.period);
+ return DIV64_U64_ROUND_CLOSEST(v * 0xf, pwm->args.period);
}
static int clps711x_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 02/11] hwmon: pwm-fan: Use 64-bit division macro
From: Guru Das Srinagesh @ 2020-05-26 17:35 UTC (permalink / raw)
To: linux-pwm, Thierry Reding, Uwe Kleine-König
Cc: linux-arm-kernel, Guru Das Srinagesh, Daniel Thompson,
Arnd Bergmann, David Collins, Stephen Boyd, linux-kernel,
Geert Uytterhoeven, Dan Carpenter, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck
In-Reply-To: <cover.1590514331.git.gurus@codeaurora.org>
Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle
a 64-bit dividend.
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/hwmon/pwm-fan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 30b7b3e..17bb642 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -447,7 +447,7 @@ static int pwm_fan_resume(struct device *dev)
return 0;
pwm_get_args(ctx->pwm, &pargs);
- duty = DIV_ROUND_UP(ctx->pwm_value * (pargs.period - 1), MAX_PWM);
+ duty = DIV_ROUND_UP_ULL(ctx->pwm_value * (pargs.period - 1), MAX_PWM);
ret = pwm_config(ctx->pwm, duty, pargs.period);
if (ret)
return ret;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 03/11] ir-rx51: Use 64-bit division macro
From: Guru Das Srinagesh @ 2020-05-26 17:35 UTC (permalink / raw)
To: linux-pwm, Thierry Reding, Uwe Kleine-König
Cc: linux-arm-kernel, Guru Das Srinagesh, Daniel Thompson,
Arnd Bergmann, David Collins, Stephen Boyd, linux-kernel,
Geert Uytterhoeven, Dan Carpenter, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck
In-Reply-To: <cover.1590514331.git.gurus@codeaurora.org>
Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using DIV_ROUND_CLOSEST_ULL to
handle a 64-bit dividend.
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Sean Young <sean@mess.org>
---
drivers/media/rc/ir-rx51.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 8574eda..9a5dfd7 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -241,7 +241,8 @@ static int ir_rx51_probe(struct platform_device *dev)
}
/* Use default, in case userspace does not set the carrier */
- ir_rx51.freq = DIV_ROUND_CLOSEST(pwm_get_period(pwm), NSEC_PER_SEC);
+ ir_rx51.freq = DIV_ROUND_CLOSEST_ULL(pwm_get_period(pwm),
+ NSEC_PER_SEC);
pwm_put(pwm);
hrtimer_init(&ir_rx51.timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 09/11] backlight: pwm_bl: Use 64-bit division function
From: Guru Das Srinagesh @ 2020-05-26 17:35 UTC (permalink / raw)
To: linux-pwm, Thierry Reding, Uwe Kleine-König
Cc: linux-arm-kernel, Guru Das Srinagesh, Daniel Thompson,
Arnd Bergmann, David Collins, Stephen Boyd, linux-kernel,
Geert Uytterhoeven, Dan Carpenter, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck
In-Reply-To: <cover.1590514331.git.gurus@codeaurora.org>
Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using div_u64 to handle a 64-bit
dividend instead of a straight division operation.
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
drivers/video/backlight/pwm_bl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 82b8d75..464baad 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -606,7 +606,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->scale = data->max_brightness;
}
- pb->lth_brightness = data->lth_brightness * (state.period / pb->scale);
+ pb->lth_brightness = data->lth_brightness * (div_u64(state.period,
+ pb->scale));
props.type = BACKLIGHT_RAW;
props.max_brightness = data->max_brightness;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 01/11] drm/i915: Use 64-bit division macro
From: Guru Das Srinagesh @ 2020-05-26 17:35 UTC (permalink / raw)
To: linux-pwm, Thierry Reding, Uwe Kleine-König
Cc: linux-arm-kernel, Guru Das Srinagesh, Daniel Thompson,
Arnd Bergmann, David Collins, Stephen Boyd, linux-kernel,
Geert Uytterhoeven, Dan Carpenter, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck
In-Reply-To: <cover.1590514331.git.gurus@codeaurora.org>
Since the PWM framework is switching struct pwm_state.duty_cycle's
datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
to handle a 64-bit dividend.
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
---
drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c
index 276f438..81547a0 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1920,7 +1920,7 @@ static int pwm_setup_backlight(struct intel_connector *connector,
return retval;
}
- level = DIV_ROUND_UP(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
+ level = DIV_ROUND_UP_ULL(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
CRC_PMIC_PWM_PERIOD_NS);
panel->backlight.level =
intel_panel_compute_brightness(connector, level);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 06/11] pwm: imx27: Use 64-bit division macro and function
From: Guru Das Srinagesh @ 2020-05-26 17:35 UTC (permalink / raw)
To: linux-pwm, Thierry Reding, Uwe Kleine-König
Cc: linux-arm-kernel, Guru Das Srinagesh, Daniel Thompson,
Fabio Estevam, Arnd Bergmann, David Collins, Stephen Boyd,
Shawn Guo, Sascha Hauer, linux-kernel, Geert Uytterhoeven,
Dan Carpenter, Pengutronix Kernel Team, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck,
NXP Linux Team
In-Reply-To: <cover.1590514331.git.gurus@codeaurora.org>
Since the PWM framework is switching struct pwm_state.period's
datatype to u64, prepare for this transition by using
DIV_ROUND_UP_ULL to handle a 64-bit dividend, and div64_u64 to handle a
64-bit divisor.
Also handle a possible overflow in the calculation of period_cycles when
both clk_rate and period are large numbers. This logic was unit-tested
out by calculating period_cycles using both the existing logic and the
proposed one, and the results are as below.
----------------------------------------------------------------------------
clk_rate period existing proposed
----------------------------------------------------------------------------
1000000000 18446744073709551615 18446744072 18446744073000000000
(U64_MAX)
----------------------------------------------------------------------------
1000000000 4294967291 4294967291 4294967291
----------------------------------------------------------------------------
Overflow occurs in the first case with the existing logic, whereas the
proposed logic handles it better, sacrificing some precision in a best-effort
attempt to handle overflow. As for the second case where there are
more typical values of period, the proposed logic handles that correctly
too.
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
drivers/pwm/pwm-imx27.c | 53 +++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 45 insertions(+), 8 deletions(-)
diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index a6e40d4..164cb65 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -203,7 +203,7 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip,
sr = readl(imx->mmio_base + MX3_PWMSR);
fifoav = FIELD_GET(MX3_PWMSR_FIFOAV, sr);
if (fifoav == MX3_PWMSR_FIFOAV_4WORDS) {
- period_ms = DIV_ROUND_UP(pwm_get_period(pwm),
+ period_ms = DIV_ROUND_UP_ULL(pwm_get_period(pwm),
NSEC_PER_MSEC);
msleep(period_ms);
@@ -213,6 +213,45 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip,
}
}
+static int pwm_imx27_calc_period_cycles(const struct pwm_state *state,
+ unsigned long clk_rate,
+ unsigned long *period_cycles)
+{
+ u64 c = 0, c1, c2;
+
+ c1 = clk_rate;
+ c2 = state->period;
+ if (c2 > c1) {
+ c2 = c1;
+ c1 = state->period;
+ }
+
+ if (!c1 || !c2) {
+ pr_err("clk rate and period should be nonzero\n");
+ return -EINVAL;
+ }
+
+ if (c2 <= div64_u64(U64_MAX, c1)) {
+ c = c1 * c2;
+ do_div(c, 1000000000);
+ } else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000))) {
+ do_div(c1, 1000);
+ c = c1 * c2;
+ do_div(c, 1000000);
+ } else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000000))) {
+ do_div(c1, 1000000);
+ c = c1 * c2;
+ do_div(c, 1000);
+ } else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000000000))) {
+ do_div(c1, 1000000000);
+ c = c1 * c2;
+ }
+
+ *period_cycles = c;
+
+ return 0;
+}
+
static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
const struct pwm_state *state)
{
@@ -225,18 +264,16 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
pwm_get_state(pwm, &cstate);
- c = clk_get_rate(imx->clk_per);
- c *= state->period;
-
- do_div(c, 1000000000);
- period_cycles = c;
+ ret = pwm_imx27_calc_period_cycles(state, clk_get_rate(imx->clk_per),
+ &period_cycles);
+ if (ret)
+ return ret;
prescale = period_cycles / 0x10000 + 1;
period_cycles /= prescale;
c = (unsigned long long)period_cycles * state->duty_cycle;
- do_div(c, state->period);
- duty_cycles = c;
+ duty_cycles = div64_u64(c, state->period);
/*
* according to imx pwm RM, the real period value should be PERIOD
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 05/11] pwm: pwm-imx-tpm: Use 64-bit division macro
From: Guru Das Srinagesh @ 2020-05-26 17:35 UTC (permalink / raw)
To: linux-pwm, Thierry Reding, Uwe Kleine-König
Cc: linux-arm-kernel, Guru Das Srinagesh, Daniel Thompson,
Fabio Estevam, Arnd Bergmann, David Collins, Stephen Boyd,
Shawn Guo, Sascha Hauer, linux-kernel, Geert Uytterhoeven,
Dan Carpenter, Pengutronix Kernel Team, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck,
NXP Linux Team
In-Reply-To: <cover.1590514331.git.gurus@codeaurora.org>
Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to
handle a 64-bit divisor.
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
drivers/pwm/pwm-imx-tpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-imx-tpm.c b/drivers/pwm/pwm-imx-tpm.c
index 5f3d7f7..fcdf6be 100644
--- a/drivers/pwm/pwm-imx-tpm.c
+++ b/drivers/pwm/pwm-imx-tpm.c
@@ -124,7 +124,7 @@ static int pwm_imx_tpm_round_state(struct pwm_chip *chip,
real_state->duty_cycle = state->duty_cycle;
tmp = (u64)p->mod * real_state->duty_cycle;
- p->val = DIV_ROUND_CLOSEST_ULL(tmp, real_state->period);
+ p->val = DIV64_U64_ROUND_CLOSEST(tmp, real_state->period);
real_state->polarity = state->polarity;
real_state->enabled = state->enabled;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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