* [PATCH v7 1/5] dt-bindings: vendor: add vendor prefix for LiteX
From: Mateusz Holenko @ 2020-06-04 10:13 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-serial
Cc: Stafford Horne, Karol Gugala, Mateusz Holenko,
Mauro Carvalho Chehab, David S. Miller, Paul E. McKenney,
Filip Kokosinski, Pawel Czarnecki, Joel Stanley, Jonathan Cameron,
Maxime Ripard, Shawn Guo, Heiko Stuebner, Sam Ravnborg,
Icenowy Zheng, Laurent Pinchart, linux-kernel, Gabriel L. Somlo
In-Reply-To: <20200604121142.2964437-0-mholenko@antmicro.com>
From: Filip Kokosinski <fkokosinski@antmicro.com>
Add vendor prefix for LiteX SoC builder.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Notes:
No changes in v7.
No changes in v6.
No changes in v5.
No changes in v4.
Changes in v3:
- added Acked-by tag
No changes in v2.
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 997934c58f9a..d2eaddc473ac 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -575,6 +575,8 @@ patternProperties:
description: Linux-specific binding
"^linx,.*":
description: Linx Technologies
+ "^litex,.*":
+ description: LiteX SoC builder
"^lltc,.*":
description: Linear Technology Corporation
"^logicpd,.*":
--
2.25.1
^ permalink raw reply related
* [PATCH v7 2/5] dt-bindings: soc: document LiteX SoC Controller bindings
From: Mateusz Holenko @ 2020-06-04 10:13 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-serial
Cc: Stafford Horne, Karol Gugala, Mateusz Holenko,
Mauro Carvalho Chehab, David S. Miller, Paul E. McKenney,
Filip Kokosinski, Pawel Czarnecki, Joel Stanley, Jonathan Cameron,
Maxime Ripard, Shawn Guo, Heiko Stuebner, Sam Ravnborg,
Icenowy Zheng, Laurent Pinchart, linux-kernel, Gabriel L. Somlo
In-Reply-To: <20200604121142.2964437-0-mholenko@antmicro.com>
From: Pawel Czarnecki <pczarnecki@internships.antmicro.com>
Add documentation for LiteX SoC Controller bindings.
Signed-off-by: Pawel Czarnecki <pczarnecki@internships.antmicro.com>
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Notes:
No changes in v7.
Changes in v6:
- fixed license header
Changes in v5:
- added reviewed-by tag
Changes in v4:
- changes compatible to "litex,soc-controller"
- fixed yaml's header
- removed unnecessary sections from yaml
- fixed indentation in yaml
This commit has been introduced in v3 of the patchset.
.../soc/litex/litex,soc-controller.yaml | 39 +++++++++++++++++++
MAINTAINERS | 6 +++
2 files changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
diff --git a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
new file mode 100644
index 000000000000..53121c1fbe4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright 2020 Antmicro <www.antmicro.com>
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/litex/litex,soc-controller.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: LiteX SoC Controller driver
+
+description: |
+ This is the SoC Controller driver for the LiteX SoC Builder.
+ It's purpose is to verify LiteX CSR (Control&Status Register) access
+ operations and provide function for other drivers to read/write CSRs
+ and to check if those accessors are ready to use.
+
+maintainers:
+ - Karol Gugala <kgugala@antmicro.com>
+ - Mateusz Holenko <mholenko@antmicro.com>
+
+properties:
+ compatible:
+ const: litex,soc-controller
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ soc_ctrl0: soc-controller@f0000000 {
+ compatible = "litex,soc-controller";
+ reg = <0x0 0xf0000000 0x0 0xC>;
+ status = "okay";
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc1dc7e535e..e3f8804c08d7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9918,6 +9918,12 @@ L: kunit-dev@googlegroups.com
S: Maintained
F: lib/list-test.c
+LITEX PLATFORM
+M: Karol Gugala <kgugala@antmicro.com>
+M: Mateusz Holenko <mholenko@antmicro.com>
+S: Maintained
+F: Documentation/devicetree/bindings/*/litex,*.yaml
+
LIVE PATCHING
M: Josh Poimboeuf <jpoimboe@redhat.com>
M: Jiri Kosina <jikos@kernel.org>
--
2.25.1
^ permalink raw reply related
* [PATCH v7 3/5] drivers/soc/litex: add LiteX SoC Controller driver
From: Mateusz Holenko @ 2020-06-04 10:13 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-serial
Cc: Stafford Horne, Karol Gugala, Mateusz Holenko,
Mauro Carvalho Chehab, David S. Miller, Paul E. McKenney,
Filip Kokosinski, Pawel Czarnecki, Joel Stanley, Jonathan Cameron,
Maxime Ripard, Shawn Guo, Heiko Stuebner, Sam Ravnborg,
Icenowy Zheng, Laurent Pinchart, linux-kernel, Gabriel L. Somlo
In-Reply-To: <20200604121142.2964437-0-mholenko@antmicro.com>
From: Pawel Czarnecki <pczarnecki@internships.antmicro.com>
This commit adds driver for the FPGA-based LiteX SoC
Controller from LiteX SoC builder.
Co-developed-by: Mateusz Holenko <mholenko@antmicro.com>
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
Signed-off-by: Pawel Czarnecki <pczarnecki@internships.antmicro.com>
---
Notes:
No changes in v7.
Changes in v6:
- added dependency on OF || COMPILE_TEST
- used le32_to_cpu(readl(addr)) instead of __raw_readl
and writel(cpu_to_le32(value), addr) instead of __raw_writel
to take advantage of memory barriers provided by readl/writel
Changes in v5:
- removed helper accessors and used __raw_readl/__raw_writel instead
- fixed checking for errors in litex_soc_ctrl_probe
Changes in v4:
- fixed indent in Kconfig's help section
- fixed copyright header
- changed compatible to "litex,soc-controller"
- simplified litex_soc_ctrl_probe
- removed unnecessary litex_soc_ctrl_remove
This commit has been introduced in v3 of the patchset.
It includes a simplified version of common 'litex.h'
header introduced in v2 of the patchset.
MAINTAINERS | 2 +
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/litex/Kconfig | 15 +++
drivers/soc/litex/Makefile | 3 +
drivers/soc/litex/litex_soc_ctrl.c | 197 +++++++++++++++++++++++++++++
include/linux/litex.h | 45 +++++++
7 files changed, 264 insertions(+)
create mode 100644 drivers/soc/litex/Kconfig
create mode 100644 drivers/soc/litex/Makefile
create mode 100644 drivers/soc/litex/litex_soc_ctrl.c
create mode 100644 include/linux/litex.h
diff --git a/MAINTAINERS b/MAINTAINERS
index e3f8804c08d7..b6d926a6ed04 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9923,6 +9923,8 @@ M: Karol Gugala <kgugala@antmicro.com>
M: Mateusz Holenko <mholenko@antmicro.com>
S: Maintained
F: Documentation/devicetree/bindings/*/litex,*.yaml
+F: drivers/soc/litex/litex_soc_ctrl.c
+F: include/linux/litex.h
LIVE PATCHING
M: Josh Poimboeuf <jpoimboe@redhat.com>
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 425ab6f7e375..d097d070f579 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -9,6 +9,7 @@ source "drivers/soc/bcm/Kconfig"
source "drivers/soc/fsl/Kconfig"
source "drivers/soc/imx/Kconfig"
source "drivers/soc/ixp4xx/Kconfig"
+source "drivers/soc/litex/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/renesas/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 36452bed86ef..0b16108823ef 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_ARCH_GEMINI) += gemini/
obj-y += imx/
obj-$(CONFIG_ARCH_IXP4XX) += ixp4xx/
obj-$(CONFIG_SOC_XWAY) += lantiq/
+obj-$(CONFIG_LITEX_SOC_CONTROLLER) += litex/
obj-y += mediatek/
obj-y += amlogic/
obj-y += qcom/
diff --git a/drivers/soc/litex/Kconfig b/drivers/soc/litex/Kconfig
new file mode 100644
index 000000000000..c974ec3846bc
--- /dev/null
+++ b/drivers/soc/litex/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License_Identifier: GPL-2.0
+
+menu "Enable LiteX SoC Builder specific drivers"
+
+config LITEX_SOC_CONTROLLER
+ tristate "Enable LiteX SoC Controller driver"
+ depends on OF || COMPILE_TEST
+ help
+ This option enables the SoC Controller Driver which verifies
+ LiteX CSR access and provides common litex_get_reg/litex_set_reg
+ accessors.
+ All drivers that use functions from litex.h must depend on
+ LITEX_SOC_CONTROLLER.
+
+endmenu
diff --git a/drivers/soc/litex/Makefile b/drivers/soc/litex/Makefile
new file mode 100644
index 000000000000..98ff7325b1c0
--- /dev/null
+++ b/drivers/soc/litex/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License_Identifier: GPL-2.0
+
+obj-$(CONFIG_LITEX_SOC_CONTROLLER) += litex_soc_ctrl.o
diff --git a/drivers/soc/litex/litex_soc_ctrl.c b/drivers/soc/litex/litex_soc_ctrl.c
new file mode 100644
index 000000000000..319be92fc63f
--- /dev/null
+++ b/drivers/soc/litex/litex_soc_ctrl.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * LiteX SoC Controller Driver
+ *
+ * Copyright (C) 2020 Antmicro <www.antmicro.com>
+ *
+ */
+
+#include <linux/litex.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/printk.h>
+#include <linux/module.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+
+/*
+ * The parameters below are true for LiteX SoC
+ * configured for 8-bit CSR Bus, 32-bit aligned.
+ *
+ * Supporting other configurations will require
+ * extending the logic in this header.
+ */
+#define LITEX_REG_SIZE 0x4
+#define LITEX_SUBREG_SIZE 0x1
+#define LITEX_SUBREG_SIZE_BIT (LITEX_SUBREG_SIZE * 8)
+
+static DEFINE_SPINLOCK(csr_lock);
+
+/*
+ * LiteX SoC Generator, depending on the configuration,
+ * can split a single logical CSR (Control & Status Register)
+ * into a series of consecutive physical registers.
+ *
+ * For example, in the configuration with 8-bit CSR Bus,
+ * 32-bit aligned (the default one for 32-bit CPUs) a 32-bit
+ * logical CSR will be generated as four 32-bit physical registers,
+ * each one containing one byte of meaningful data.
+ *
+ * For details see: https://github.com/enjoy-digital/litex/wiki/CSR-Bus
+ *
+ * The purpose of `litex_set_reg`/`litex_get_reg` is to implement
+ * the logic of writing to/reading from the LiteX CSR in a single
+ * place that can be then reused by all LiteX drivers.
+ */
+void litex_set_reg(void __iomem *reg, unsigned long reg_size,
+ unsigned long val)
+{
+ unsigned long shifted_data, shift, i;
+ unsigned long flags;
+
+ spin_lock_irqsave(&csr_lock, flags);
+
+ for (i = 0; i < reg_size; ++i) {
+ shift = ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT);
+ shifted_data = val >> shift;
+
+ writel(cpu_to_le32(shifted_data), reg + (LITEX_REG_SIZE * i));
+ }
+
+ spin_unlock_irqrestore(&csr_lock, flags);
+}
+
+unsigned long litex_get_reg(void __iomem *reg, unsigned long reg_size)
+{
+ unsigned long shifted_data, shift, i;
+ unsigned long result = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(&csr_lock, flags);
+
+ for (i = 0; i < reg_size; ++i) {
+ shifted_data = le32_to_cpu(readl(reg + (LITEX_REG_SIZE * i)));
+
+ shift = ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT);
+ result |= (shifted_data << shift);
+ }
+
+ spin_unlock_irqrestore(&csr_lock, flags);
+
+ return result;
+}
+
+static int accessors_ok;
+
+/*
+ * Check if accessors are safe to be used by other drivers
+ * returns true if yes - false if not
+ */
+int litex_check_accessors(void)
+{
+ return accessors_ok;
+}
+
+#define SCRATCH_REG_OFF 0x04
+#define SCRATCH_REG_SIZE 4
+#define SCRATCH_REG_VALUE 0x12345678
+#define SCRATCH_TEST_VALUE 0xdeadbeef
+
+/*
+ * Check LiteX CSR read/write access
+ *
+ * This function reads and writes a scratch register in order
+ * to verify if CSR access works.
+ *
+ * In case any problems are detected, the driver should panic
+ * and not set `accessors_ok` flag. As a result no other
+ * LiteX driver should access CSR bus.
+ *
+ * Access to the LiteX CSR is, by design, done in CPU native
+ * endianness. The driver should not dynamically configure
+ * access functions when the endianness mismatch is detected.
+ * Such situation indicates problems in the soft SoC design
+ * and should be solved at the LiteX generator level,
+ * not in the software.
+ */
+static int litex_check_csr_access(void __iomem *reg_addr)
+{
+ unsigned long reg;
+
+ reg = litex_get_reg(reg_addr + SCRATCH_REG_OFF, SCRATCH_REG_SIZE);
+
+ if (reg != SCRATCH_REG_VALUE) {
+ panic("Scratch register read error! Expected: 0x%x but got: 0x%lx",
+ SCRATCH_REG_VALUE, reg);
+ return -EINVAL;
+ }
+
+ litex_set_reg(reg_addr + SCRATCH_REG_OFF,
+ SCRATCH_REG_SIZE, SCRATCH_TEST_VALUE);
+ reg = litex_get_reg(reg_addr + SCRATCH_REG_OFF, SCRATCH_REG_SIZE);
+
+ if (reg != SCRATCH_TEST_VALUE) {
+ panic("Scratch register write error! Expected: 0x%x but got: 0x%lx",
+ SCRATCH_TEST_VALUE, reg);
+ return -EINVAL;
+ }
+
+ /* restore original value of the SCRATCH register */
+ litex_set_reg(reg_addr + SCRATCH_REG_OFF,
+ SCRATCH_REG_SIZE, SCRATCH_REG_VALUE);
+
+ /* Set flag for other drivers */
+ accessors_ok = 1;
+ pr_info("LiteX SoC Controller driver initialized");
+
+ return 0;
+}
+
+struct litex_soc_ctrl_device {
+ void __iomem *base;
+};
+
+static const struct of_device_id litex_soc_ctrl_of_match[] = {
+ {.compatible = "litex,soc-controller"},
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, litex_soc_ctrl_of_match);
+
+static int litex_soc_ctrl_probe(struct platform_device *pdev)
+{
+ struct device *dev;
+ struct device_node *node;
+ struct litex_soc_ctrl_device *soc_ctrl_dev;
+
+ dev = &pdev->dev;
+ node = dev->of_node;
+ if (!node)
+ return -ENODEV;
+
+ soc_ctrl_dev = devm_kzalloc(dev, sizeof(*soc_ctrl_dev), GFP_KERNEL);
+ if (!soc_ctrl_dev)
+ return -ENOMEM;
+
+ soc_ctrl_dev->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(soc_ctrl_dev->base))
+ return PTR_ERR(soc_ctrl_dev->base);
+
+ return litex_check_csr_access(soc_ctrl_dev->base);
+}
+
+static struct platform_driver litex_soc_ctrl_driver = {
+ .driver = {
+ .name = "litex-soc-controller",
+ .of_match_table = of_match_ptr(litex_soc_ctrl_of_match)
+ },
+ .probe = litex_soc_ctrl_probe,
+};
+
+module_platform_driver(litex_soc_ctrl_driver);
+MODULE_DESCRIPTION("LiteX SoC Controller driver");
+MODULE_AUTHOR("Antmicro <www.antmicro.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/litex.h b/include/linux/litex.h
new file mode 100644
index 000000000000..f31062436273
--- /dev/null
+++ b/include/linux/litex.h
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Common LiteX header providing
+ * helper functions for accessing CSRs.
+ *
+ * Implementation of the functions is provided by
+ * the LiteX SoC Controller driver.
+ *
+ * Copyright (C) 2019-2020 Antmicro <www.antmicro.com>
+ */
+
+#ifndef _LINUX_LITEX_H
+#define _LINUX_LITEX_H
+
+#include <linux/io.h>
+#include <linux/types.h>
+#include <linux/compiler_types.h>
+
+/*
+ * litex_check_accessors is a function implemented in
+ * drivers/soc/litex/litex_soc_controller.c
+ * checking if the common LiteX CSR accessors
+ * are safe to be used by the drivers;
+ * returns true (1) if yes - false (0) if not
+ *
+ * Important: All drivers that use litex_set_reg/litex_get_reg
+ * functions should make sure that LiteX SoC Controller driver
+ * has verified LiteX CSRs read and write operations before
+ * issuing any read/writes to the LiteX peripherals.
+ *
+ * Exemplary snippet that can be used at the beginning
+ * of the driver's probe() function to ensure that LiteX
+ * SoC Controller driver is properely initialized:
+ *
+ * if (!litex_check_accessors())
+ * return -EPROBE_DEFER;
+ */
+int litex_check_accessors(void);
+
+void litex_set_reg(void __iomem *reg, unsigned long reg_sz, unsigned long val);
+
+unsigned long litex_get_reg(void __iomem *reg, unsigned long reg_sz);
+
+
+#endif /* _LINUX_LITEX_H */
--
2.25.1
^ permalink raw reply related
* [PATCH v7 4/5] dt-bindings: serial: document LiteUART bindings
From: Mateusz Holenko @ 2020-06-04 10:14 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-serial
Cc: Stafford Horne, Karol Gugala, Mateusz Holenko,
Mauro Carvalho Chehab, David S. Miller, Paul E. McKenney,
Filip Kokosinski, Pawel Czarnecki, Joel Stanley, Jonathan Cameron,
Maxime Ripard, Shawn Guo, Heiko Stuebner, Sam Ravnborg,
Icenowy Zheng, Laurent Pinchart, linux-kernel, Gabriel L. Somlo
In-Reply-To: <20200604121142.2964437-0-mholenko@antmicro.com>
From: Filip Kokosinski <fkokosinski@antmicro.com>
Add documentation for LiteUART devicetree bindings.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Notes:
No changes in v7.
Changes in v6:
- fixed license header
No changes in v5.
No changes in v4.
Changes in v3:
- added Reviewed-by tag
- patch number changed from 3 to 4
- removed changes in MAINTAINERS file (moved to patch #2)
Changes in v2:
- binding description rewritten to a yaml schema file
- added interrupt line
- fixed unit address
- patch number changed from 2 to 3
.../bindings/serial/litex,liteuart.yaml | 38 +++++++++++++++++++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/litex,liteuart.yaml
diff --git a/Documentation/devicetree/bindings/serial/litex,liteuart.yaml b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml
new file mode 100644
index 000000000000..87bf846b170a
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/litex,liteuart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LiteUART serial controller
+
+maintainers:
+ - Karol Gugala <kgugala@antmicro.com>
+ - Mateusz Holenko <mholenko@antmicro.com>
+
+description: |
+ LiteUART serial controller is a part of LiteX FPGA SoC builder. It supports
+ multiple CPU architectures, currently including e.g. OpenRISC and RISC-V.
+
+properties:
+ compatible:
+ const: litex,liteuart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ uart0: serial@e0001800 {
+ compatible = "litex,liteuart";
+ reg = <0xe0001800 0x100>;
+ interrupts = <2>;
+ };
--
2.25.1
^ permalink raw reply related
* [PATCH v7 5/5] drivers/tty/serial: add LiteUART driver
From: Mateusz Holenko @ 2020-06-04 10:14 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-serial
Cc: Stafford Horne, Karol Gugala, Mateusz Holenko,
Mauro Carvalho Chehab, David S. Miller, Paul E. McKenney,
Filip Kokosinski, Pawel Czarnecki, Joel Stanley, Jonathan Cameron,
Maxime Ripard, Shawn Guo, Heiko Stuebner, Sam Ravnborg,
Icenowy Zheng, Laurent Pinchart, linux-kernel, Gabriel L. Somlo
In-Reply-To: <20200604121142.2964437-0-mholenko@antmicro.com>
From: Filip Kokosinski <fkokosinski@antmicro.com>
This commit adds driver for the FPGA-based LiteUART serial controller
from LiteX SoC builder.
The current implementation supports LiteUART configured
for 32 bit data width and 8 bit CSR bus width.
It does not support IRQ.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
---
Notes:
Changed in v7:
- added missing include directive
Changes in v6:
- LiteUART ports now stored in xArray
- removed PORT_LITEUART
- fixed formatting
- removed some unnecessary defines
No changes in v5.
Changes in v4:
- fixed copyright header
- removed a wrong dependency on UARTLITE from Kconfig
- added a dependency on LITEX_SOC_CONTROLLER to LITEUART in Kconfig
Changes in v3:
- aliases made optional
- used litex_get_reg/litex_set_reg functions instead of macros
- SERIAL_LITEUART_NR_PORTS renamed to SERIAL_LITEUART_MAX_PORTS
- PORT_LITEUART changed from 122 to 123
- added dependency on LITEX_SOC_CONTROLLER
- patch number changed from 4 to 5
No changes in v2.
MAINTAINERS | 1 +
drivers/tty/serial/Kconfig | 31 +++
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/liteuart.c | 405 ++++++++++++++++++++++++++++++++++
4 files changed, 438 insertions(+)
create mode 100644 drivers/tty/serial/liteuart.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b6d926a6ed04..d06d099aa56f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9924,6 +9924,7 @@ M: Mateusz Holenko <mholenko@antmicro.com>
S: Maintained
F: Documentation/devicetree/bindings/*/litex,*.yaml
F: drivers/soc/litex/litex_soc_ctrl.c
+F: drivers/tty/serial/liteuart.c
F: include/linux/litex.h
LIVE PATCHING
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index adf9e80e7dc9..17aaf0afb27a 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1562,6 +1562,37 @@ config SERIAL_MILBEAUT_USIO_CONSOLE
receives all kernel messages and warnings and which allows logins in
single user mode).
+config SERIAL_LITEUART
+ tristate "LiteUART serial port support"
+ depends on HAS_IOMEM
+ depends on OF || COMPILE_TEST
+ depends on LITEX_SOC_CONTROLLER
+ select SERIAL_CORE
+ help
+ This driver is for the FPGA-based LiteUART serial controller from LiteX
+ SoC builder.
+
+ Say 'Y' here if you wish to use the LiteUART serial controller.
+ Otherwise, say 'N'.
+
+config SERIAL_LITEUART_MAX_PORTS
+ int "Maximum number of LiteUART ports"
+ depends on SERIAL_LITEUART
+ default "1"
+ help
+ Set this to the maximum number of serial ports you want the driver
+ to support.
+
+config SERIAL_LITEUART_CONSOLE
+ bool "LiteUART serial port console support"
+ depends on SERIAL_LITEUART=y
+ select SERIAL_CORE_CONSOLE
+ help
+ Say 'Y' here if you wish to use the FPGA-based LiteUART serial controller
+ from LiteX SoC builder as the system console (the system console is the
+ device which receives all kernel messages and warnings and which allows
+ logins in single user mode). Otherwise, say 'N'.
+
endmenu
config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index d056ee6cca33..9f8ba419ff3b 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_SERIAL_OWL) += owl-uart.o
obj-$(CONFIG_SERIAL_RDA) += rda-uart.o
obj-$(CONFIG_SERIAL_MILBEAUT_USIO) += milbeaut_usio.o
obj-$(CONFIG_SERIAL_SIFIVE) += sifive.o
+obj-$(CONFIG_SERIAL_LITEUART) += liteuart.o
# GPIOLIB helpers for modem control lines
obj-$(CONFIG_SERIAL_MCTRL_GPIO) += serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/liteuart.c b/drivers/tty/serial/liteuart.c
new file mode 100644
index 000000000000..b90e51fad281
--- /dev/null
+++ b/drivers/tty/serial/liteuart.c
@@ -0,0 +1,405 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * LiteUART serial controller (LiteX) Driver
+ *
+ * Copyright (C) 2019-2020 Antmicro <www.antmicro.com>
+ */
+
+#include <linux/console.h>
+#include <linux/litex.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/slab.h>
+#include <linux/timer.h>
+#include <linux/tty_flip.h>
+#include <linux/xarray.h>
+
+/*
+ * CSRs definitions (base address offsets + width)
+ *
+ * The definitions below are true for LiteX SoC configured for 8-bit CSR Bus,
+ * 32-bit aligned.
+ *
+ * Supporting other configurations might require new definitions or a more
+ * generic way of indexing the LiteX CSRs.
+ *
+ * For more details on how CSRs are defined and handled in LiteX, see comments
+ * in the LiteX SoC Driver: drivers/soc/litex/litex_soc_ctrl.c
+ */
+#define OFF_RXTX 0x00
+#define OFF_TXFULL 0x04
+#define OFF_RXEMPTY 0x08
+#define OFF_EV_STATUS 0x0c
+#define OFF_EV_PENDING 0x10
+#define OFF_EV_ENABLE 0x14
+
+/* events */
+#define EV_TX 0x1
+#define EV_RX 0x2
+
+struct liteuart_port {
+ struct uart_port port;
+ struct timer_list timer;
+};
+
+#define to_liteuart_port(port) container_of(port, struct liteuart_port, port)
+
+static DEFINE_XARRAY_FLAGS(liteuart_array, XA_FLAGS_ALLOC);
+
+#ifdef CONFIG_SERIAL_LITEUART_CONSOLE
+static struct console liteuart_console;
+#endif
+
+static struct uart_driver liteuart_driver = {
+ .owner = THIS_MODULE,
+ .driver_name = "liteuart",
+ .dev_name = "ttyLXU",
+ .major = 0,
+ .minor = 0,
+ .nr = CONFIG_SERIAL_LITEUART_MAX_PORTS,
+#ifdef CONFIG_SERIAL_LITEUART_CONSOLE
+ .cons = &liteuart_console,
+#endif
+};
+
+static void liteuart_timer(struct timer_list *t)
+{
+ struct liteuart_port *uart = from_timer(uart, t, timer);
+ struct uart_port *port = &uart->port;
+ unsigned char __iomem *membase = port->membase;
+ unsigned int flg = TTY_NORMAL;
+ int ch;
+ unsigned long status;
+
+ while ((status = !litex_get_reg(membase + OFF_RXEMPTY, 1)) == 1) {
+ ch = litex_get_reg(membase + OFF_RXTX, 1);
+ port->icount.rx++;
+
+ /* necessary for RXEMPTY to refresh its value */
+ litex_set_reg(membase + OFF_EV_PENDING, 1, EV_TX | EV_RX);
+
+ /* no overflow bits in status */
+ if (!(uart_handle_sysrq_char(port, ch)))
+ uart_insert_char(port, status, 0, ch, flg);
+
+ tty_flip_buffer_push(&port->state->port);
+ }
+
+ mod_timer(&uart->timer, jiffies + uart_poll_timeout(port));
+}
+
+static void liteuart_putchar(struct uart_port *port, int ch)
+{
+ while (litex_get_reg(port->membase + OFF_TXFULL, 1))
+ cpu_relax();
+
+ litex_set_reg(port->membase + OFF_RXTX, 1, ch);
+}
+
+static unsigned int liteuart_tx_empty(struct uart_port *port)
+{
+ /* not really tx empty, just checking if tx is not full */
+ if (!litex_get_reg(port->membase + OFF_TXFULL, 1))
+ return TIOCSER_TEMT;
+
+ return 0;
+}
+
+static void liteuart_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+ /* modem control register is not present in LiteUART */
+}
+
+static unsigned int liteuart_get_mctrl(struct uart_port *port)
+{
+ return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
+}
+
+static void liteuart_stop_tx(struct uart_port *port)
+{
+}
+
+static void liteuart_start_tx(struct uart_port *port)
+{
+ struct circ_buf *xmit = &port->state->xmit;
+ unsigned char ch;
+
+ if (unlikely(port->x_char)) {
+ litex_set_reg(port->membase + OFF_RXTX, 1, port->x_char);
+ port->icount.tx++;
+ port->x_char = 0;
+ } else if (!uart_circ_empty(xmit)) {
+ while (xmit->head != xmit->tail) {
+ ch = xmit->buf[xmit->tail];
+ xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+ port->icount.tx++;
+ liteuart_putchar(port, ch);
+ }
+ }
+
+ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+ uart_write_wakeup(port);
+}
+
+static void liteuart_stop_rx(struct uart_port *port)
+{
+ struct liteuart_port *uart = to_liteuart_port(port);
+
+ /* just delete timer */
+ del_timer(&uart->timer);
+}
+
+static void liteuart_break_ctl(struct uart_port *port, int break_state)
+{
+ /* LiteUART doesn't support sending break signal */
+}
+
+static int liteuart_startup(struct uart_port *port)
+{
+ struct liteuart_port *uart = to_liteuart_port(port);
+
+ /* disable events */
+ litex_set_reg(port->membase + OFF_EV_ENABLE, 1, 0);
+
+ /* prepare timer for polling */
+ timer_setup(&uart->timer, liteuart_timer, 0);
+ mod_timer(&uart->timer, jiffies + uart_poll_timeout(port));
+
+ return 0;
+}
+
+static void liteuart_shutdown(struct uart_port *port)
+{
+}
+
+static void liteuart_set_termios(struct uart_port *port, struct ktermios *new,
+ struct ktermios *old)
+{
+ unsigned int baud;
+ unsigned long flags;
+
+ spin_lock_irqsave(&port->lock, flags);
+
+ /* update baudrate */
+ baud = uart_get_baud_rate(port, new, old, 0, 460800);
+ uart_update_timeout(port, new->c_cflag, baud);
+
+ spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *liteuart_type(struct uart_port *port)
+{
+ return "liteuart";
+}
+
+static void liteuart_release_port(struct uart_port *port)
+{
+}
+
+static int liteuart_request_port(struct uart_port *port)
+{
+ return 0;
+}
+
+static void liteuart_config_port(struct uart_port *port, int flags)
+{
+ /*
+ * Driver core for serial ports forces a non-zero value for port type.
+ * Write an arbitrary value here to accommodate the serial core driver,
+ * as ID part of UAPI is redundant.
+ */
+ port->type = 1;
+}
+
+static int liteuart_verify_port(struct uart_port *port,
+ struct serial_struct *ser)
+{
+ if (port->type != PORT_UNKNOWN && ser->type != 1)
+ return -EINVAL;
+
+ return 0;
+}
+
+static const struct uart_ops liteuart_ops = {
+ .tx_empty = liteuart_tx_empty,
+ .set_mctrl = liteuart_set_mctrl,
+ .get_mctrl = liteuart_get_mctrl,
+ .stop_tx = liteuart_stop_tx,
+ .start_tx = liteuart_start_tx,
+ .stop_rx = liteuart_stop_rx,
+ .break_ctl = liteuart_break_ctl,
+ .startup = liteuart_startup,
+ .shutdown = liteuart_shutdown,
+ .set_termios = liteuart_set_termios,
+ .type = liteuart_type,
+ .release_port = liteuart_release_port,
+ .request_port = liteuart_request_port,
+ .config_port = liteuart_config_port,
+ .verify_port = liteuart_verify_port,
+};
+
+static int liteuart_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct liteuart_port *uart;
+ struct uart_port *port;
+ struct xa_limit limit;
+ int dev_id, ret;
+
+ /* no device tree */
+ if (!np)
+ return -ENODEV;
+
+ if (!litex_check_accessors())
+ return -EPROBE_DEFER;
+
+ /* look for aliases; auto-enumerate for free index if not found */
+ dev_id = of_alias_get_id(np, "serial");
+ if (dev_id < 0)
+ limit = XA_LIMIT(0, CONFIG_SERIAL_LITEUART_MAX_PORTS);
+ else
+ limit = XA_LIMIT(dev_id, dev_id);
+
+ uart = kzalloc(sizeof(struct liteuart_port), GFP_KERNEL);
+ if (!uart)
+ return -ENOMEM;
+
+ ret = xa_alloc(&liteuart_array, &dev_id, uart, limit, GFP_KERNEL);
+ if (ret)
+ return ret;
+
+ port = &uart->port;
+
+ /* get membase */
+ port->membase = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
+ if (!port->membase)
+ return -ENXIO;
+
+ /* values not from device tree */
+ port->dev = &pdev->dev;
+ port->iotype = UPIO_MEM;
+ port->flags = UPF_BOOT_AUTOCONF;
+ port->ops = &liteuart_ops;
+ port->regshift = 2;
+ port->fifosize = 16;
+ port->iobase = 1;
+ port->type = PORT_UNKNOWN;
+ port->line = dev_id;
+ spin_lock_init(&port->lock);
+
+ return uart_add_one_port(&liteuart_driver, &uart->port);
+}
+
+static int liteuart_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static const struct of_device_id liteuart_of_match[] = {
+ { .compatible = "litex,liteuart" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, liteuart_of_match);
+
+static struct platform_driver liteuart_platform_driver = {
+ .probe = liteuart_probe,
+ .remove = liteuart_remove,
+ .driver = {
+ .name = "liteuart",
+ .of_match_table = liteuart_of_match,
+ },
+};
+
+#ifdef CONFIG_SERIAL_LITEUART_CONSOLE
+
+static void liteuart_console_write(struct console *co, const char *s,
+ unsigned int count)
+{
+ struct liteuart_port *uart;
+ struct uart_port *port;
+ unsigned long flags;
+
+ uart = (struct liteuart_port *)xa_load(&liteuart_array, co->index);
+ port = &uart->port;
+
+ spin_lock_irqsave(&port->lock, flags);
+ uart_console_write(port, s, count, liteuart_putchar);
+ spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static int liteuart_console_setup(struct console *co, char *options)
+{
+ struct liteuart_port *uart;
+ struct uart_port *port;
+ int baud = 115200;
+ int bits = 8;
+ int parity = 'n';
+ int flow = 'n';
+
+ uart = (struct liteuart_port *)xa_load(&liteuart_array, co->index);
+ if (!uart)
+ return -ENODEV;
+
+ port = &uart->port;
+ if (!port->membase)
+ return -ENODEV;
+
+ if (options)
+ uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+ return uart_set_options(port, co, baud, parity, bits, flow);
+}
+
+static struct console liteuart_console = {
+ .name = "liteuart",
+ .write = liteuart_console_write,
+ .device = uart_console_device,
+ .setup = liteuart_console_setup,
+ .flags = CON_PRINTBUFFER,
+ .index = -1,
+ .data = &liteuart_driver,
+};
+
+static int __init liteuart_console_init(void)
+{
+ register_console(&liteuart_console);
+
+ return 0;
+}
+console_initcall(liteuart_console_init);
+#endif /* CONFIG_SERIAL_LITEUART_CONSOLE */
+
+static int __init liteuart_init(void)
+{
+ int res;
+
+ res = uart_register_driver(&liteuart_driver);
+ if (res)
+ return res;
+
+ res = platform_driver_register(&liteuart_platform_driver);
+ if (res) {
+ uart_unregister_driver(&liteuart_driver);
+ return res;
+ }
+
+ return 0;
+}
+
+static void __exit liteuart_exit(void)
+{
+ platform_driver_unregister(&liteuart_platform_driver);
+ uart_unregister_driver(&liteuart_driver);
+}
+
+module_init(liteuart_init);
+module_exit(liteuart_exit);
+
+MODULE_AUTHOR("Antmicro <www.antmicro.com>");
+MODULE_DESCRIPTION("LiteUART serial driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform: liteuart");
--
2.20.1
^ permalink raw reply related
* [v2] drm/bridge: ti-sn65dsi86: ensure bridge suspend happens during PM sleep
From: Harigovindan P @ 2020-06-04 10:34 UTC (permalink / raw)
To: dri-devel, linux-arm-msm, freedreno, devicetree
Cc: Harigovindan P, linux-kernel, robdclark, seanpaul, hoegsberg,
kalyan_t, nganji, sam
ti-sn65dsi86 bridge is enumerated as a runtime device.
Adding sleep ops to force runtime_suspend when PM suspend is
requested on the device.
Signed-off-by: Harigovindan P <harigovi@codeaurora.org>
---
Changes in v2:
- Include bridge name in the commit message and
remove dependent patchwork link from the commit
text as bridge is independent of OEM(Stephen Boyd)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 6ad688b320ae..2eef755b2917 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -159,6 +159,8 @@ static int __maybe_unused ti_sn_bridge_suspend(struct device *dev)
static const struct dev_pm_ops ti_sn_bridge_pm_ops = {
SET_RUNTIME_PM_OPS(ti_sn_bridge_suspend, ti_sn_bridge_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
static int status_show(struct seq_file *s, void *data)
--
2.27.0
^ permalink raw reply related
* Re: [PATCH 5/7] arm64: dts: qcom: pm8150x: add thermal alarms and thermal zones
From: Vinod Koul @ 2020-06-04 10:47 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
devicetree, patches, linaro-kernel
In-Reply-To: <20200604004331.669936-5-dmitry.baryshkov@linaro.org>
On 04-06-20, 03:43, Dmitry Baryshkov wrote:
> Add temperature alarm and thermal zone configuration to all three
> pm8150 instances. Configuration is largely based on the msm-4.19 tree.
> These alarms use main adc of the pmic. Separate temperature adc is not
> supported yet.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/pm8150.dtsi | 41 +++++++++++++++++++++++--
> arch/arm64/boot/dts/qcom/pm8150b.dtsi | 43 +++++++++++++++++++++++++--
> arch/arm64/boot/dts/qcom/pm8150l.dtsi | 43 +++++++++++++++++++++++++--
> 3 files changed, 119 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/pm8150.dtsi b/arch/arm64/boot/dts/qcom/pm8150.dtsi
> index c0b197458665..fee2db42f4cb 100644
> --- a/arch/arm64/boot/dts/qcom/pm8150.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pm8150.dtsi
> @@ -30,6 +30,15 @@ pwrkey {
> };
> };
>
> + pm8150_temp: temp-alarm@2400 {
> + compatible = "qcom,spmi-temp-alarm";
> + reg = <0x2400>;
> + interrupts = <0x0 0x24 0x0 IRQ_TYPE_EDGE_BOTH>;
> + io-channels = <&pm8150_adc ADC5_DIE_TEMP>;
> + io-channel-names = "thermal";
> + #thermal-sensor-cells = <0>;
> + };
> +
> pm8150_adc: adc@3100 {
> compatible = "qcom,spmi-adc5";
> reg = <0x3100>;
> @@ -38,8 +47,6 @@ pm8150_adc: adc@3100 {
> #io-channel-cells = <1>;
> interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
>
> - status = "disabled";
> -
This should not be removed, rather than this please add enabled in you
board dts file
> ref-gnd@0 {
> reg = <ADC5_REF_GND>;
> qcom,pre-scaling = <1 1>;
> @@ -85,3 +92,33 @@ pmic@1 {
> #size-cells = <0>;
> };
> };
> +
> +&thermal_zones {
> + pm8150_temp {
> + polling-delay-passive = <0>;
> + polling-delay = <0>;
> +
> + thermal-sensors = <&pm8150_temp>;
> +
> + trips {
> + trip0 {
> + temperature = <95000>;
> + hysteresis = <0>;
> + type = "passive";
> + };
> +
> + trip1 {
> + temperature = <115000>;
> + hysteresis = <0>;
> + type = "passive";
> + };
> +
> + trip2 {
> + temperature = <145000>;
> + hysteresis = <0>;
> + type = "passive";
> + };
> + };
> +
> + };
Not sure about this, Amit..? Should this also not be in board dts?
Similar comments on similar ones for rest of the patch as well..
--
~Vinod
^ permalink raw reply
* Re: [PATCH 6/7] arm64: dts: qcom: pm8150: enable rtc device
From: Vinod Koul @ 2020-06-04 10:51 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
devicetree, patches, linaro-kernel
In-Reply-To: <20200604004331.669936-6-dmitry.baryshkov@linaro.org>
On 04-06-20, 03:43, Dmitry Baryshkov wrote:
> Enable rtc device provided by the pmic.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/pm8150.dtsi | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/pm8150.dtsi b/arch/arm64/boot/dts/qcom/pm8150.dtsi
> index fee2db42f4cb..762fb902db81 100644
> --- a/arch/arm64/boot/dts/qcom/pm8150.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pm8150.dtsi
> @@ -71,8 +71,6 @@ rtc@6000 {
> reg = <0x6000>;
> reg-names = "rtc", "alarm";
> interrupts = <0x0 0x61 0x1 IRQ_TYPE_NONE>;
> -
> - status = "disabled";
Again, pls enable in your board dts...
Thanks
--
~Vinod
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: sm8250: add watchdog device
From: Vinod Koul @ 2020-06-04 10:52 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
devicetree, patches, linaro-kernel
In-Reply-To: <20200604004331.669936-7-dmitry.baryshkov@linaro.org>
On 04-06-20, 03:43, Dmitry Baryshkov wrote:
> Add on-SoC watchdog device node.
Reviewed-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: sm8250: add watchdog device
From: Sai Prakash Ranjan @ 2020-06-04 11:07 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
devicetree, patches, linaro-kernel, devicetree-owner
In-Reply-To: <20200604004331.669936-7-dmitry.baryshkov@linaro.org>
On 2020-06-04 06:13, Dmitry Baryshkov wrote:
> Add on-SoC watchdog device node.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> index 972d8e04c8a2..f1641c6fe203 100644
> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> @@ -1662,6 +1662,12 @@ config {
> };
> };
>
> + watchdog@17c10000 {
> + compatible = "qcom,apss-wdt-sm8250", "qcom,kpss-wdt";
Need to add this compatible to bindings.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [RFC 1/4] regulator: lp87565: enable voltage regardless of ENx pin
From: Mark Brown @ 2020-06-04 11:07 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Liam Girdwood, devicetree, linux-kernel, Lee Jones, Rob Herring,
Keerthy, Axel Lin
In-Reply-To: <20200603200319.16184-2-luca@lucaceresoli.net>
[-- Attachment #1: Type: text/plain, Size: 866 bytes --]
On Wed, Jun 03, 2020 at 10:03:16PM +0200, Luca Ceresoli wrote:
> I suspect the only solution that allows to configure the EN_PIN_CTRLn bits
> correctly in all the possible hardware setups would be to tell in device
> tree / board info whether each enable pin is connected or not (which is a
> hardware _fact_) and which ENx pin should control which regulator output
> (which is a policy). But it would make this simple driver considerably more
> complex.
> Any suggestion about the correct way to handle this situation would be
> greatly appreciated.
We can tell if we've got a software controlled GPIO connected, if we
have then we should ensure that it continues to take effect. That
should just be a single register write at startup from the sounds of it.
Otherwise yeah, just ignoring that there's a possibility of a GPIO we
don't know about seems sensible.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: bcm2711: Update SPI nodes compatible strings
From: Mark Brown @ 2020-06-04 11:13 UTC (permalink / raw)
To: Lukas Wunner
Cc: Florian Fainelli, linux-kernel, Rob Herring,
Nicolas Saenz Julienne, Ray Jui, Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
open list:SPI SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Martin Sperl
In-Reply-To: <20200604042038.jzolu6k7q3d6bsvq@wunner.de>
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]
On Thu, Jun 04, 2020 at 06:20:38AM +0200, Lukas Wunner wrote:
> On Wed, Jun 03, 2020 at 08:46:54PM -0700, Florian Fainelli wrote:
> > The BCM2711 SoC features 5 SPI controllers which all share the same
> > interrupt line, the SPI driver needs to support interrupt sharing,
> > therefore use the chip specific compatible string to help with that.
> You're saying above that the 5 controllers all share the interrupt
> but below you're only changing the compatible string of 4 controllers.
> So I assume spi0 still has its own interrupt and only the additional
> 4 controllers present on the BCM2711/BCM7211 share their interrupt?
Regardless of what's going on with the interrupts the compatible string
should reflect the IP version so unless for some reason someone taped
out two different versions of the IP it seems odd that the compatible
strings would vary within a given SoC.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH V1 1/2] mmc: sdhci-msm: Add interconnect bandwidth scaling support
From: ppvk @ 2020-06-04 11:13 UTC (permalink / raw)
To: Sibi Sankar
Cc: bjorn.andersson, adrian.hunter, robh+dt, ulf.hansson, vbadigan,
sboyd, georgi.djakov, mka, linux-mmc, linux-kernel, linux-arm-msm,
devicetree, linux-mmc-owner, rnayak, matthias,
linux-arm-msm-owner
In-Reply-To: <29826613b412e4f4db4289e292a1fe57@codeaurora.org>
Hi Sibi,
Thanks for the review!!
On 2020-06-03 17:22, Sibi Sankar wrote:
> Hey Pradeep,
> Thanks for the patch.
>
> On 2020-06-03 14:39, Pradeep P V K wrote:
>> Interconnect bandwidth scaling support is now added as a
>> part of OPP [1]. So, make sure interconnect driver is ready
>> before handling interconnect scaling.
>>
>> This change is based on
>> [1] [Patch v8] Introduce OPP bandwidth bindings
>> (https://lkml.org/lkml/2020/5/12/493)
>>
>> [2] [Patch v3] mmc: sdhci-msm: Fix error handling
>> for dev_pm_opp_of_add_table()
>> (https://lkml.org/lkml/2020/5/5/491)
>>
>> Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
>> ---
>> drivers/mmc/host/sdhci-msm.c | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci-msm.c
>> b/drivers/mmc/host/sdhci-msm.c
>> index b277dd7..bf95484 100644
>> --- a/drivers/mmc/host/sdhci-msm.c
>> +++ b/drivers/mmc/host/sdhci-msm.c
>> @@ -14,6 +14,7 @@
>> #include <linux/slab.h>
>> #include <linux/iopoll.h>
>> #include <linux/regulator/consumer.h>
>> +#include <linux/interconnect.h>
>>
>> #include "sdhci-pltfm.h"
>> #include "cqhci.h"
>> @@ -1999,6 +2000,7 @@ static int sdhci_msm_probe(struct
>> platform_device *pdev)
>> struct sdhci_pltfm_host *pltfm_host;
>> struct sdhci_msm_host *msm_host;
>> struct clk *clk;
>> + struct icc_path *sdhc_path;
>> int ret;
>> u16 host_version, core_minor;
>> u32 core_version, config;
>> @@ -2070,6 +2072,20 @@ static int sdhci_msm_probe(struct
>> platform_device *pdev)
>> }
>> msm_host->bulk_clks[0].clk = clk;
>>
>> + /* Make sure that ICC driver is ready for interconnect bandwdith
>> + * scaling before registering the device for OPP.
>> + */
>> + sdhc_path = of_icc_get(&pdev->dev, NULL);
>> + ret = PTR_ERR_OR_ZERO(sdhc_path);
>> + if (ret) {
>> + if (ret == -EPROBE_DEFER)
>> + dev_info(&pdev->dev, "defer icc path: %d\n", ret);
>> + else
>> + dev_err(&pdev->dev, "failed to get icc path:%d\n", ret);
>> + goto bus_clk_disable;
>> + }
>> + icc_put(sdhc_path);
>
> ret = dev_pm_opp_of_find_icc_paths(&pdev->dev, NULL);
>
> since there are multiple paths
> described in the bindings you
> should use ^^ instead and you
> can drop temporary path as well.
>
Ok. of_icc_get() used above is only to test if ICC driver is ready or
not. I'm not
really using the multiple paths here. Anyhow i will use
dev_pm_opp_of_find_icc_paths()
to get rid of some extra lines of code.
>> +
>> msm_host->opp_table = dev_pm_opp_set_clkname(&pdev->dev, "core");
>> if (IS_ERR(msm_host->opp_table)) {
>> ret = PTR_ERR(msm_host->opp_table);
^ permalink raw reply
* [PATCH net-next v6 1/4] dt-bindings: net: Add tx and rx internal delays
From: Dan Murphy @ 2020-06-04 11:14 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200604111410.17918-1-dmurphy@ti.com>
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../devicetree/bindings/net/ethernet-phy.yaml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
index 9b1f1147ca36..edd0245d132b 100644
--- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
@@ -162,6 +162,19 @@ properties:
description:
Specifies a reference to a node representing a SFP cage.
+
+ rx-internal-delay-ps:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ RGMII Receive PHY Clock Delay defined in pico seconds. This is used for
+ PHY's that have configurable RX internal delays.
+
+ tx-internal-delay-ps:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ RGMII Transmit PHY Clock Delay defined in pico seconds. This is used for
+ PHY's that have configurable TX internal delays.
+
required:
- reg
--
2.26.2
^ permalink raw reply related
* [PATCH net-next v6 2/4] net: phy: Add a helper to return the index for of the internal delay
From: Dan Murphy @ 2020-06-04 11:14 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200604111410.17918-1-dmurphy@ti.com>
Add a helper function that will return the index in the array for the
passed in internal delay value. The helper requires the array, size and
delay value.
The helper will then return the index for the exact match or return the
index for the index to the closest smaller value.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/net/phy/phy_device.c | 68 ++++++++++++++++++++++++++++++++++++
include/linux/phy.h | 4 +++
2 files changed, 72 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 04946de74fa0..611d4e68e3c6 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -31,6 +31,7 @@
#include <linux/mdio.h>
#include <linux/io.h>
#include <linux/uaccess.h>
+#include <linux/property.h>
MODULE_DESCRIPTION("PHY library");
MODULE_AUTHOR("Andy Fleming");
@@ -2657,6 +2658,73 @@ void phy_get_pause(struct phy_device *phydev, bool *tx_pause, bool *rx_pause)
}
EXPORT_SYMBOL(phy_get_pause);
+/**
+ * phy_get_delay_index - returns the index of the internal delay
+ * @phydev: phy_device struct
+ * @dev: pointer to the devices device struct
+ * @delay_values: array of delays the PHY supports
+ * @size: the size of the delay array
+ * @is_rx: boolean to indicate to get the rx internal delay
+ *
+ * Returns the index within the array of internal delay passed in.
+ * Or if size == 0 then the delay read from the firmware is returned.
+ * The array must be in ascending order.
+ * Return errno if the delay is invalid or cannot be found.
+ */
+s32 phy_get_internal_delay(struct phy_device *phydev, struct device *dev,
+ const int *delay_values, int size, bool is_rx)
+{
+ int ret;
+ int i;
+ s32 delay;
+
+ if (is_rx)
+ ret = device_property_read_u32(dev, "rx-internal-delay-ps",
+ &delay);
+ else
+ ret = device_property_read_u32(dev, "tx-internal-delay-ps",
+ &delay);
+ if (ret) {
+ phydev_err(phydev, "internal delay not defined\n");
+ return -EINVAL;
+ }
+
+ if (delay < 0)
+ return -EINVAL;
+
+ if (size <= 0)
+ return delay;
+
+ if (delay < delay_values[0] || delay > delay_values[size - 1]) {
+ phydev_err(phydev, "Delay %d is out of range\n", delay);
+ return -EINVAL;
+ }
+
+ if (delay == delay_values[0])
+ return 0;
+
+ for (i = 1; i < size; i++) {
+ if (delay == delay_values[i])
+ return i;
+
+ /* Find an approximate index by looking up the table */
+ if (delay > delay_values[i - 1] &&
+ delay < delay_values[i]) {
+ if (delay - delay_values[i - 1] <
+ delay_values[i] - delay)
+ return i - 1;
+ else
+ return i;
+ }
+ }
+
+ phydev_err(phydev, "error finding internal delay index for %d\n",
+ delay);
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL(phy_get_internal_delay);
+
static bool phy_drv_supports_irq(struct phy_driver *phydrv)
{
return phydrv->config_intr && phydrv->ack_interrupt;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 8c05d0fb5c00..917bfd422e06 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1430,6 +1430,10 @@ void phy_set_asym_pause(struct phy_device *phydev, bool rx, bool tx);
bool phy_validate_pause(struct phy_device *phydev,
struct ethtool_pauseparam *pp);
void phy_get_pause(struct phy_device *phydev, bool *tx_pause, bool *rx_pause);
+
+s32 phy_get_internal_delay(struct phy_device *phydev, struct device *dev,
+ const int *delay_values, int size, bool is_rx);
+
void phy_resolve_pause(unsigned long *local_adv, unsigned long *partner_adv,
bool *tx_pause, bool *rx_pause);
--
2.26.2
^ permalink raw reply related
* [PATCH net-next v6 4/4] net: dp83869: Add RGMII internal delay configuration
From: Dan Murphy @ 2020-06-04 11:14 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200604111410.17918-1-dmurphy@ti.com>
Add RGMII internal delay configuration for Rx and Tx.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/net/phy/dp83869.c | 53 ++++++++++++++++++++++++++++++++++++---
1 file changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/dp83869.c
index cfb22a21a2e6..801341edbe31 100644
--- a/drivers/net/phy/dp83869.c
+++ b/drivers/net/phy/dp83869.c
@@ -64,6 +64,10 @@
#define DP83869_RGMII_TX_CLK_DELAY_EN BIT(1)
#define DP83869_RGMII_RX_CLK_DELAY_EN BIT(0)
+/* RGMIIDCTL */
+#define DP83869_RGMII_CLK_DELAY_SHIFT 4
+#define DP83869_CLK_DELAY_DEF 7
+
/* STRAP_STS1 bits */
#define DP83869_STRAP_OP_MODE_MASK GENMASK(2, 0)
#define DP83869_STRAP_STS1_RESERVED BIT(11)
@@ -78,9 +82,6 @@
#define DP83869_PHYCR_FIFO_DEPTH_MASK GENMASK(15, 12)
#define DP83869_PHYCR_RESERVED_MASK BIT(11)
-/* RGMIIDCTL bits */
-#define DP83869_RGMII_TX_CLK_DELAY_SHIFT 4
-
/* IO_MUX_CFG bits */
#define DP83869_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
@@ -99,6 +100,10 @@
#define DP83869_OP_MODE_MII BIT(5)
#define DP83869_SGMII_RGMII_BRIDGE BIT(6)
+static const int dp83869_internal_delay[] = {250, 500, 750, 1000, 1250, 1500,
+ 1750, 2000, 2250, 2500, 2750, 3000,
+ 3250, 3500, 3750, 4000};
+
enum {
DP83869_PORT_MIRRORING_KEEP,
DP83869_PORT_MIRRORING_EN,
@@ -108,6 +113,8 @@ enum {
struct dp83869_private {
int tx_fifo_depth;
int rx_fifo_depth;
+ s32 rx_id_delay;
+ s32 tx_id_delay;
int io_impedance;
int port_mirroring;
bool rxctrl_strap_quirk;
@@ -182,6 +189,7 @@ static int dp83869_of_init(struct phy_device *phydev)
struct dp83869_private *dp83869 = phydev->priv;
struct device *dev = &phydev->mdio.dev;
struct device_node *of_node = dev->of_node;
+ int delay_size = ARRAY_SIZE(dp83869_internal_delay);
int ret;
if (!of_node)
@@ -232,6 +240,20 @@ static int dp83869_of_init(struct phy_device *phydev)
&dp83869->tx_fifo_depth))
dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
+ dp83869->rx_id_delay = phy_get_internal_delay(phydev, dev,
+ &dp83869_internal_delay[0],
+ delay_size, true);
+ if (dp83869->rx_id_delay < 0)
+ dp83869->rx_id_delay =
+ dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
+
+ dp83869->tx_id_delay = phy_get_internal_delay(phydev, dev,
+ &dp83869_internal_delay[0],
+ delay_size, false);
+ if (dp83869->tx_id_delay < 0)
+ dp83869->tx_id_delay =
+ dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
+
return ret;
}
#else
@@ -394,6 +416,31 @@ static int dp83869_config_init(struct phy_device *phydev)
dp83869->clk_output_sel <<
DP83869_IO_MUX_CFG_CLK_O_SEL_SHIFT);
+ if (phy_interface_is_rgmii(phydev)) {
+ ret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIIDCTL,
+ dp83869->rx_id_delay |
+ dp83869->tx_id_delay << DP83869_RGMII_CLK_DELAY_SHIFT);
+ if (ret)
+ return ret;
+
+ val = phy_read_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIICTL);
+ val &= ~(DP83869_RGMII_TX_CLK_DELAY_EN |
+ DP83869_RGMII_RX_CLK_DELAY_EN);
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
+ val |= (DP83869_RGMII_TX_CLK_DELAY_EN |
+ DP83869_RGMII_RX_CLK_DELAY_EN);
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
+ val |= DP83869_RGMII_TX_CLK_DELAY_EN;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
+ val |= DP83869_RGMII_RX_CLK_DELAY_EN;
+
+ ret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIICTL,
+ val);
+ }
+
return ret;
}
--
2.26.2
^ permalink raw reply related
* [PATCH net-next v6 0/4] RGMII Internal delay common property
From: Dan Murphy @ 2020-06-04 11:14 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
Hello
The RGMII internal delay is a common setting found in most RGMII capable PHY
devices. It was found that many vendor specific device tree properties exist
to do the same function. This creates a common property to be used for PHY's
that have tunable internal delays for the Rx and Tx paths.
Dan Murphy (4):
dt-bindings: net: Add tx and rx internal delays
net: phy: Add a helper to return the index for of the internal delay
dt-bindings: net: Add RGMII internal delay for DP83869
net: dp83869: Add RGMII internal delay configuration
.../devicetree/bindings/net/ethernet-phy.yaml | 13 ++++
.../devicetree/bindings/net/ti,dp83869.yaml | 16 ++++-
drivers/net/phy/dp83869.c | 53 ++++++++++++++-
drivers/net/phy/phy_device.c | 68 +++++++++++++++++++
include/linux/phy.h | 4 ++
5 files changed, 150 insertions(+), 4 deletions(-)
--
2.26.2
^ permalink raw reply
* [PATCH net-next v6 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Dan Murphy @ 2020-06-04 11:14 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200604111410.17918-1-dmurphy@ti.com>
Add the internal delay values into the header and update the binding
with the internal delay properties.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../devicetree/bindings/net/ti,dp83869.yaml | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
index 5b69ef03bbf7..71e90a3e4652 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml
+++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
@@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: TI DP83869 ethernet PHY
allOf:
- - $ref: "ethernet-controller.yaml#"
+ - $ref: "ethernet-phy.yaml#"
maintainers:
- Dan Murphy <dmurphy@ti.com>
@@ -64,6 +64,18 @@ properties:
Operational mode for the PHY. If this is not set then the operational
mode is set by the straps. see dt-bindings/net/ti-dp83869.h for values
+ rx-internal-delay-ps:
+ description: Delay is in pico seconds
+ enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000,
+ 3250, 3500, 3750, 4000 ]
+ default: 2000
+
+ tx-internal-delay-ps:
+ description: Delay is in pico seconds
+ enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000,
+ 3250, 3500, 3750, 4000 ]
+ default: 2000
+
required:
- reg
@@ -80,5 +92,7 @@ examples:
ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
ti,max-output-impedance = "true";
ti,clk-output-sel = <DP83869_CLK_O_SEL_CHN_A_RCLK>;
+ rx-internal-delay-ps = <2000>;
+ tx-internal-delay-ps = <2000>;
};
};
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v7 2/4] usb: dwc3: qcom: Add interconnect support in dwc3 driver
From: Stephen Boyd @ 2020-06-04 11:16 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Doug Anderson, Felipe Balbi,
Greg Kroah-Hartman, Mark Rutland, Matthias Kaehlcke, Rob Herring,
Sandeep Maheswaram
Cc: linux-arm-msm, linux-usb, devicetree, linux-kernel, Manu Gautam,
Chandana Kishori Chiluveru
In-Reply-To: <d9ccf188-4f00-d3ac-ba0f-73f06c087553@codeaurora.org>
Quoting Sandeep Maheswaram (Temp) (2020-06-04 02:43:09)
>
> On 6/3/2020 11:06 PM, Stephen Boyd wrote:
> > Quoting Sandeep Maheswaram (2020-03-31 22:15:43)
> >> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> >> index 1dfd024..d33ae86 100644
> >> --- a/drivers/usb/dwc3/dwc3-qcom.c
> >> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> >> @@ -285,6 +307,101 @@ static int dwc3_qcom_resume(struct dwc3_qcom *qcom)
> >> return 0;
> >> }
> >>
> >> +
> >> +/**
> >> + * dwc3_qcom_interconnect_init() - Get interconnect path handles
> >> + * @qcom: Pointer to the concerned usb core.
> >> + *
> >> + */
> >> +static int dwc3_qcom_interconnect_init(struct dwc3_qcom *qcom)
> >> +{
> >> + struct device *dev = qcom->dev;
> >> + int ret;
> >> +
> >> + if (!device_is_bound(&qcom->dwc3->dev))
> >> + return -EPROBE_DEFER;
> > How is this supposed to work? I see that this was added in an earlier
> > revision of this patch series but there isn't any mention of why
> > device_is_bound() is used here. It would be great if there was a comment
> > detailing why this is necessary. It sounds like maximum_speed is
> > important?
> >
> > Furthermore, dwc3_qcom_interconnect_init() is called by
> > dwc3_qcom_probe() which is the function that registers the device for
> > qcom->dwc3->dev. If that device doesn't probe between the time it is
> > registered by dwc3_qcom_probe() and this function is called then we'll
> > fail dwc3_qcom_probe() with -EPROBE_DEFER. And that will remove the
> > qcom->dwc3->dev device from the platform bus because we call
> > of_platform_depopulate() on the error path of dwc3_qcom_probe().
> >
> > So isn't this whole thing racy and can potentially lead us to a driver
> > probe loop where the wrapper (dwc3_qcom) and the core (dwc3) are probing
> > and we're trying to time it just right so that driver for dwc3 binds
> > before we setup interconnects? I don't know if dwc3 can communicate to
> > the wrapper but that would be more of a direct way to do this. Or maybe
> > the wrapper should try to read the DT property for maximum speed and
> > fallback to a worst case high bandwidth value if it can't figure it out
> > itself without help from dwc3 core.
> >
> This was added in V4 to address comments from Matthias in V3
>
> https://patchwork.kernel.org/patch/11148587/
>
Yes, that why I said:
"I see that this was added in an earlier
revision of this patch series but there isn't any mention of why
device_is_bound() is used here. It would be great if there was a comment
detailing why this is necessary. It sounds like maximum_speed is
important?"
Can you please respond to the rest of my email?
^ permalink raw reply
* [PATCH V2 2/2] dt-bindings: mmc: sdhci-msm: Add interconnect BW scaling strings
From: Pradeep P V K @ 2020-06-04 11:14 UTC (permalink / raw)
To: bjorn.andersson, adrian.hunter, robh+dt, ulf.hansson, vbadigan,
sboyd, georgi.djakov, mka
Cc: linux-mmc, linux-kernel, linux-arm-msm, devicetree,
linux-mmc-owner, rnayak, sibis, matthias, Pradeep P V K
In-Reply-To: <1591269283-24084-1-git-send-email-ppvk@codeaurora.org>
Add interconnect bandwidth scaling supported strings for qcom-sdhci
controller.
Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
index b8e1d2b..3b602fd 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -54,6 +54,21 @@ Required properties:
- qcom,dll-config: Chipset and Platform specific value. Use this field to
specify the DLL_CONFIG register value as per Hardware Programming Guide.
+Optional Properties:
+* Following bus parameters are required for interconnect bandwidth scaling:
+- interconnects: Pairs of phandles and interconnect provider specifier
+ to denote the edge source and destination ports of
+ the interconnect path.
+
+- interconnect-names: For sdhc, we have two main paths.
+ 1. Data path : sdhc to ddr
+ 2. Config path : cpu to sdhc
+ For Data interconnect path the name supposed to be
+ is "sdhc-ddr" and for config interconnect path it is
+ "cpu-sdhc".
+ Please refer to Documentation/devicetree/bindings/
+ interconnect/ for more details.
+
Example:
sdhc_1: sdhci@f9824900 {
@@ -71,6 +86,9 @@ Example:
clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>;
clock-names = "core", "iface";
+ interconnects = <&qnoc MASTER_SDCC_ID &qnoc SLAVE_DDR_ID>,
+ <&qnoc MASTER_CPU_ID &qnoc SLAVE_SDCC_ID>;
+ interconnect-names = "sdhc-ddr","cpu-sdhc";
qcom,dll-config = <0x000f642c>;
qcom,ddr-config = <0x80040868>;
--
1.9.1
^ permalink raw reply related
* [PATCH V2 1/2] mmc: sdhci-msm: Add interconnect bandwidth scaling support
From: Pradeep P V K @ 2020-06-04 11:14 UTC (permalink / raw)
To: bjorn.andersson, adrian.hunter, robh+dt, ulf.hansson, vbadigan,
sboyd, georgi.djakov, mka
Cc: linux-mmc, linux-kernel, linux-arm-msm, devicetree,
linux-mmc-owner, rnayak, sibis, matthias, Pradeep P V K
In-Reply-To: <1591269283-24084-1-git-send-email-ppvk@codeaurora.org>
Interconnect bandwidth scaling support is now added as a
part of OPP [1]. So, make sure interconnect driver is ready
before handling interconnect scaling.
This change is based on
[1] [Patch v8] Introduce OPP bandwidth bindings
(https://lkml.org/lkml/2020/5/12/493)
[2] [Patch v3] mmc: sdhci-msm: Fix error handling
for dev_pm_opp_of_add_table()
(https://lkml.org/lkml/2020/5/5/491)
Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
---
drivers/mmc/host/sdhci-msm.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index b277dd7..a13ff1b 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -14,6 +14,7 @@
#include <linux/slab.h>
#include <linux/iopoll.h>
#include <linux/regulator/consumer.h>
+#include <linux/interconnect.h>
#include "sdhci-pltfm.h"
#include "cqhci.h"
@@ -2070,6 +2071,18 @@ static int sdhci_msm_probe(struct platform_device *pdev)
}
msm_host->bulk_clks[0].clk = clk;
+ /* Make sure that ICC driver is ready for interconnect bandwdith
+ * scaling before registering the device for OPP.
+ */
+ ret = dev_pm_opp_of_find_icc_paths(&pdev->dev, NULL);
+ if (ret) {
+ if (ret == -EPROBE_DEFER)
+ dev_info(&pdev->dev, "defer icc path: %d\n", ret);
+ else
+ dev_err(&pdev->dev, "failed to get icc path:%d\n", ret);
+ goto bus_clk_disable;
+ }
+
msm_host->opp_table = dev_pm_opp_set_clkname(&pdev->dev, "core");
if (IS_ERR(msm_host->opp_table)) {
ret = PTR_ERR(msm_host->opp_table);
--
1.9.1
^ permalink raw reply related
* [PATCH V2 0/2] Add SDHC interconnect bandwidth scaling
From: Pradeep P V K @ 2020-06-04 11:14 UTC (permalink / raw)
To: bjorn.andersson, adrian.hunter, robh+dt, ulf.hansson, vbadigan,
sboyd, georgi.djakov, mka
Cc: linux-mmc, linux-kernel, linux-arm-msm, devicetree,
linux-mmc-owner, rnayak, sibis, matthias, Pradeep P V K
Add interconnect bandwidths for SDHC driver using OPP framework that
is required by SDHC driver based on the clock frequency and bus width
of the card. Otherwise, the system clocks may run at minimum clock
speed and thus affecting the performance.
This change is based on
[1] [Patch v8] Introduce OPP bandwidth bindings
(https://lkml.org/lkml/2020/5/12/493)
[2] [Patch v3 09/17] mmc: sdhci-msm: Fix error handling
for dev_pm_opp_of_add_table()
(https://lkml.org/lkml/2020/5/5/491)
[3] [RFC v6 2/2] dt-bindings: mmc: sdhci-msm: Add interconnect BW
scaling strings
(https://lkml.org/lkml/2020/3/23/409)
as there were no extra changes made on [3], retaining the Acked-by and
Reviewed-by sign-off from [3].
Pradeep P V K (2):
mmc: sdhci-msm: Add interconnect bandwidth scaling support
dt-bindings: mmc: sdhci-msm: Add interconnect BW scaling strings
Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 18 ++++++++++++++++++
drivers/mmc/host/sdhci-msm.c | 13 +++++++++++++
2 files changed, 31 insertions(+)
--
changes since V1:
- Added dev_pm_opp_find_icc_paths() to check for icc paths.
^ permalink raw reply
* Re: [Freedreno] [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep
From: kalyan_t @ 2020-06-04 11:19 UTC (permalink / raw)
To: Doug Anderson
Cc: Sean Paul,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
mkrishn, travitej, linux-arm-msm, LKML, dri-devel, Rob Clark,
nganji, Kristian H. Kristensen, freedreno, Jeykumar Sankaran
In-Reply-To: <CAD=FV=XphGpmBwZdL0jZ5HEFdxY3L7nH+s9_A0Kjamtg7j3R9w@mail.gmail.com>
On 2020-05-28 03:41, Doug Anderson wrote:
> Hi,
>
> On Fri, May 15, 2020 at 9:37 AM Doug Anderson <dianders@chromium.org>
> wrote:
>>
>> Hi,
>>
>> On Fri, May 15, 2020 at 5:06 AM <kalyan_t@codeaurora.org> wrote:
>> >
>> > On 2020-05-14 21:47, Doug Anderson wrote:
>> > > Hi,
>> > >
>> > > On Fri, May 1, 2020 at 6:31 AM Kalyan Thota <kalyan_t@codeaurora.org>
>> > > wrote:
>> > >>
>> > >> "The PM core always increments the runtime usage counter
>> > >> before calling the ->suspend() callback and decrements it
>> > >> after calling the ->resume() callback"
>> > >>
>> > >> DPU and DSI are managed as runtime devices. When
>> > >> suspend is triggered, PM core adds a refcount on all the
>> > >> devices and calls device suspend, since usage count is
>> > >> already incremented, runtime suspend was not getting called
>> > >> and it kept the clocks on which resulted in target not
>> > >> entering into XO shutdown.
>> > >>
>> > >> Add changes to force suspend on runtime devices during pm sleep.
>> > >>
>> > >> Changes in v1:
>> > >> - Remove unnecessary checks in the function
>> > >> _dpu_kms_disable_dpu (Rob Clark).
>> > >>
>> > >> Changes in v2:
>> > >> - Avoid using suspend_late to reset the usagecount
>> > >> as suspend_late might not be called during suspend
>> > >> call failures (Doug).
>> > >>
>> > >> Changes in v3:
>> > >> - Use force suspend instead of managing device usage_count
>> > >> via runtime put and get API's to trigger callbacks (Doug).
>> > >>
>> > >> Changes in v4:
>> > >> - Check the return values of pm_runtime_force_suspend and
>> > >> pm_runtime_force_resume API's and pass appropriately (Doug).
>> > >>
>> > >> Changes in v5:
>> > >
>> > > Can you please put the version number properly in your subject? It's
>> > > really hard to tell one version of your patch from another.
>> > >
>> > >
>> > >> - With v4 patch, test cycle has uncovered issues in device resume.
>> > >>
>> > >> On bubs: cmd tx failures were seen as SW is sending panel off
>> > >> commands when the dsi resources are turned off.
>> > >>
>> > >> Upon suspend, DRM driver will issue a NULL composition to the
>> > >> dpu, followed by turning off all the HW blocks.
>> > >>
>> > >> v5 changes will serialize the NULL commit and resource unwinding
>> > >> by handling them under PM prepare and PM complete phases there by
>> > >> ensuring that clks are on when panel off commands are being
>> > >> processed.
>> > >
>> > > I'm still most definitely not an expert in how all the DRM pieces all
>> > > hook up together, but the solution you have in this patch seems wrong
>> > > to me. As far as I can tell the "prepare" state isn't supposed to be
>> > > actually doing the suspend work and here that's exactly what you're
>> > > doing. I think you should find a different solution to ensure
>> > > ordering is correct.
>> > >
>> > > -Doug
>> > >
>> >
>> > Hi,
>>
>> Quite honestly I'm probably not the right person to be reviewing this
>> code. I mostly just noticed one of your early patches and it looked
>> strange to me. Hopefully someone with actual experience in how all
>> the DRM components work together can actually review and see if this
>> makes sense. Maybe Sean would know better?
>>
>> That being said, let me at least look at what you're saying...
>>
>>
>> > Prepare and Complete are callbacks defined as part of Sleep and Resume
>> > sequence
>> >
>> > Entering PM SUSPEND the phases are : prepare --> suspend -->
>> > suspend_late --> suspend_noirq.
>> > While leaving PM SUSPEND the phases are: resume_noirq --> resume_early
>> > --> resume --> complete.
>>
>> Sure, it's part of the sequence. It's also documented in pm.h as:
>>
>> * The principal role of this callback is to prevent new children of
>> * the device from being registered after it has returned (the
>> driver's
>> * subsystem and generally the rest of the kernel is supposed to
>> prevent
>> * new calls to the probe method from being made too once @prepare()
>> has
>> * succeeded).
>>
>> It does not feel like that matches your usage of this call.
>>
>>
>> > The reason to push drm suspend handling to PM prepare phase is that
>> > parent here will trigger a modeset to turn off the timing and
>> > subsequently the panel.
>> > the child devices should not turn of their clocks before parent unwinds
>> > the composition. Hence they are serialized as per the sequence mentioned
>> > above.
>>
>> So the general model in Linux is that children suspend before their
>> parents, right? So you're saying that, in this case, the parent needs
>> to act on the child before the child suspends. Is that correct?
>>
>> Rather than hijacking the prepare/complete, I'd be at least slightly
>> inclined to move the other driver to turn off its clocks in
>> suspend_late and to turn them back on in resume_early? That seems to
>> be what was done in "analogix_dp-rockchip.c" to solve a similar
>> problem.
>>
>>
>> > A similar approach is taken by other driver that use drm framework. In
>> > this driver, the device registers for prepare and complete callbacks to
>> > handle drm_suspend and drm_resume.
>> > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/exynos/exynos_drm_drv.c#L163
>>
>> OK, if there is another driver in DRM then I guess I won't object too
>> strongly. Note that when searching for other drivers I noticed this
>> bit in todo.rst:
>>
>> * Most drivers (except i915 and nouveau) that use
>> * drm_atomic_helper_suspend/resume() can probably be converted to use
>> * drm_mode_config_helper_suspend/resume(). Also there's still
>> open-coded version
>> * of the atomic suspend/resume code in older atomic modeset drivers.
>>
>> Does anything get fixed if you do that? It seems like it'd cleanup
>> your code a bit so maybe worth doing anyway...
>>
>> ---
>>
>> I guess the last question I'd want resolved is why you have this
>> asymmetry:
>>
>> SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, msm_pm_resume)
>>
>> Why couldn't you use pm_runtime_force_resume()?
>
> I'm curious if you had answers to any of the questions I posed in my
> review.
>
> -Doug
1) i'll update the patch to use "drm_mode_config_helper_suspend/resume".
This will help in additional cleanup such as enabling FBDEV emulation in
the build.
2) For the asymmetry part,
pm_runtime_force_resume() was not waking up the device forcefully if
the usage count is 1. PM core thinks that if usage count is 1 then
device can be runtime resumed after suspend/resume sequence is complete.
This is true for all the child nodes and the parent node. Hence to
overcome that i used pm_runtime_resume on parent.
I have explored a bit on how to handle this cleanly, found an old thread
discussing on the similar problem
(https://lists.gt.net/linux/kernel/1556562 post no#4 Alan Stern ) the
suggestion was to use runtime API's directly in PM Suspend/Resume.
I have found few example implementations on similar lines.
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/media/platform/mtk-mdp/mtk_mdp_core.c#L279
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/media/i2c/ak7375.c#L273
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gnss/sirf.c#L377
I have changed the implementation on those lines in v6.
Summary of the flow now:
PM Sleep --> pm_prepare for parent ( Disable all the DRM CRTCs) -->
Suspend for child1, child2 ( turn off child clocks )--> Suspend for
parent (turn off parent clocks )
PM Wakeup --> Resume for child1, child2 ( force resume is inactive due
to usage count 1, but the call is needed to undo the force suspend
things ) --> Resume for Parent (turn on parent clocks ) --> PM_complete
for Parent.( By the time we reach here, PM core will remove the usage
count for all the children and they are ready for runtime resume. Parent
enables CRTCs which will runtime resume all the child clocks)
Let me know your views on it.
--Kalyan
> _______________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: bcm2711: Update SPI nodes compatible strings
From: Lukas Wunner @ 2020-06-04 11:21 UTC (permalink / raw)
To: Mark Brown
Cc: Florian Fainelli, linux-kernel, Rob Herring,
Nicolas Saenz Julienne, Ray Jui, Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
open list:SPI SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Martin Sperl
In-Reply-To: <20200604111325.GC6644@sirena.org.uk>
On Thu, Jun 04, 2020 at 12:13:25PM +0100, Mark Brown wrote:
> On Thu, Jun 04, 2020 at 06:20:38AM +0200, Lukas Wunner wrote:
> > On Wed, Jun 03, 2020 at 08:46:54PM -0700, Florian Fainelli wrote:
> > > The BCM2711 SoC features 5 SPI controllers which all share the same
> > > interrupt line, the SPI driver needs to support interrupt sharing,
> > > therefore use the chip specific compatible string to help with that.
>
> > You're saying above that the 5 controllers all share the interrupt
> > but below you're only changing the compatible string of 4 controllers.
>
> > So I assume spi0 still has its own interrupt and only the additional
> > 4 controllers present on the BCM2711/BCM7211 share their interrupt?
>
> Regardless of what's going on with the interrupts the compatible string
> should reflect the IP version so unless for some reason someone taped
> out two different versions of the IP it seems odd that the compatible
> strings would vary within a given SoC.
Hm. I guess it may be possible to search the DT for other devices
sharing the same interrupt line and thereby determine whether
IRQF_SHARED is necessary. The helper to perform this search could
live in drivers/of/irq.c as I imagine it might be useful in general.
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: sm8250: add watchdog device
From: Manivannan Sadhasivam @ 2020-06-04 11:35 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: Dmitry Baryshkov, Andy Gross, Bjorn Andersson, Rob Herring,
linux-arm-msm, devicetree, patches, linaro-kernel,
devicetree-owner
In-Reply-To: <1a23cf8a6386e8b78c52199bdcde9b5e@codeaurora.org>
On Thu, Jun 04, 2020 at 04:37:01PM +0530, Sai Prakash Ranjan wrote:
> On 2020-06-04 06:13, Dmitry Baryshkov wrote:
> > Add on-SoC watchdog device node.
> >
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > ---
> > arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> > b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> > index 972d8e04c8a2..f1641c6fe203 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> > @@ -1662,6 +1662,12 @@ config {
> > };
> > };
> >
> > + watchdog@17c10000 {
> > + compatible = "qcom,apss-wdt-sm8250", "qcom,kpss-wdt";
>
> Need to add this compatible to bindings.
>
I did look into this but the binding says,
"compatible : shall contain only one of the following"
So clearly the fallback is not going to work and there is no need to add a
dedicated compatible in the driver. The binding is not in the YAML format to
be validated but still... Other option is to convert the binding to YAML and
make the compatibles listed as 'enum' and 'const' elements appropriately.
Thanks,
Mani
> Thanks,
> Sai
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox