* [PATCH] arm64: dts: qcom: msm8916: Disable coresight by default
From: michael.srba @ 2020-05-13 18:47 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson
Cc: Jeffrey Hugo, Rob Herring, Mathieu Poirier, Suzuki K Poulose,
Mike Leach, linux-arm-msm, devicetree, linux-kernel,
~postmarketos/upstreaming, Michael Srba
From: Michael Srba <michael.srba@seznam.cz>
On some msm8916 devices, attempts at initializing coresight cause the boot to
fail. This was fixed by disabling the coresight-related nodes in the board dts
files. However, a cleaner approach was chosen for fixing the same issue on
msm8998: disabling coresight by default, and enabling it in board dts files
where desired.
This patch implements the same solution for msm8916, removes now redundant
overwrites in board specific dts files and and enables coresight in db410c's
board dts in order to keep the current behavior.
Fixes: b1fcc5702a41 ("arm64: dts: qcom: msm8916: Add CTI options")
Signed-off-by: Michael Srba <michael.srba@seznam.cz>
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 21 +++++++++++
.../boot/dts/qcom/msm8916-longcheer-l8150.dts | 23 ------------
.../qcom/msm8916-samsung-a2015-common.dtsi | 23 ------------
arch/arm64/boot/dts/qcom/msm8916.dtsi | 35 +++++++++++++++++++
4 files changed, 56 insertions(+), 46 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 14982762088d..07c150b0ed54 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -519,6 +519,27 @@ mpps@a000 {
wcnss@a21b000 {
status = "okay";
};
+
+ tpiu@820000 { status = "okay"; };
+ funnel@821000 { status = "okay"; };
+ replicator@824000 { status = "okay"; };
+ etf@825000 { status = "okay"; };
+ etr@826000 { status = "okay"; };
+ funnel@841000 { status = "okay"; };
+ debug@850000 { status = "okay"; };
+ debug@852000 { status = "okay"; };
+ debug@854000 { status = "okay"; };
+ debug@856000 { status = "okay"; };
+ etm@85c000 { status = "okay"; };
+ etm@85d000 { status = "okay"; };
+ etm@85e000 { status = "okay"; };
+ etm@85f000 { status = "okay"; };
+ cti@810000 { status = "okay"; };
+ cti@811000 { status = "okay"; };
+ cti@858000 { status = "okay"; };
+ cti@859000 { status = "okay"; };
+ cti@85a000 { status = "okay"; };
+ cti@85b000 { status = "okay"; };
};
usb2513 {
diff --git a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
index d1ccb9472c8b..691eb1a87bc9 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
@@ -82,29 +82,6 @@ phy {
wcnss@a21b000 {
status = "okay";
};
-
- /*
- * Attempting to enable these devices causes a "synchronous
- * external abort". Suspected cause is that the debug power
- * domain is not enabled by default on this device.
- * Disable these devices for now to avoid the crash.
- *
- * See: https://lore.kernel.org/linux-arm-msm/20190618202623.GA53651@gerhold.net/
- */
- tpiu@820000 { status = "disabled"; };
- funnel@821000 { status = "disabled"; };
- replicator@824000 { status = "disabled"; };
- etf@825000 { status = "disabled"; };
- etr@826000 { status = "disabled"; };
- funnel@841000 { status = "disabled"; };
- debug@850000 { status = "disabled"; };
- debug@852000 { status = "disabled"; };
- debug@854000 { status = "disabled"; };
- debug@856000 { status = "disabled"; };
- etm@85c000 { status = "disabled"; };
- etm@85d000 { status = "disabled"; };
- etm@85e000 { status = "disabled"; };
- etm@85f000 { status = "disabled"; };
};
// FIXME: Use extcon device provided by charger driver when available
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
index 43c5e0f882f1..af812f76e8be 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
@@ -75,29 +75,6 @@ phy {
wcnss@a21b000 {
status = "okay";
};
-
- /*
- * Attempting to enable these devices causes a "synchronous
- * external abort". Suspected cause is that the debug power
- * domain is not enabled by default on this device.
- * Disable these devices for now to avoid the crash.
- *
- * See: https://lore.kernel.org/linux-arm-msm/20190618202623.GA53651@gerhold.net/
- */
- tpiu@820000 { status = "disabled"; };
- funnel@821000 { status = "disabled"; };
- replicator@824000 { status = "disabled"; };
- etf@825000 { status = "disabled"; };
- etr@826000 { status = "disabled"; };
- funnel@841000 { status = "disabled"; };
- debug@850000 { status = "disabled"; };
- debug@852000 { status = "disabled"; };
- debug@854000 { status = "disabled"; };
- debug@856000 { status = "disabled"; };
- etm@85c000 { status = "disabled"; };
- etm@85d000 { status = "disabled"; };
- etm@85e000 { status = "disabled"; };
- etm@85f000 { status = "disabled"; };
};
gpio-keys {
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 8b429954ea29..5cf117e247df 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -1228,6 +1228,8 @@ tpiu@820000 {
clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
clock-names = "apb_pclk", "atclk";
+ status = "disabled";
+
in-ports {
port {
tpiu_in: endpoint {
@@ -1244,6 +1246,8 @@ funnel@821000 {
clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
clock-names = "apb_pclk", "atclk";
+ status = "disabled";
+
in-ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -1283,6 +1287,8 @@ replicator@824000 {
clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
clock-names = "apb_pclk", "atclk";
+ status = "disabled";
+
out-ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -1317,6 +1323,8 @@ etf@825000 {
clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
clock-names = "apb_pclk", "atclk";
+ status = "disabled";
+
in-ports {
port {
etf_in: endpoint {
@@ -1341,6 +1349,8 @@ etr@826000 {
clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
clock-names = "apb_pclk", "atclk";
+ status = "disabled";
+
in-ports {
port {
etr_in: endpoint {
@@ -1357,6 +1367,8 @@ funnel@841000 { /* APSS funnel only 4 inputs are used */
clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
clock-names = "apb_pclk", "atclk";
+ status = "disabled";
+
in-ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -1402,6 +1414,7 @@ debug@850000 {
clocks = <&rpmcc RPM_QDSS_CLK>;
clock-names = "apb_pclk";
cpu = <&CPU0>;
+ status = "disabled";
};
debug@852000 {
@@ -1410,6 +1423,7 @@ debug@852000 {
clocks = <&rpmcc RPM_QDSS_CLK>;
clock-names = "apb_pclk";
cpu = <&CPU1>;
+ status = "disabled";
};
debug@854000 {
@@ -1418,6 +1432,7 @@ debug@854000 {
clocks = <&rpmcc RPM_QDSS_CLK>;
clock-names = "apb_pclk";
cpu = <&CPU2>;
+ status = "disabled";
};
debug@856000 {
@@ -1426,6 +1441,7 @@ debug@856000 {
clocks = <&rpmcc RPM_QDSS_CLK>;
clock-names = "apb_pclk";
cpu = <&CPU3>;
+ status = "disabled";
};
etm0: etm@85c000 {
@@ -1438,6 +1454,8 @@ etm0: etm@85c000 {
cpu = <&CPU0>;
+ status = "disabled";
+
out-ports {
port {
etm0_out: endpoint {
@@ -1457,6 +1475,8 @@ etm1: etm@85d000 {
cpu = <&CPU1>;
+ status = "disabled";
+
out-ports {
port {
etm1_out: endpoint {
@@ -1476,6 +1496,8 @@ etm2: etm@85e000 {
cpu = <&CPU2>;
+ status = "disabled";
+
out-ports {
port {
etm2_out: endpoint {
@@ -1495,6 +1517,8 @@ etm3: etm@85f000 {
cpu = <&CPU3>;
+ status = "disabled";
+
out-ports {
port {
etm3_out: endpoint {
@@ -1512,6 +1536,8 @@ cti@810000 {
clocks = <&rpmcc RPM_QDSS_CLK>;
clock-names = "apb_pclk";
+
+ status = "disabled";
};
/* CTI 1 - TPIU connections */
@@ -1521,6 +1547,8 @@ cti@811000 {
clocks = <&rpmcc RPM_QDSS_CLK>;
clock-names = "apb_pclk";
+
+ status = "disabled";
};
/* CTIs 2-11 - no information - not instantiated */
@@ -1538,6 +1566,7 @@ cti@858000 {
cpu = <&CPU0>;
arm,cs-dev-assoc = <&etm0>;
+ status = "disabled";
};
/* CTI - CPU-1 */
@@ -1551,6 +1580,8 @@ cti@859000 {
cpu = <&CPU1>;
arm,cs-dev-assoc = <&etm1>;
+
+ status = "disabled";
};
/* CTI - CPU-2 */
@@ -1564,6 +1595,8 @@ cti@85a000 {
cpu = <&CPU2>;
arm,cs-dev-assoc = <&etm2>;
+
+ status = "disabled";
};
/* CTI - CPU-3 */
@@ -1577,6 +1610,8 @@ cti@85b000 {
cpu = <&CPU3>;
arm,cs-dev-assoc = <&etm3>;
+
+ status = "disabled";
};
--
2.24.0
^ permalink raw reply related
* [PATCH v3] video: fbdev: ssd1307fb: Added support to Column offset
From: Rodrigo Alencar @ 2020-05-13 18:48 UTC (permalink / raw)
To: linux-fbdev
Cc: linux-kernel, b.zolnierkie, andy.shevchenko, devicetree,
Rodrigo Rolim Mendes de Alencar, Rodrigo Alencar
From: Rodrigo Rolim Mendes de Alencar <alencar.fmce@imbel.gov.br>
This patch provides support for displays like VGM128064B0W10,
which requires a column offset of 2, i.e., its segments starts
in SEG2 and ends in SEG129.
Signed-off-by: Rodrigo Alencar <455.rodrigo.alencar@gmail.com>
---
Documentation/devicetree/bindings/display/ssd1307fb.txt | 1 +
drivers/video/fbdev/ssd1307fb.c | 8 ++++++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/ssd1307fb.txt b/Documentation/devicetree/bindings/display/ssd1307fb.txt
index 27333b9551b3..2dcb6d12d137 100644
--- a/Documentation/devicetree/bindings/display/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/display/ssd1307fb.txt
@@ -19,6 +19,7 @@ Optional properties:
- vbat-supply: The supply for VBAT
- solomon,segment-no-remap: Display needs normal (non-inverted) data column
to segment mapping
+ - solomon,col-offset: Offset of columns (COL/SEG) that the screen is mapped to.
- solomon,com-seq: Display uses sequential COM pin configuration
- solomon,com-lrremap: Display uses left-right COM pin remap
- solomon,com-invdir: Display uses inverted COM pin scan direction
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 8e06ba912d60..102f941104c0 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -74,6 +74,7 @@ struct ssd1307fb_par {
struct fb_info *info;
u8 lookup_table[4];
u32 page_offset;
+ u32 col_offset;
u32 prechargep1;
u32 prechargep2;
struct pwm_device *pwm;
@@ -458,11 +459,11 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
if (ret < 0)
return ret;
- ret = ssd1307fb_write_cmd(par->client, 0x0);
+ ret = ssd1307fb_write_cmd(par->client, par->col_offset);
if (ret < 0)
return ret;
- ret = ssd1307fb_write_cmd(par->client, par->width - 1);
+ ret = ssd1307fb_write_cmd(par->client, par->col_offset + par->width - 1);
if (ret < 0)
return ret;
@@ -626,6 +627,9 @@ static int ssd1307fb_probe(struct i2c_client *client)
if (device_property_read_u32(dev, "solomon,page-offset", &par->page_offset))
par->page_offset = 1;
+ if (device_property_read_u32(dev, "solomon,col-offset", &par->col_offset))
+ par->col_offset = 0;
+
if (device_property_read_u32(dev, "solomon,com-offset", &par->com_offset))
par->com_offset = 0;
--
2.23.0.rc1
^ permalink raw reply related
* [PATCH v7 1/6] MIPS: JZ4780: Introduce SMP support.
From: 周琰杰 (Zhou Yanjie) @ 2020-05-13 18:46 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, devicetree, tsbogend, paulburton, jiaxun.yang,
chenhc, tglx, robh+dt, daniel.lezcano, keescook, paul, krzk, hns,
ebiederm, dongsheng.qiu, yanfei.li, sernia.zhou, zhenwenjin
In-Reply-To: <1589395578-87441-1-git-send-email-zhouyanjie@wanyeetech.com>
Forward port smp support from kernel 3.18.3 of CI20_linux
to upstream kernel 5.6.
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: Paul Boddie <paul@boddie.org.uk>
Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
Notes:
v1->v2:
1.Remove unnecessary "plat_irq_dispatch(void)" in irq-ingenic.c.
2.Add a timeout check for "jz4780_boot_secondary()" to avoid a dead loop.
3.Replace hard code in smp.c with macro.
v2->v3:
1.Remove unnecessary "extern void (*r4k_blast_dcache)(void)" in smp.c.
2.Use "for_each_of_cpu_node" instead "for_each_compatible_node" in smp.c.
3.Use "of_cpu_node_to_id" instead "of_property_read_u32_index" in smp.c.
4.Move LCR related operations to jz4780-cgu.c.
v3->v4:
Rebase on top of kernel 5.6-rc1.
v4->v5:
1.Splitting changes involving "jz4780-cgu.c" into separate commit.
2.Use "request_irq()" replace "setup_irq()".
v5->v6:
In order to have a kernel that works on multiple SoCs at the same
time, use "IS_ENABLED()" replace "#ifdef".
v6->v7:
1.SMP has be decoupled from the SoC version.
2.Add mailboxes 3 and 4 for XBurst.
3.Adjust code in "jz4780_smp_prepare_cpus()".
4."jz4780_smp_init()" has be marked "__init".
arch/mips/include/asm/mach-jz4740/smp.h | 87 +++++++++++
arch/mips/jz4740/Kconfig | 2 +
arch/mips/jz4740/Makefile | 5 +
arch/mips/jz4740/prom.c | 4 +
arch/mips/jz4740/smp-entry.S | 57 +++++++
arch/mips/jz4740/smp.c | 258 ++++++++++++++++++++++++++++++++
arch/mips/kernel/idle.c | 35 ++++-
7 files changed, 447 insertions(+), 1 deletion(-)
create mode 100644 arch/mips/include/asm/mach-jz4740/smp.h
create mode 100644 arch/mips/jz4740/smp-entry.S
create mode 100644 arch/mips/jz4740/smp.c
diff --git a/arch/mips/include/asm/mach-jz4740/smp.h b/arch/mips/include/asm/mach-jz4740/smp.h
new file mode 100644
index 00000000..86f660f
--- /dev/null
+++ b/arch/mips/include/asm/mach-jz4740/smp.h
@@ -0,0 +1,87 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2013, Paul Burton <paul.burton@imgtec.com>
+ * JZ4780 SMP definitions
+ */
+
+#ifndef __MIPS_ASM_MACH_JZ4740_SMP_H__
+#define __MIPS_ASM_MACH_JZ4740_SMP_H__
+
+#define read_c0_corectrl() __read_32bit_c0_register($12, 2)
+#define write_c0_corectrl(val) __write_32bit_c0_register($12, 2, val)
+
+#define read_c0_corestatus() __read_32bit_c0_register($12, 3)
+#define write_c0_corestatus(val) __write_32bit_c0_register($12, 3, val)
+
+#define read_c0_reim() __read_32bit_c0_register($12, 4)
+#define write_c0_reim(val) __write_32bit_c0_register($12, 4, val)
+
+#define read_c0_mailbox0() __read_32bit_c0_register($20, 0)
+#define write_c0_mailbox0(val) __write_32bit_c0_register($20, 0, val)
+
+#define read_c0_mailbox1() __read_32bit_c0_register($20, 1)
+#define write_c0_mailbox1(val) __write_32bit_c0_register($20, 1, val)
+
+#define read_c0_mailbox2() __read_32bit_c0_register($20, 2)
+#define write_c0_mailbox2(val) __write_32bit_c0_register($20, 2, val)
+
+#define read_c0_mailbox3() __read_32bit_c0_register($20, 3)
+#define write_c0_mailbox3(val) __write_32bit_c0_register($20, 3, val)
+
+#define smp_clr_pending(mask) do { \
+ unsigned int stat; \
+ stat = read_c0_corestatus(); \
+ stat &= ~((mask) & 0xff); \
+ write_c0_corestatus(stat); \
+ } while (0)
+
+/*
+ * Core Control register
+ */
+#define CORECTRL_SLEEP1M_SHIFT 17
+#define CORECTRL_SLEEP1M (_ULCAST_(0x1) << CORECTRL_SLEEP1M_SHIFT)
+#define CORECTRL_SLEEP0M_SHIFT 16
+#define CORECTRL_SLEEP0M (_ULCAST_(0x1) << CORECTRL_SLEEP0M_SHIFT)
+#define CORECTRL_RPC1_SHIFT 9
+#define CORECTRL_RPC1 (_ULCAST_(0x1) << CORECTRL_RPC1_SHIFT)
+#define CORECTRL_RPC0_SHIFT 8
+#define CORECTRL_RPC0 (_ULCAST_(0x1) << CORECTRL_RPC0_SHIFT)
+#define CORECTRL_SWRST1_SHIFT 1
+#define CORECTRL_SWRST1 (_ULCAST_(0x1) << CORECTRL_SWRST1_SHIFT)
+#define CORECTRL_SWRST0_SHIFT 0
+#define CORECTRL_SWRST0 (_ULCAST_(0x1) << CORECTRL_SWRST0_SHIFT)
+
+/*
+ * Core Status register
+ */
+#define CORESTATUS_SLEEP1_SHIFT 17
+#define CORESTATUS_SLEEP1 (_ULCAST_(0x1) << CORESTATUS_SLEEP1_SHIFT)
+#define CORESTATUS_SLEEP0_SHIFT 16
+#define CORESTATUS_SLEEP0 (_ULCAST_(0x1) << CORESTATUS_SLEEP0_SHIFT)
+#define CORESTATUS_IRQ1P_SHIFT 9
+#define CORESTATUS_IRQ1P (_ULCAST_(0x1) << CORESTATUS_IRQ1P_SHIFT)
+#define CORESTATUS_IRQ0P_SHIFT 8
+#define CORESTATUS_IRQ0P (_ULCAST_(0x1) << CORESTATUS_IRQ8P_SHIFT)
+#define CORESTATUS_MIRQ1P_SHIFT 1
+#define CORESTATUS_MIRQ1P (_ULCAST_(0x1) << CORESTATUS_MIRQ1P_SHIFT)
+#define CORESTATUS_MIRQ0P_SHIFT 0
+#define CORESTATUS_MIRQ0P (_ULCAST_(0x1) << CORESTATUS_MIRQ0P_SHIFT)
+
+/*
+ * Reset Entry & IRQ Mask register
+ */
+#define REIM_ENTRY_SHIFT 16
+#define REIM_ENTRY (_ULCAST_(0xffff) << REIM_ENTRY_SHIFT)
+#define REIM_IRQ1M_SHIFT 9
+#define REIM_IRQ1M (_ULCAST_(0x1) << REIM_IRQ1M_SHIFT)
+#define REIM_IRQ0M_SHIFT 8
+#define REIM_IRQ0M (_ULCAST_(0x1) << REIM_IRQ0M_SHIFT)
+#define REIM_MBOXIRQ1M_SHIFT 1
+#define REIM_MBOXIRQ1M (_ULCAST_(0x1) << REIM_MBOXIRQ1M_SHIFT)
+#define REIM_MBOXIRQ0M_SHIFT 0
+#define REIM_MBOXIRQ0M (_ULCAST_(0x1) << REIM_MBOXIRQ0M_SHIFT)
+
+extern void jz4780_smp_init(void);
+extern void jz4780_secondary_cpu_entry(void);
+
+#endif /* __MIPS_ASM_MACH_JZ4740_SMP_H__ */
diff --git a/arch/mips/jz4740/Kconfig b/arch/mips/jz4740/Kconfig
index 412d2fa..2b88557 100644
--- a/arch/mips/jz4740/Kconfig
+++ b/arch/mips/jz4740/Kconfig
@@ -34,9 +34,11 @@ config MACH_JZ4770
config MACH_JZ4780
bool
+ select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select MIPS_CPU_SCACHE
select SYS_HAS_CPU_MIPS32_R2
select SYS_SUPPORTS_HIGHMEM
+ select SYS_SUPPORTS_SMP
config MACH_X1000
bool
diff --git a/arch/mips/jz4740/Makefile b/arch/mips/jz4740/Makefile
index 6de14c0..0a0f024 100644
--- a/arch/mips/jz4740/Makefile
+++ b/arch/mips/jz4740/Makefile
@@ -12,3 +12,8 @@ CFLAGS_setup.o = -I$(src)/../../../scripts/dtc/libfdt
# PM support
obj-$(CONFIG_PM) += pm.o
+
+# SMP support
+
+obj-$(CONFIG_SMP) += smp.o
+obj-$(CONFIG_SMP) += smp-entry.o
diff --git a/arch/mips/jz4740/prom.c b/arch/mips/jz4740/prom.c
index ff4555c..4acf5c2c 100644
--- a/arch/mips/jz4740/prom.c
+++ b/arch/mips/jz4740/prom.c
@@ -8,10 +8,14 @@
#include <asm/bootinfo.h>
#include <asm/fw/fw.h>
+#include <asm/mach-jz4740/smp.h>
void __init prom_init(void)
{
fw_init_cmdline();
+
+ if (IS_ENABLED(CONFIG_SMP))
+ jz4780_smp_init();
}
void __init prom_free_prom_memory(void)
diff --git a/arch/mips/jz4740/smp-entry.S b/arch/mips/jz4740/smp-entry.S
new file mode 100644
index 00000000..20049a3
--- /dev/null
+++ b/arch/mips/jz4740/smp-entry.S
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2013, Paul Burton <paul.burton@imgtec.com>
+ * JZ4780 SMP entry point
+ */
+
+#include <asm/addrspace.h>
+#include <asm/asm.h>
+#include <asm/asmmacro.h>
+#include <asm/cacheops.h>
+#include <asm/mipsregs.h>
+
+#define CACHE_SIZE (32 * 1024)
+#define CACHE_LINESIZE 32
+
+.extern jz4780_cpu_entry_sp
+.extern jz4780_cpu_entry_gp
+
+.section .text.smp-entry
+.balign 0x10000
+.set noreorder
+LEAF(jz4780_secondary_cpu_entry)
+ mtc0 zero, CP0_CAUSE
+
+ li t0, ST0_CU0
+ mtc0 t0, CP0_STATUS
+
+ /* cache setup */
+ li t0, KSEG0
+ ori t1, t0, CACHE_SIZE
+ mtc0 zero, CP0_TAGLO, 0
+1: cache Index_Store_Tag_I, 0(t0)
+ cache Index_Store_Tag_D, 0(t0)
+ bne t0, t1, 1b
+ addiu t0, t0, CACHE_LINESIZE
+
+ /* kseg0 cache attribute */
+ mfc0 t0, CP0_CONFIG, 0
+ ori t0, t0, CONF_CM_CACHABLE_NONCOHERENT
+ mtc0 t0, CP0_CONFIG, 0
+
+ /* pagemask */
+ mtc0 zero, CP0_PAGEMASK, 0
+
+ /* retrieve sp */
+ la t0, jz4780_cpu_entry_sp
+ lw sp, 0(t0)
+
+ /* retrieve gp */
+ la t0, jz4780_cpu_entry_gp
+ lw gp, 0(t0)
+
+ /* jump to the kernel in kseg0 */
+ la t0, smp_bootstrap
+ jr t0
+ nop
+ END(jz4780_secondary_cpu_entry)
diff --git a/arch/mips/jz4740/smp.c b/arch/mips/jz4740/smp.c
new file mode 100644
index 00000000..d95d22a
--- /dev/null
+++ b/arch/mips/jz4740/smp.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2013, Paul Burton <paul.burton@imgtec.com>
+ * JZ4780 SMP
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/of.h>
+#include <linux/sched.h>
+#include <linux/sched/task_stack.h>
+#include <linux/smp.h>
+#include <linux/tick.h>
+#include <asm/mach-jz4740/smp.h>
+#include <asm/smp-ops.h>
+
+static struct clk *cpu_clock_gates[CONFIG_NR_CPUS] = { NULL };
+
+u32 jz4780_cpu_entry_sp;
+u32 jz4780_cpu_entry_gp;
+
+static struct cpumask cpu_running;
+
+static DEFINE_SPINLOCK(smp_lock);
+
+static irqreturn_t mbox_handler(int irq, void *dev_id)
+{
+ int cpu = smp_processor_id();
+ u32 action, status;
+
+ spin_lock(&smp_lock);
+
+ switch (cpu) {
+ case 0:
+ action = read_c0_mailbox0();
+ write_c0_mailbox0(0);
+ break;
+ case 1:
+ action = read_c0_mailbox1();
+ write_c0_mailbox1(0);
+ break;
+ case 2:
+ action = read_c0_mailbox2();
+ write_c0_mailbox2(0);
+ break;
+ case 3:
+ action = read_c0_mailbox3();
+ write_c0_mailbox3(0);
+ break;
+ default:
+ panic("unhandled cpu %d!", cpu);
+ }
+
+ /* clear pending mailbox interrupt */
+ status = read_c0_corestatus();
+ status &= ~(CORESTATUS_MIRQ0P << cpu);
+ write_c0_corestatus(status);
+
+ spin_unlock(&smp_lock);
+
+ if (action & SMP_RESCHEDULE_YOURSELF)
+ scheduler_ipi();
+ if (action & SMP_CALL_FUNCTION)
+ generic_smp_call_function_interrupt();
+
+ return IRQ_HANDLED;
+}
+
+static void jz4780_smp_setup(void)
+{
+ u32 addr, reim;
+ int cpu;
+
+ reim = read_c0_reim();
+
+ for (cpu = 0; cpu < NR_CPUS; cpu++) {
+ __cpu_number_map[cpu] = cpu;
+ __cpu_logical_map[cpu] = cpu;
+ set_cpu_possible(cpu, true);
+ }
+
+ /* mask mailbox interrupts for this core */
+ reim &= ~REIM_MBOXIRQ0M;
+ write_c0_reim(reim);
+
+ /* clear mailboxes & pending mailbox IRQs */
+ write_c0_mailbox0(0);
+ write_c0_mailbox1(0);
+ write_c0_corestatus(0);
+
+ /* set reset entry point */
+ addr = KSEG1ADDR((u32)&jz4780_secondary_cpu_entry);
+ WARN_ON(addr & ~REIM_ENTRY);
+ reim &= ~REIM_ENTRY;
+ reim |= addr & REIM_ENTRY;
+
+ /* unmask mailbox interrupts for this core */
+ reim |= REIM_MBOXIRQ0M;
+ write_c0_reim(reim);
+ set_c0_status(STATUSF_IP3);
+ irq_enable_hazard();
+
+ cpumask_set_cpu(cpu, &cpu_running);
+}
+
+static void jz4780_smp_prepare_cpus(unsigned int max_cpus)
+{
+ struct device_node *cpu_node;
+ unsigned cpu, ctrl;
+ int err;
+
+ /* setup the mailbox IRQ */
+ err = request_irq(MIPS_CPU_IRQ_BASE + 3, mbox_handler,
+ IRQF_PERCPU | IRQF_NO_THREAD, "core mailbox", NULL);
+ if (err)
+ pr_err("request_irq() on core mailbox failed\n");
+
+ ctrl = read_c0_corectrl();
+
+ for_each_of_cpu_node(cpu_node) {
+ cpu = of_cpu_node_to_id(cpu_node);
+ if (cpu < 0) {
+ pr_err("Failed to read index of %s\n",
+ cpu_node->full_name);
+ continue;
+ }
+
+ /* use reset entry point from REIM register */
+ ctrl |= CORECTRL_RPC0 << cpu;
+
+ cpu_clock_gates[cpu] = of_clk_get(cpu_node, 0);
+ if (IS_ERR(cpu_clock_gates[cpu])) {
+ cpu_clock_gates[cpu] = NULL;
+ continue;
+ }
+
+ err = clk_prepare(cpu_clock_gates[cpu]);
+ if (err)
+ pr_err("Failed to prepare CPU clock gate\n");
+ }
+
+ write_c0_corectrl(ctrl);
+}
+
+static int jz4780_boot_secondary(int cpu, struct task_struct *idle)
+{
+ unsigned long flags;
+ u32 ctrl;
+
+ spin_lock_irqsave(&smp_lock, flags);
+
+ /* ensure the core is in reset */
+ ctrl = read_c0_corectrl();
+ ctrl |= CORECTRL_SWRST0 << cpu;
+ write_c0_corectrl(ctrl);
+
+ /* ungate core clock */
+ if (cpu_clock_gates[cpu])
+ clk_enable(cpu_clock_gates[cpu]);
+
+ /* set entry sp/gp register values */
+ jz4780_cpu_entry_sp = __KSTK_TOS(idle);
+ jz4780_cpu_entry_gp = (u32)task_thread_info(idle);
+ smp_wmb();
+
+ /* take the core out of reset */
+ ctrl &= ~(CORECTRL_SWRST0 << cpu);
+ write_c0_corectrl(ctrl);
+
+ cpumask_set_cpu(cpu, &cpu_running);
+
+ spin_unlock_irqrestore(&smp_lock, flags);
+
+ return 0;
+}
+
+static void jz4780_init_secondary(void)
+{
+}
+
+static void jz4780_smp_finish(void)
+{
+ u32 reim;
+
+ spin_lock(&smp_lock);
+
+ /* unmask mailbox interrupts for this core */
+ reim = read_c0_reim();
+ reim |= REIM_MBOXIRQ0M << smp_processor_id();
+ write_c0_reim(reim);
+
+ spin_unlock(&smp_lock);
+
+ /* unmask interrupts for this core */
+ change_c0_status(ST0_IM, STATUSF_IP3 | STATUSF_IP2 |
+ STATUSF_IP1 | STATUSF_IP0);
+ irq_enable_hazard();
+
+ /* force broadcast timer */
+ tick_broadcast_force();
+}
+
+static void jz4780_send_ipi_single_locked(int cpu, unsigned int action)
+{
+ u32 mbox;
+
+ switch (cpu) {
+ case 0:
+ mbox = read_c0_mailbox0();
+ write_c0_mailbox0(mbox | action);
+ break;
+ case 1:
+ mbox = read_c0_mailbox1();
+ write_c0_mailbox1(mbox | action);
+ break;
+ default:
+ panic("unhandled cpu %d!", cpu);
+ }
+}
+
+static void jz4780_send_ipi_single(int cpu, unsigned int action)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&smp_lock, flags);
+ jz4780_send_ipi_single_locked(cpu, action);
+ spin_unlock_irqrestore(&smp_lock, flags);
+}
+
+static void jz4780_send_ipi_mask(const struct cpumask *mask,
+ unsigned int action)
+{
+ unsigned long flags;
+ int cpu;
+
+ spin_lock_irqsave(&smp_lock, flags);
+
+ for_each_cpu(cpu, mask)
+ jz4780_send_ipi_single_locked(cpu, action);
+
+ spin_unlock_irqrestore(&smp_lock, flags);
+}
+
+static struct plat_smp_ops jz4780_smp_ops = {
+ .send_ipi_single = jz4780_send_ipi_single,
+ .send_ipi_mask = jz4780_send_ipi_mask,
+ .init_secondary = jz4780_init_secondary,
+ .smp_finish = jz4780_smp_finish,
+ .boot_secondary = jz4780_boot_secondary,
+ .smp_setup = jz4780_smp_setup,
+ .prepare_cpus = jz4780_smp_prepare_cpus,
+};
+
+void __init jz4780_smp_init(void)
+{
+ register_smp_ops(&jz4780_smp_ops);
+}
diff --git a/arch/mips/kernel/idle.c b/arch/mips/kernel/idle.c
index 37f8e78..d33f2d4 100644
--- a/arch/mips/kernel/idle.c
+++ b/arch/mips/kernel/idle.c
@@ -18,6 +18,7 @@
#include <asm/cpu-type.h>
#include <asm/idle.h>
#include <asm/mipsregs.h>
+#include <asm/r4kcache.h>
/*
* Not all of the MIPS CPUs have the "wait" instruction available. Moreover,
@@ -88,6 +89,34 @@ static void __cpuidle rm7k_wait_irqoff(void)
}
/*
+ * The Ingenic jz4780 SMP variant has to write back dirty cache lines before
+ * executing wait. The CPU & cache clock will be gated until we return from
+ * the wait, and if another core attempts to access data from our data cache
+ * during this time then it will lock up.
+ */
+void jz4780_smp_wait_irqoff(void)
+{
+ unsigned long pending = read_c0_cause() & read_c0_status() & CAUSEF_IP;
+
+ /*
+ * Going to idle has a significant overhead due to the cache flush so
+ * try to avoid it if we'll immediately be woken again due to an IRQ.
+ */
+ if (!need_resched() && !pending) {
+ r4k_blast_dcache();
+
+ __asm__(
+ " .set push \n"
+ " .set mips3 \n"
+ " sync \n"
+ " wait \n"
+ " .set pop \n");
+ }
+
+ local_irq_enable();
+}
+
+/*
* Au1 'wait' is only useful when the 32kHz counter is used as timer,
* since coreclock (and the cp0 counter) stops upon executing it. Only an
* interrupt can wake it, so they must be enabled before entering idle modes.
@@ -172,7 +201,6 @@ void __init check_wait(void)
case CPU_CAVIUM_OCTEON_PLUS:
case CPU_CAVIUM_OCTEON2:
case CPU_CAVIUM_OCTEON3:
- case CPU_XBURST:
case CPU_LOONGSON32:
case CPU_XLR:
case CPU_XLP:
@@ -246,6 +274,11 @@ void __init check_wait(void)
cpu_wait = r4k_wait;
*/
break;
+ case CPU_XBURST:
+ if (IS_ENABLED(CONFIG_SMP))
+ cpu_wait = jz4780_smp_wait_irqoff;
+ else
+ cpu_wait = r4k_wait;
default:
break;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v7 2/6] MIPS: CI20: Modify DTS to support high resolution timer for SMP.
From: 周琰杰 (Zhou Yanjie) @ 2020-05-13 18:46 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, devicetree, tsbogend, paulburton, jiaxun.yang,
chenhc, tglx, robh+dt, daniel.lezcano, keescook, paul, krzk, hns,
ebiederm, dongsheng.qiu, yanfei.li, sernia.zhou, zhenwenjin
In-Reply-To: <1589395578-87441-1-git-send-email-zhouyanjie@wanyeetech.com>
Modify DTS, change tcu channel from 2 to 3, channel #0 and #1 for
per core local timer, #2 for clocksource.
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: Paul Boddie <paul@boddie.org.uk>
Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
---
Notes:
v1->v2:
No change.
v2->v3:
No change.
v3->v4:
Rebase on top of kernel 5.6-rc1.
v4->v5:
Move [5/6] in v4 to this patch, to ensure that we can
git-bisect without ending up with a broken kernel.
v5->v6:
No change.
v6->v7:
Remove unnecessary "ingenic,pwm-channels-mask".
arch/mips/boot/dts/ingenic/ci20.dts | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/mips/boot/dts/ingenic/ci20.dts b/arch/mips/boot/dts/ingenic/ci20.dts
index db0ca25..06e3186 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -486,7 +486,12 @@
};
&tcu {
- /* 3 MHz for the system timer and clocksource */
- assigned-clocks = <&tcu TCU_CLK_TIMER0>, <&tcu TCU_CLK_TIMER1>;
- assigned-clock-rates = <3000000>, <3000000>;
+ /*
+ * 750 kHz for the system timers and clocksource,
+ * use channel #0 and #1 for the per cpu system timers,
+ * and use channel #2 for the clocksource.
+ */
+ assigned-clocks = <&tcu TCU_CLK_TIMER0>, <&tcu TCU_CLK_TIMER1>,
+ <&tcu TCU_CLK_TIMER2>;
+ assigned-clock-rates = <750000>, <750000>, <750000>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH v7 4/6] dt-bindings: MIPS: Document Ingenic SoCs binding.
From: 周琰杰 (Zhou Yanjie) @ 2020-05-13 18:46 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, devicetree, tsbogend, paulburton, jiaxun.yang,
chenhc, tglx, robh+dt, daniel.lezcano, keescook, paul, krzk, hns,
ebiederm, dongsheng.qiu, yanfei.li, sernia.zhou, zhenwenjin
In-Reply-To: <1589395578-87441-1-git-send-email-zhouyanjie@wanyeetech.com>
Document the available properties for the SoC root node and the
CPU nodes of the devicetree for the Ingenic XBurst SoCs.
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: Paul Boddie <paul@boddie.org.uk>
Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
---
Notes:
v1->v2:
Change the two Document from txt to yaml.
v2->v3:
Fix formatting errors.
v3->v4:
Fix bugs in the two yaml files.
v4->v5:
No change.
v5->v6:
Rewrite the two yaml files.
v6->v7:
1.Update compatible strings in "ingenic,cpu.yaml".
2.Fix formatting errors, and enum for compatible strings.
3.Remove unnecessary "ingenic,soc.yaml".
.../bindings/mips/ingenic/ingenic,cpu.yaml | 57 ++++++++++++++++++++++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
diff --git a/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
new file mode 100644
index 00000000..afb0207
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mips/ingenic/ingenic,cpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for Ingenic XBurst family CPUs
+
+maintainers:
+ - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
+
+description:
+ Ingenic XBurst family CPUs shall have the following properties.
+
+properties:
+ compatible:
+ oneOf:
+
+ - description: Ingenic XBurst®1 CPU Cores
+ items:
+ enum:
+ - ingenic,xburst-mxu1.0
+ - ingenic,xburst-fpu1.0-mxu1.1
+ - ingenic,xburst-fpu2.0-mxu2.0
+
+ - description: Ingenic XBurst®2 CPU Cores
+ items:
+ enum:
+ - ingenic,xburst2-fpu2.1-mxu2.1-smt
+
+ reg:
+ maxItems: 1
+
+required:
+ - device_type
+ - compatible
+ - reg
+
+examples:
+ - |
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "ingenic,xburst-fpu1.0-mxu1.1";
+ reg = <0>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "ingenic,xburst-fpu1.0-mxu1.1";
+ reg = <1>;
+ };
+ };
+...
--
2.7.4
^ permalink raw reply related
* [PATCH v7 3/6] clocksource: Ingenic: Add high resolution timer support for SMP.
From: 周琰杰 (Zhou Yanjie) @ 2020-05-13 18:46 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, devicetree, tsbogend, paulburton, jiaxun.yang,
chenhc, tglx, robh+dt, daniel.lezcano, keescook, paul, krzk, hns,
ebiederm, dongsheng.qiu, yanfei.li, sernia.zhou, zhenwenjin
In-Reply-To: <1589395578-87441-1-git-send-email-zhouyanjie@wanyeetech.com>
Enable clock event handling on per CPU core basis.
Make sure that interrupts raised on the first core execute
event handlers on the correct CPU core.
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: Paul Boddie <paul@boddie.org.uk>
Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
---
Notes:
v1->v2:
1.Adjust function naming to make it more reasonable.
2.Replace function smp_call_function_single() with
smp_call_function_single_async() in order to resolve
the warning below:
[ 0.350942] smp: Brought up 1 node, 2 CPUs
[ 0.365497] ------------[ cut here ]------------
[ 0.365522] WARNING: CPU: 0 PID: 1 at kernel/smp.c:300 smp_call_function_single+0x110/0x200
[ 0.365533] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc1+ #5
[ 0.365537] Stack : 00000000 59c73bcd 00000037 80074e80 80000000 80670000 805a0000 80620590
[ 0.365557] 8065ce38 8fc0dc8c 806d0000 00000000 80670000 00000001 8fc0dc20 59c73bcd
[ 0.365574] 00000000 00000000 806f0000 80670000 00000000 806dab00 00000000 2d302e35
[ 0.365591] 203a6d6d 806e0000 806e0000 70617773 80670000 00000000 00000000 00000009
[ 0.365610] 00000000 8fc94e20 8fc0de30 80690000 00000018 803592dc 00000000 806d0000
[ 0.365627] ...
[ 0.365634] Call Trace:
[ 0.365647] [<8001b9a0>] show_stack+0x6c/0x12c
[ 0.365663] [<804aed20>] dump_stack+0x98/0xc8
[ 0.365673] [<8003044c>] __warn+0xc4/0xe8
[ 0.365682] [<800304f4>] warn_slowpath_fmt+0x84/0xb8
[ 0.365690] [<800a886c>] smp_call_function_single+0x110/0x200
[ 0.365703] ---[ end trace 5785856ca39c79d5 ]---
[ 0.365557] 8065ce38 8fc0dc8c 806d0000 00000000 80670000 00000001 8fc0dc20 59c73bcd
[ 0.365574] 00000000 00000000 806f0000 80670000 00000000 806dab00 00000000 2d302e35
[ 0.365591] 203a6d6d 806e0000 806e0000 70617773 80670000 00000000 00000000 00000009
[ 0.365610] 00000000 8fc94e20 8fc0de30 80690000 00000018 803592dc 00000000 806d0000
[ 0.365627] ...
[ 0.365634] Call Trace:
[ 0.365647] [<8001b9a0>] show_stack+0x6c/0x12c
[ 0.365663] [<804aed20>] dump_stack+0x98/0xc8
[ 0.365673] [<8003044c>] __warn+0xc4/0xe8
[ 0.365682] [<800304f4>] warn_slowpath_fmt+0x84/0xb8
[ 0.365690] [<800a886c>] smp_call_function_single+0x110/0x200
[ 0.365703] ---[ end trace 5785856ca39c79d5 ]---
v2->v3:
No Change.
v3->v4:
Rebase on top of kernel 5.6-rc1.
v4->v5:
Move the check for (evt->event_handler) from "ingenic_per_cpu_event_handler"
to "ingenic_tcu_cevt_cb".
v5->v6:
No change.
v6->v7:
Remove unnecessary check for "NR_CPUS > 1".
drivers/clocksource/ingenic-timer.c | 103 ++++++++++++++++++++++++++++--------
1 file changed, 82 insertions(+), 21 deletions(-)
diff --git a/drivers/clocksource/ingenic-timer.c b/drivers/clocksource/ingenic-timer.c
index 4963336..9aae939 100644
--- a/drivers/clocksource/ingenic-timer.c
+++ b/drivers/clocksource/ingenic-timer.c
@@ -1,7 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * JZ47xx SoCs TCU IRQ driver
+ * XBurst SoCs TCU IRQ driver
* Copyright (C) 2019 Paul Cercueil <paul@crapouillou.net>
+ * Copyright (C) 2020 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
*/
#include <linux/bitops.h>
@@ -21,18 +22,23 @@
#include <dt-bindings/clock/ingenic,tcu.h>
+static DEFINE_PER_CPU(call_single_data_t, ingenic_cevt_csd);
+
struct ingenic_soc_info {
unsigned int num_channels;
};
struct ingenic_tcu {
struct regmap *map;
+ struct device_node *np;
struct clk *timer_clk, *cs_clk;
+ unsigned int timer_local[NR_CPUS];
unsigned int timer_channel, cs_channel;
struct clock_event_device cevt;
struct clocksource cs;
- char name[4];
+ char name[8];
unsigned long pwm_channels_mask;
+ int cpu;
};
static struct ingenic_tcu *ingenic_tcu;
@@ -81,6 +87,24 @@ static int ingenic_tcu_cevt_set_next(unsigned long next,
return 0;
}
+static void ingenic_per_cpu_event_handler(void *info)
+{
+ struct clock_event_device *cevt = (struct clock_event_device *) info;
+
+ cevt->event_handler(cevt);
+}
+
+static void ingenic_tcu_per_cpu_cb(struct clock_event_device *evt)
+{
+ struct ingenic_tcu *tcu = to_ingenic_tcu(evt);
+ call_single_data_t *csd;
+
+ csd = &per_cpu(ingenic_cevt_csd, tcu->cpu);
+ csd->info = (void *) evt;
+ csd->func = ingenic_per_cpu_event_handler;
+ smp_call_function_single_async(tcu->cpu, csd);
+}
+
static irqreturn_t ingenic_tcu_cevt_cb(int irq, void *dev_id)
{
struct clock_event_device *evt = dev_id;
@@ -89,7 +113,7 @@ static irqreturn_t ingenic_tcu_cevt_cb(int irq, void *dev_id)
regmap_write(tcu->map, TCU_REG_TECR, BIT(tcu->timer_channel));
if (evt->event_handler)
- evt->event_handler(evt);
+ ingenic_tcu_per_cpu_cb(evt);
return IRQ_HANDLED;
}
@@ -105,14 +129,21 @@ static struct clk * __init ingenic_tcu_get_clock(struct device_node *np, int id)
return of_clk_get_from_provider(&args);
}
-static int __init ingenic_tcu_timer_init(struct device_node *np,
- struct ingenic_tcu *tcu)
+static int ingenic_tcu_setup_per_cpu_cevt(struct device_node *np,
+ unsigned int channel)
{
- unsigned int timer_virq, channel = tcu->timer_channel;
+ unsigned int timer_virq;
struct irq_domain *domain;
+ struct ingenic_tcu *tcu;
unsigned long rate;
int err;
+ tcu = kzalloc(sizeof(*tcu), GFP_KERNEL);
+ if (!tcu)
+ return -ENOMEM;
+
+ tcu->map = ingenic_tcu->map;
+
tcu->timer_clk = ingenic_tcu_get_clock(np, channel);
if (IS_ERR(tcu->timer_clk))
return PTR_ERR(tcu->timer_clk);
@@ -139,13 +170,15 @@ static int __init ingenic_tcu_timer_init(struct device_node *np,
goto err_clk_disable;
}
- snprintf(tcu->name, sizeof(tcu->name), "TCU");
+ snprintf(tcu->name, sizeof(tcu->name), "TCU%u", channel);
err = request_irq(timer_virq, ingenic_tcu_cevt_cb, IRQF_TIMER,
tcu->name, &tcu->cevt);
if (err)
goto err_irq_dispose_mapping;
+ tcu->cpu = smp_processor_id();
+ tcu->timer_channel = channel;
tcu->cevt.cpumask = cpumask_of(smp_processor_id());
tcu->cevt.features = CLOCK_EVT_FEAT_ONESHOT;
tcu->cevt.name = tcu->name;
@@ -166,6 +199,25 @@ static int __init ingenic_tcu_timer_init(struct device_node *np,
return err;
}
+static int ingenic_tcu_setup_cevt(unsigned int cpu)
+{
+ int ret;
+
+ ret = ingenic_tcu_setup_per_cpu_cevt(ingenic_tcu->np,
+ ingenic_tcu->timer_local[cpu]);
+ if (ret)
+ goto err_tcu_clocksource_cleanup;
+
+ return 0;
+
+err_tcu_clocksource_cleanup:
+ clocksource_unregister(&ingenic_tcu->cs);
+ clk_disable_unprepare(ingenic_tcu->cs_clk);
+ clk_put(ingenic_tcu->cs_clk);
+ kfree(ingenic_tcu);
+ return ret;
+}
+
static int __init ingenic_tcu_clocksource_init(struct device_node *np,
struct ingenic_tcu *tcu)
{
@@ -240,6 +292,7 @@ static int __init ingenic_tcu_init(struct device_node *np)
const struct ingenic_soc_info *soc_info = id->data;
struct ingenic_tcu *tcu;
struct regmap *map;
+ unsigned cpu = 0;
long rate;
int ret;
@@ -253,13 +306,18 @@ static int __init ingenic_tcu_init(struct device_node *np)
if (!tcu)
return -ENOMEM;
- /* Enable all TCU channels for PWM use by default except channels 0/1 */
- tcu->pwm_channels_mask = GENMASK(soc_info->num_channels - 1, 2);
+ /*
+ * Enable all TCU channels for PWM use by default except channels 0/1,
+ * and channel 2 if target CPU is JZ4780 and SMP is selected.
+ */
+ tcu->pwm_channels_mask = GENMASK(soc_info->num_channels - 1,
+ NR_CPUS + 1);
of_property_read_u32(np, "ingenic,pwm-channels-mask",
(u32 *)&tcu->pwm_channels_mask);
- /* Verify that we have at least two free channels */
- if (hweight8(tcu->pwm_channels_mask) > soc_info->num_channels - 2) {
+ /* Verify that we have at least NR_CPUS + 1 free channels */
+ if (hweight8(tcu->pwm_channels_mask) >
+ soc_info->num_channels - NR_CPUS + 1) {
pr_crit("%s: Invalid PWM channel mask: 0x%02lx\n", __func__,
tcu->pwm_channels_mask);
ret = -EINVAL;
@@ -267,13 +325,19 @@ static int __init ingenic_tcu_init(struct device_node *np)
}
tcu->map = map;
+ tcu->np = np;
ingenic_tcu = tcu;
- tcu->timer_channel = find_first_zero_bit(&tcu->pwm_channels_mask,
+ tcu->timer_local[cpu] = find_first_zero_bit(&tcu->pwm_channels_mask,
soc_info->num_channels);
+
+ for (cpu = 1; cpu < NR_CPUS; cpu++)
+ tcu->timer_local[cpu] = find_next_zero_bit(
+ &tcu->pwm_channels_mask, soc_info->num_channels,
+ tcu->timer_local[cpu - 1] + 1);
+
tcu->cs_channel = find_next_zero_bit(&tcu->pwm_channels_mask,
- soc_info->num_channels,
- tcu->timer_channel + 1);
+ soc_info->num_channels, tcu->timer_local[cpu - 1] + 1);
ret = ingenic_tcu_clocksource_init(np, tcu);
if (ret) {
@@ -281,9 +345,10 @@ static int __init ingenic_tcu_init(struct device_node *np)
goto err_free_ingenic_tcu;
}
- ret = ingenic_tcu_timer_init(np, tcu);
- if (ret)
- goto err_tcu_clocksource_cleanup;
+ /* Setup clock events on each CPU core */
+ ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "Ingenic XBurst: online",
+ ingenic_tcu_setup_cevt, NULL);
+ WARN_ON(ret < 0);
/* Register the sched_clock at the end as there's no way to undo it */
rate = clk_get_rate(tcu->cs_clk);
@@ -291,10 +356,6 @@ static int __init ingenic_tcu_init(struct device_node *np)
return 0;
-err_tcu_clocksource_cleanup:
- clocksource_unregister(&tcu->cs);
- clk_disable_unprepare(tcu->cs_clk);
- clk_put(tcu->cs_clk);
err_free_ingenic_tcu:
kfree(tcu);
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH v7 6/6] MIPS: CI20: Update defconfig to support SMP.
From: 周琰杰 (Zhou Yanjie) @ 2020-05-13 18:46 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, devicetree, tsbogend, paulburton, jiaxun.yang,
chenhc, tglx, robh+dt, daniel.lezcano, keescook, paul, krzk, hns,
ebiederm, dongsheng.qiu, yanfei.li, sernia.zhou, zhenwenjin
In-Reply-To: <1589395578-87441-1-git-send-email-zhouyanjie@wanyeetech.com>
Add "CONFIG_SMP=y" and "CONFIG_NR_CPUS=2" to support SMP.
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: Paul Boddie <paul@boddie.org.uk>
Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
---
Notes:
v1->v2:
No change.
v2->v3:
No change.
v3->v4:
Rebase on top of kernel 5.6-rc1.
v4->v5:
No change.
v5->v6:
No change.
v6->v7:
No change.
arch/mips/configs/ci20_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index 0db0088..c8dd136 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -1,3 +1,5 @@
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_MODULES=y
CONFIG_KERNEL_XZ=y
--
2.7.4
^ permalink raw reply related
* [PATCH v7 5/6] MIPS: Ingenic: Add 'cpus' node for Ingenic SoCs.
From: 周琰杰 (Zhou Yanjie) @ 2020-05-13 18:46 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, devicetree, tsbogend, paulburton, jiaxun.yang,
chenhc, tglx, robh+dt, daniel.lezcano, keescook, paul, krzk, hns,
ebiederm, dongsheng.qiu, yanfei.li, sernia.zhou, zhenwenjin
In-Reply-To: <1589395578-87441-1-git-send-email-zhouyanjie@wanyeetech.com>
Add 'cpus' node to the jz4740.dtsi, jz4770.dtsi, jz4780.dtsi
and x1000.dtsi files.
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: Paul Boddie <paul@boddie.org.uk>
Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
---
Notes:
v1->v2:
No change.
v2->v3:
No change.
v3->v4:
Rebase on top of kernel 5.6-rc1.
v4->v5:
No change.
v5->v6:
No change.
v6->v7:
Update compatible strings.
arch/mips/boot/dts/ingenic/jz4740.dtsi | 14 ++++++++++++++
arch/mips/boot/dts/ingenic/jz4770.dtsi | 15 ++++++++++++++-
arch/mips/boot/dts/ingenic/jz4780.dtsi | 23 +++++++++++++++++++++++
arch/mips/boot/dts/ingenic/x1000.dtsi | 14 ++++++++++++++
4 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/arch/mips/boot/dts/ingenic/jz4740.dtsi b/arch/mips/boot/dts/ingenic/jz4740.dtsi
index a3301ba..1f2f896 100644
--- a/arch/mips/boot/dts/ingenic/jz4740.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4740.dtsi
@@ -7,6 +7,20 @@
#size-cells = <1>;
compatible = "ingenic,jz4740";
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "ingenic,xburst-mxu1.0";
+ reg = <0>;
+
+ clocks = <&cgu JZ4740_CLK_CCLK>;
+ clock-names = "cpu";
+ };
+ };
+
cpuintc: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
diff --git a/arch/mips/boot/dts/ingenic/jz4770.dtsi b/arch/mips/boot/dts/ingenic/jz4770.dtsi
index 0bfb9ed..12c7101 100644
--- a/arch/mips/boot/dts/ingenic/jz4770.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4770.dtsi
@@ -1,5 +1,4 @@
// SPDX-License-Identifier: GPL-2.0
-
#include <dt-bindings/clock/jz4770-cgu.h>
/ {
@@ -7,6 +6,20 @@
#size-cells = <1>;
compatible = "ingenic,jz4770";
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "ingenic,xburst-fpu1.0-mxu1.1";
+ reg = <0>;
+
+ clocks = <&cgu JZ4770_CLK_CCLK>;
+ clock-names = "cpu";
+ };
+ };
+
cpuintc: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index bb89653..03aeeff 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -8,6 +8,29 @@
#size-cells = <1>;
compatible = "ingenic,jz4780";
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "ingenic,xburst-fpu1.0-mxu1.1";
+ reg = <0>;
+
+ clocks = <&cgu JZ4780_CLK_CPU>;
+ clock-names = "cpu";
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "ingenic,xburst-fpu1.0-mxu1.1";
+ reg = <1>;
+
+ clocks = <&cgu JZ4780_CLK_CORE1>;
+ clock-names = "cpu";
+ };
+ };
+
cpuintc: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
diff --git a/arch/mips/boot/dts/ingenic/x1000.dtsi b/arch/mips/boot/dts/ingenic/x1000.dtsi
index 147f7d5..2205e1b 100644
--- a/arch/mips/boot/dts/ingenic/x1000.dtsi
+++ b/arch/mips/boot/dts/ingenic/x1000.dtsi
@@ -8,6 +8,20 @@
#size-cells = <1>;
compatible = "ingenic,x1000", "ingenic,x1000e";
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "ingenic,xburst-fpu1.0-mxu1.1";
+ reg = <0>;
+
+ clocks = <&cgu X1000_CLK_CPU>;
+ clock-names = "cpu";
+ };
+ };
+
cpuintc: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v7 0/6] Introduce SMP support for CI20 (based on JZ4780).
From: 周琰杰 (Zhou Yanjie) @ 2020-05-13 18:46 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, devicetree, tsbogend, paulburton, jiaxun.yang,
chenhc, tglx, robh+dt, daniel.lezcano, keescook, paul, krzk, hns,
ebiederm, dongsheng.qiu, yanfei.li, sernia.zhou, zhenwenjin
In-Reply-To: <1589395578-87441-1-git-send-email-zhouyanjie@wanyeetech.com>
Introduce SMP support for MIPS Creator CI20, which is
based on Ingenic JZ4780 SoC.
周琰杰 (Zhou Yanjie) (6):
MIPS: JZ4780: Introduce SMP support.
MIPS: CI20: Modify DTS to support high resolution timer for SMP.
clocksource: Ingenic: Add high resolution timer support for SMP.
dt-bindings: MIPS: Document Ingenic SoCs binding.
MIPS: Ingenic: Add 'cpus' node for Ingenic SoCs.
MIPS: CI20: Update defconfig to support SMP.
.../bindings/mips/ingenic/ingenic,cpu.yaml | 57 +++++
arch/mips/boot/dts/ingenic/ci20.dts | 11 +-
arch/mips/boot/dts/ingenic/jz4740.dtsi | 14 ++
arch/mips/boot/dts/ingenic/jz4770.dtsi | 15 +-
arch/mips/boot/dts/ingenic/jz4780.dtsi | 23 ++
arch/mips/boot/dts/ingenic/x1000.dtsi | 14 ++
arch/mips/configs/ci20_defconfig | 2 +
arch/mips/include/asm/mach-jz4740/smp.h | 87 +++++++
arch/mips/jz4740/Kconfig | 2 +
arch/mips/jz4740/Makefile | 5 +
arch/mips/jz4740/prom.c | 4 +
arch/mips/jz4740/smp-entry.S | 57 +++++
arch/mips/jz4740/smp.c | 258 +++++++++++++++++++++
arch/mips/kernel/idle.c | 35 ++-
drivers/clocksource/ingenic-timer.c | 103 ++++++--
15 files changed, 661 insertions(+), 26 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
create mode 100644 arch/mips/include/asm/mach-jz4740/smp.h
create mode 100644 arch/mips/jz4740/smp-entry.S
create mode 100644 arch/mips/jz4740/smp.c
--
2.7.4
^ permalink raw reply
* Introduce SMP support for CI20 (based on JZ4780) v7.
From: 周琰杰 (Zhou Yanjie) @ 2020-05-13 18:46 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, devicetree, tsbogend, paulburton, jiaxun.yang,
chenhc, tglx, robh+dt, daniel.lezcano, keescook, paul, krzk, hns,
ebiederm, dongsheng.qiu, yanfei.li, sernia.zhou, zhenwenjin
Introduce SMP support for MIPS Creator CI20, which is
based on Ingenic JZ4780 SoC.
^ permalink raw reply
* Re: [PATCH] dt-bindings: at24: add microchip,24lc[0-9]+ to the compatible pattern
From: Masahiro Yamada @ 2020-05-13 18:33 UTC (permalink / raw)
To: Rob Herring
Cc: DTML, Linux Kernel Mailing List, linux-i2c, Bartosz Golaszewski,
Rob Herring
In-Reply-To: <20200511191400.GA27107@bogus>
Hi Rob,
On Tue, May 12, 2020 at 4:14 AM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, 22 Apr 2020 23:18:36 +0900, Masahiro Yamada wrote:
> > arch/arm/boot/dts/uniphier-ref-daughter.dtsi has
> >
> > compatible = "microchip,24lc128", "atmel,24c128";
> >
> > and 'make ARCH=arm dtbs_check' warns this:
> >
> > eeprom@50: compatible: ['microchip,24lc128', 'atmel,24c128'] is not valid under any of the given schemas (Possible causes of the failure)
> >
> > Microchip 24LC128 is the device used on this board, and I see it in
> > https://www.microchip.com/wwwproducts/en/24LC128
> >
> > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > ---
> >
> > Documentation/devicetree/bindings/eeprom/at24.yaml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Applied, thanks!
If it is not too late, can you correct the patch subject?
See the applied commit in linux-next.
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Wed Apr 22 23:18:36 2020 +0900
dt-bindings: at24: add microchip, 24lc[0-9]+ to the compatible pattern
Please notice a space after 'microchip,'
And this is the patch I submitted:
https://lore.kernel.org/patchwork/patch/1229480/
No space after 'microchip,'
This is a patchwork bug.
It automatically inserts a space after a comma.
Patchwork adds various unpleasant modification,
and breaks the commit subject and log.
I reported this bug to patchwork ML, but
still not fixed...
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v3 20/20] dt-bindings: ehci/ohci: Allow iommus property
From: Sudeep Holla @ 2020-05-13 18:28 UTC (permalink / raw)
To: Andre Przywara
Cc: Rob Herring, Liviu Dudau, Lorenzo Pieralisi, devicetree,
linux-arm-kernel, Mark Rutland, Greg Kroah-Hartman, linux-usb
In-Reply-To: <20200513103016.130417-21-andre.przywara@arm.com>
On Wed, May 13, 2020 at 11:30:16AM +0100, Andre Przywara wrote:
> A OHCI/EHCI controller could be behind an IOMMU, in which case an iommus
> property assigns the stream ID for this device.
>
> Allow that property in the DT bindings to fix a complaint about the Arm Juno
> board's DTS file.
>
I need acks for this and the first dt-binding in order to take it
via ARM SoC. Also where ever possible split arm64 and arm DT in case
ARM SoC wants different PR. I will ask if you have to respin.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v3 16/20] arm64: dts: juno: Fix GPU interrupt order
From: Sudeep Holla @ 2020-05-13 18:24 UTC (permalink / raw)
To: Andre Przywara
Cc: Rob Herring, Liviu Dudau, Lorenzo Pieralisi, devicetree,
linux-arm-kernel, Mark Rutland
In-Reply-To: <20200513103016.130417-17-andre.przywara@arm.com>
On Wed, May 13, 2020 at 11:30:12AM +0100, Andre Przywara wrote:
> The Mali binding insists on the GPU interrupts to be in ordered as: job,
> mmu, gpu.
> Sort the GPU interrupts and interrupt-names properties accordingly.
>
I assume this is not a bug fix, just clean up to make it 100% binding
compliant. Things work just fine without this too. Just for my info.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v3 08/20] arm64: dts: arm: model: Fix GIC compatible names
From: Sudeep Holla @ 2020-05-13 18:21 UTC (permalink / raw)
To: Andre Przywara
Cc: Rob Herring, Liviu Dudau, Lorenzo Pieralisi, devicetree,
linux-arm-kernel, Mark Rutland, Marc Zyngier
In-Reply-To: <20200513103016.130417-9-andre.przywara@arm.com>
On Wed, May 13, 2020 at 11:30:04AM +0100, Andre Przywara wrote:
> The GIC DT binding only allows certain combinations of DT compatible
> strings. The somewhat awkward "arm,cortex-a15-gic", "arm,cortex-a9-gic"
> is not among those.
>
> Drop that combination of different "cortex" based strings used for the
> models, and replace it with the more useful combination including
> "arm,gic-400".
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> arch/arm64/boot/dts/arm/foundation-v8-gicv2.dtsi | 2 +-
> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/arm/foundation-v8-gicv2.dtsi b/arch/arm64/boot/dts/arm/foundation-v8-gicv2.dtsi
> index 15fe81738e94..f17e744163a5 100644
> --- a/arch/arm64/boot/dts/arm/foundation-v8-gicv2.dtsi
> +++ b/arch/arm64/boot/dts/arm/foundation-v8-gicv2.dtsi
> @@ -6,7 +6,7 @@
>
> / {
> gic: interrupt-controller@2c001000 {
> - compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
> + compatible = "arm,gic-400", "arm,cortex-a15-gic";
Do we need to still retain "arm,cortex-a15-gic" ?
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 2/3] remoteproc/k3-dsp: Add a remoteproc driver of K3 C66x DSPs
From: Suman Anna @ 2020-05-13 18:14 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Bjorn Andersson, Rob Herring, Lokesh Vutla, linux-remoteproc,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20200427225737.GB10552@xps15>
Hi Mathieu,
On 4/27/20 5:57 PM, Mathieu Poirier wrote:
> On Wed, Mar 25, 2020 at 03:18:38PM -0500, Suman Anna wrote:
>> The Texas Instrument's K3 J721E SoCs have two C66x DSP Subsystems in MAIN
>> voltage domain that are based on the TI's standard TMS320C66x DSP CorePac
>> module. Each subsystem has a Fixed/Floating-Point DSP CPU, with 32 KB each
>> of L1P & L1D SRAMs that can be configured and partitioned as either RAM
>> and/or Cache, and 288 KB of L2 SRAM with 256 KB of memory configurable as
>> either RAM and/or Cache. The CorePac also includes an Internal DMA (IDMA),
>> External Memory Controller (EMC), Extended Memory Controller (XMC) with a
>> Region Address Translator (RAT) unit for 32-bit to 48-bit address
>> extension/translations, an Interrupt Controller (INTC) and a Powerdown
>> Controller (PDC).
>>
>> A new remoteproc module is added to perform the device management of
>> these DSP devices. The support is limited to images using only external
>> DDR memory at the moment, the loading support to internal memories and
>> any on-chip RAM memories will be added in a subsequent patch. RAT support
>> is also left for a future patch, and as such the reserved memory carveout
>> regions are all expected to be using memory regions within the first 2 GB.
>> Error Recovery and Power Management features are not currently supported.
>>
>> The C66x remote processors do not have an MMU, and so require fixed memory
>> carveout regions matching the firmware image addresses. Support for this
>> is provided by mandating multiple memory regions to be attached to the
>> remoteproc device. The first memory region will be used to serve as the
>> DMA pool for all dynamic allocations like the vrings and vring buffers.
>> The remaining memory regions are mapped into the kernel at device probe
>> time, and are used to provide address translations for firmware image
>> segments without the need for any RSC_CARVEOUT entries. Any firmware
>> image using memory outside of the supplied reserved memory carveout
>> regions will be errored out.
>>
>> The driver uses various TI-SCI interfaces to talk to the System Controller
>> (DMSC) for managing configuration, power and reset management of these
>> cores. IPC between the A72 cores and the DSP cores is supported through
>> the virtio rpmsg stack using shared memory and OMAP Mailboxes.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>> drivers/remoteproc/Kconfig | 16 +
>> drivers/remoteproc/Makefile | 1 +
>> drivers/remoteproc/ti_k3_dsp_remoteproc.c | 736 ++++++++++++++++++++++
>> 3 files changed, 753 insertions(+)
>> create mode 100644 drivers/remoteproc/ti_k3_dsp_remoteproc.c
>>
>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
>> index 073048b4c0fb..66a76acb15b6 100644
>> --- a/drivers/remoteproc/Kconfig
>> +++ b/drivers/remoteproc/Kconfig
>> @@ -240,6 +240,22 @@ config TI_K3_R5_REMOTEPROC
>> It's safe to say N here if you're not interested in utilizing
>> a slave processor
>>
>> +config TI_K3_DSP_REMOTEPROC
>> + tristate "TI K3 DSP remoteproc support"
>> + depends on ARCH_K3
>> + select MAILBOX
>> + select OMAP2PLUS_MBOX
>> + help
>> + Say y here to support TI's C66x and C71x DSP remote processor
>> + subsystems on various TI K3 family of SoCs through the remote
>> + processor framework.
>> +
>> + You want to say m here in order to offload some processing
>> + tasks to these processors.
>
> Building this driver has a module, i.e 'm', has nothing to do with what the
> remote processor does. I would simply remove the above 2 lines.
Yes, can drop. I will switch the "Say y" to "Say m" - that would be the
preferred option. Having the driver built-in means the firmware has to
be part of initramfs.
>
>> +
>> + It's safe to say N here if you're not interested in utilizing
>> + the DSP slave processors.
>> +
>> endif # REMOTEPROC
>>
>> endmenu
>> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
>> index 00ba826818af..eb51cc09e47b 100644
>> --- a/drivers/remoteproc/Makefile
>> +++ b/drivers/remoteproc/Makefile
>> @@ -29,3 +29,4 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
>> obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
>> obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
>> obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
>> +obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
>> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
>> new file mode 100644
>> index 000000000000..fd0d84f46f90
>> --- /dev/null
>> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
>> @@ -0,0 +1,736 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * TI K3 DSP Remote Processor(s) driver
>> + *
>> + * Copyright (C) 2018-2020 Texas Instruments Incorporated - http://www.ti.com/
>> + * Suman Anna <s-anna@ti.com>
>> + */
>> +
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_reserved_mem.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pm_runtime.h>
>> +#include <linux/remoteproc.h>
>> +#include <linux/mailbox_client.h>
>> +#include <linux/omap-mailbox.h>
>
> Please move these two up.
OK.
>
>> +#include <linux/reset.h>
>> +#include <linux/soc/ti/ti_sci_protocol.h>
>> +
>> +#include "omap_remoteproc.h"
>> +#include "remoteproc_internal.h"
>> +#include "ti_sci_proc.h"
>> +
>> +#define KEYSTONE_RPROC_LOCAL_ADDRESS_MASK (SZ_16M - 1)
>> +
>> +/**
>> + * struct k3_dsp_rproc_mem - internal memory structure
>> + * @cpu_addr: MPU virtual address of the memory region
>> + * @bus_addr: Bus address used to access the memory region
>> + * @dev_addr: Device address of the memory region from DSP view
>> + * @size: Size of the memory region
>> + */
>> +struct k3_dsp_rproc_mem {
>
> I would rename this 'k3_dsp_mem' to be consistent with k3_r5_mem.
Yeah, will rename.
>
>> + void __iomem *cpu_addr;
>> + phys_addr_t bus_addr;
>> + u32 dev_addr;
>> + size_t size;
>> +};
>> +
>> +/**
>> + * struct k3_dsp_mem_data - memory definitions for a DSP
>> + * @name: name for this memory entry
>> + * @dev_addr: device address for the memory entry
>> + */
>> +struct k3_dsp_mem_data {
>> + const char *name;
>> + const u32 dev_addr;
>> +};
>> +
>> +/**
>> + * struct k3_dsp_dev_data - device data structure for a DSP
>> + * @mems: pointer to memory definitions for a DSP
>> + * @num_mems: number of memory regions in @mems
>> + * @boot_align_addr: boot vector address alignment granularity
>> + * @uses_lreset: flag to denote the need for local reset management
>> + */
>> +struct k3_dsp_dev_data {
>> + const struct k3_dsp_mem_data *mems;
>> + u32 num_mems;
>> + u32 boot_align_addr;
>> + bool uses_lreset;
>> +};
>> +
>> +/**
>> + * struct k3_dsp_rproc - k3 DSP remote processor driver structure
>> + * @dev: cached device pointer
>> + * @rproc: remoteproc device handle
>> + * @mem: internal memory regions data
>> + * @num_mems: number of internal memory regions
>> + * @rmem: reserved memory regions data
>> + * @num_rmems: number of reserved memory regions
>> + * @reset: reset control handle
>> + * @data: pointer to DSP-specific device data
>> + * @tsp: TI-SCI processor control handle
>> + * @ti_sci: TI-SCI handle
>> + * @ti_sci_id: TI-SCI device identifier
>> + * @mbox: mailbox channel handle
>> + * @client: mailbox client to request the mailbox channel
>> + */
>> +struct k3_dsp_rproc {
>> + struct device *dev;
>> + struct rproc *rproc;
>> + struct k3_dsp_rproc_mem *mem;
>> + int num_mems;
>> + struct k3_dsp_rproc_mem *rmem;
>> + int num_rmems;
>> + struct reset_control *reset;
>> + const struct k3_dsp_dev_data *data;
>> + struct ti_sci_proc *tsp;
>> + const struct ti_sci_handle *ti_sci;
>> + u32 ti_sci_id;
>> + struct mbox_chan *mbox;
>> + struct mbox_client client;
>> +};
>> +
>> +/**
>> + * k3_dsp_rproc_mbox_callback() - inbound mailbox message handler
>> + * @client: mailbox client pointer used for requesting the mailbox channel
>> + * @data: mailbox payload
>> + *
>> + * This handler is invoked by the OMAP mailbox driver whenever a mailbox
>> + * message is received. Usually, the mailbox payload simply contains
>> + * the index of the virtqueue that is kicked by the remote processor,
>> + * and we let remoteproc core handle it.
>> + *
>> + * In addition to virtqueue indices, we also have some out-of-band values
>> + * that indicate different events. Those values are deliberately very
>> + * large so they don't coincide with virtqueue indices.
>> + */
>> +static void k3_dsp_rproc_mbox_callback(struct mbox_client *client, void *data)
>> +{
>> + struct k3_dsp_rproc *kproc = container_of(client, struct k3_dsp_rproc,
>> + client);
>
> Indentation problem.
Thanks. Hmm, checkpatch didn't catch this.
>
>> + struct device *dev = kproc->rproc->dev.parent;
>> + const char *name = kproc->rproc->name;
>> + u32 msg = omap_mbox_message(data);
>> +
>> + dev_dbg(dev, "mbox msg: 0x%x\n", msg);
>> +
>> + switch (msg) {
>> + case RP_MBOX_CRASH:
>> + /*
>> + * remoteproc detected an exception, but error recovery is not
>> + * supported. So, just log this for now
>> + */
>> + dev_err(dev, "K3 DSP rproc %s crashed\n", name);
>> + break;
>> + case RP_MBOX_ECHO_REPLY:
>> + dev_info(dev, "received echo reply from %s\n", name);
>> + break;
>> + default:
>> + /* silently handle all other valid messages */
>> + if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
>> + return;
>> + if (msg > kproc->rproc->max_notifyid) {
>> + dev_dbg(dev, "dropping unknown message 0x%x", msg);
>> + return;
>> + }
>> + /* msg contains the index of the triggered vring */
>> + if (rproc_vq_interrupt(kproc->rproc, msg) == IRQ_NONE)
>> + dev_dbg(dev, "no message was found in vqid %d\n", msg);
>> + }
>> +}
>> +
>> +/*
>> + * Kick the remote processor to notify about pending unprocessed messages.
>> + * The vqid usage is not used and is inconsequential, as the kick is performed
>> + * through a simulated GPIO (a bit in an IPC interrupt-triggering register),
>> + * the remote processor is expected to process both its Tx and Rx virtqueues.
>> + */
>> +static void k3_dsp_rproc_kick(struct rproc *rproc, int vqid)
>> +{
>> + struct k3_dsp_rproc *kproc = rproc->priv;
>> + struct device *dev = rproc->dev.parent;
>> + mbox_msg_t msg = (mbox_msg_t)vqid;
>> + int ret;
>> +
>> + /* send the index of the triggered virtqueue in the mailbox payload */
>> + ret = mbox_send_message(kproc->mbox, (void *)msg);
>> + if (ret < 0)
>> + dev_err(dev, "failed to send mailbox message, status = %d\n",
>> + ret);
>> +}
>> +
>> +/* Put the DSP processor into reset */
>> +static int k3_dsp_rproc_reset(struct k3_dsp_rproc *kproc)
>> +{
>> + struct device *dev = kproc->dev;
>> + int ret;
>> +
>> + ret = reset_control_assert(kproc->reset);
>> + if (ret) {
>> + dev_err(dev, "local-reset assert failed, ret = %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
>> + kproc->ti_sci_id);
>> + if (ret) {
>> + dev_err(dev, "module-reset assert failed, ret = %d\n", ret);
>> + if (reset_control_deassert(kproc->reset))
>> + dev_warn(dev, "local-reset deassert back failed\n");
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +/* Release the DSP processor from reset */
>> +static int k3_dsp_rproc_release(struct k3_dsp_rproc *kproc)
>> +{
>> + struct device *dev = kproc->dev;
>> + int ret;
>> +
>> + ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci,
>> + kproc->ti_sci_id);
>
> Indentation problem.
Thanks for catching, will fix.
>
>> + if (ret) {
>> + dev_err(dev, "module-reset deassert failed, ret = %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = reset_control_deassert(kproc->reset);
>> + if (ret) {
>> + dev_err(dev, "local-reset deassert failed, ret = %d\n", ret);
>> + if (kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
>> + kproc->ti_sci_id))
>> + dev_warn(dev, "module-reset assert back failed\n");
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +/*
>> + * Power up the DSP remote processor.
>> + *
>> + * This function will be invoked only after the firmware for this rproc
>> + * was loaded, parsed successfully, and all of its resource requirements
>> + * were met.
>> + */
>> +static int k3_dsp_rproc_start(struct rproc *rproc)
>> +{
>> + struct k3_dsp_rproc *kproc = rproc->priv;
>> + struct mbox_client *client = &kproc->client;
>> + struct device *dev = kproc->dev;
>> + u32 boot_addr;
>> + int ret;
>> +
>> + client->dev = dev;
>> + client->tx_done = NULL;
>> + client->rx_callback = k3_dsp_rproc_mbox_callback;
>> + client->tx_block = false;
>> + client->knows_txdone = false;
>> +
>> + kproc->mbox = mbox_request_channel(client, 0);
>> + if (IS_ERR(kproc->mbox)) {
>> + ret = -EBUSY;
>> + dev_err(dev, "mbox_request_channel failed: %ld\n",
>> + PTR_ERR(kproc->mbox));
>> + return ret;
>> + }
>> +
>> + /*
>> + * Ping the remote processor, this is only for sanity-sake for now;
>> + * there is no functional effect whatsoever.
>> + *
>> + * Note that the reply will _not_ arrive immediately: this message
>> + * will wait in the mailbox fifo until the remote processor is booted.
>> + */
>> + ret = mbox_send_message(kproc->mbox, (void *)RP_MBOX_ECHO_REQUEST);
>> + if (ret < 0) {
>> + dev_err(dev, "mbox_send_message failed: %d\n", ret);
>> + goto put_mbox;
>> + }
>> +
>> + boot_addr = rproc->bootaddr;
>> + if (boot_addr & (kproc->data->boot_align_addr - 1)) {
>> + dev_err(dev, "invalid boot address 0x%x, must be aligned on a 0x%x boundary\n",
>> + boot_addr, kproc->data->boot_align_addr);
>> + ret = -EINVAL;
>> + goto put_mbox;
>> + }
>> +
>> + dev_err(dev, "booting DSP core using boot addr = 0x%x\n", boot_addr);
>> + ret = ti_sci_proc_set_config(kproc->tsp, boot_addr, 0, 0);
>> + if (ret)
>> + goto put_mbox;
>> +
>> + ret = k3_dsp_rproc_release(kproc);
>> + if (ret)
>> + goto put_mbox;
>> +
>> + return 0;
>> +
>> +put_mbox:
>> + mbox_free_channel(kproc->mbox);
>> + return ret;
>> +}
>> +
>> +/*
>> + * Stop the DSP remote processor.
>> + *
>> + * This function puts the DSP processor into reset, and finishes processing
>> + * of any pending messages.
>> + */
>> +static int k3_dsp_rproc_stop(struct rproc *rproc)
>> +{
>> + struct k3_dsp_rproc *kproc = rproc->priv;
>> +
>> + mbox_free_channel(kproc->mbox);
>> +
>> + k3_dsp_rproc_reset(kproc);
>> +
>> + return 0;
>> +}
>> +
>> +/*
>> + * Custom function to translate a DSP device address (internal RAMs only) to a
>> + * kernel virtual address. The DSPs can access their RAMs at either an internal
>> + * address visible only from a DSP, or at the SoC-level bus address. Both these
>> + * addresses need to be looked through for translation. The translated addresses
>> + * can be used either by the remoteproc core for loading (when using kernel
>> + * remoteproc loader), or by any rpmsg bus drivers.
>> + */
>> +static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
>> +{
>> + struct k3_dsp_rproc *kproc = rproc->priv;
>> + void __iomem *va = NULL;
>> + phys_addr_t bus_addr;
>> + u32 dev_addr, offset;
>> + size_t size;
>> + int i;
>> +
>> + if (len == 0)
>> + return NULL;
>> +
>> + for (i = 0; i < kproc->num_mems; i++) {
>> + bus_addr = kproc->mem[i].bus_addr;
>> + dev_addr = kproc->mem[i].dev_addr;
>> + size = kproc->mem[i].size;
>> +
>> + if (da < KEYSTONE_RPROC_LOCAL_ADDRESS_MASK) {
>> + /* handle DSP-view addresses */
>> + if (da >= dev_addr &&
>> + ((da + len) <= (dev_addr + size))) {
>> + offset = da - dev_addr;
>> + va = kproc->mem[i].cpu_addr + offset;
>> + return (__force void *)va;
>> + }
>> + } else {
>> + /* handle SoC-view addresses */
>> + if (da >= bus_addr &&
>> + (da + len) <= (bus_addr + size)) {
>> + offset = da - bus_addr;
>> + va = kproc->mem[i].cpu_addr + offset;
>> + return (__force void *)va;
>> + }
>> + }
>> + }
>> +
>> + /* handle static DDR reserved memory regions */
>> + for (i = 0; i < kproc->num_rmems; i++) {
>> + dev_addr = kproc->rmem[i].dev_addr;
>> + size = kproc->rmem[i].size;
>> +
>> + if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
>> + offset = da - dev_addr;
>> + va = kproc->rmem[i].cpu_addr + offset;
>> + return (__force void *)va;
>> + }
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> +static const struct rproc_ops k3_dsp_rproc_ops = {
>> + .start = k3_dsp_rproc_start,
>> + .stop = k3_dsp_rproc_stop,
>> + .kick = k3_dsp_rproc_kick,
>> + .da_to_va = k3_dsp_rproc_da_to_va,
>> +};
>> +
>> +static const char *k3_dsp_rproc_get_firmware(struct device *dev)
>> +{
>> + const char *fw_name;
>> + int ret;
>> +
>> + ret = of_property_read_string(dev->of_node, "firmware-name",
>> + &fw_name);
>> + if (ret) {
>> + dev_err(dev, "failed to parse firmware-name property, ret = %d\n",
>> + ret);
>> + return ERR_PTR(ret);
>> + }
>> +
>> + return fw_name;
>> +}
>
> The above is a carbon copy of k3_r5_rproc_get_firmware(). Please reuse the same
> function.
Yeah, I can add this as a common helper to rproc core, would be useful
beyond just the TI rproc drivers.
>
>> +
>> +static int k3_dsp_rproc_of_get_memories(struct platform_device *pdev,
>> + struct k3_dsp_rproc *kproc)
>> +{
>> + const struct k3_dsp_dev_data *data = kproc->data;
>> + struct device *dev = &pdev->dev;
>> + struct resource *res;
>> + int num_mems = 0;
>> + int i;
>> +
>> + num_mems = kproc->data->num_mems;
>> + kproc->mem = devm_kcalloc(kproc->dev, num_mems,
>> + sizeof(*kproc->mem), GFP_KERNEL);
>> + if (!kproc->mem)
>> + return -ENOMEM;
>> +
>> + for (i = 0; i < num_mems; i++) {
>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>> + data->mems[i].name);
>> + if (!res) {
>> + dev_err(dev, "found no memory resource for %s\n",
>> + data->mems[i].name);
>> + return -EINVAL;
>> + }
>> + if (!devm_request_mem_region(dev, res->start,
>> + resource_size(res),
>> + dev_name(dev))) {
>> + dev_err(dev, "could not request %s region for resource\n",
>> + data->mems[i].name);
>> + return -EBUSY;
>> + }
>> +
>> + kproc->mem[i].cpu_addr = devm_ioremap_wc(dev, res->start,
>> + resource_size(res));
>> + if (IS_ERR(kproc->mem[i].cpu_addr)) {
>> + dev_err(dev, "failed to map %s memory\n",
>> + data->mems[i].name);
>> + return PTR_ERR(kproc->mem[i].cpu_addr);
>> + }
>> + kproc->mem[i].bus_addr = res->start;
>> + kproc->mem[i].dev_addr = data->mems[i].dev_addr;
>> + kproc->mem[i].size = resource_size(res);
>> +
>> + dev_dbg(dev, "memory %8s: bus addr %pa size 0x%zx va %pK da 0x%x\n",
>> + data->mems[i].name, &kproc->mem[i].bus_addr,
>> + kproc->mem[i].size, kproc->mem[i].cpu_addr,
>> + kproc->mem[i].dev_addr);
>> +
>> + /* zero out memories to start in a pristine state */
>> + /*
>> + * FIXME: comment out until kernel crash is fixed, possible
>> + * issue with local resets.
>> + * memset((__force void *)kproc->mem[i].cpu_addr, 0,
>> + * kproc->mem[i].size);
>> + */
>
> Things still work without zero'ing out the memory? As such is it mandatory to
> do so? Function k3_r5_core_of_get_internal_memories does not do a memset(). And
> didn't Peng also had this problem?
This is a stale comment, I will clean this up. The zeroing out is not
strictly needed, it is only to ensure that the DSPs are started in a
pristine condition. The issue is unrelated to what Peng reported, it is
not the ARM memset issue (which won't be an issue since I am already
using the ioremap_wc variant), but rather related to device being
powered-on to be able to access the DSP internal memories from ARM. This
won't be powered on at the time this function is invoked anyway. The R5F
does needs to memzero it for ECC reasons, and does so in the
k3_r5_rproc_prepare().
>
>> + }
>> + kproc->num_mems = num_mems;
>> +
>> + return 0;
>> +}
>> +
>> +static int k3_dsp_reserved_mem_init(struct k3_dsp_rproc *kproc)
>> +{
>> + struct device *dev = kproc->dev;
>> + struct device_node *np = dev->of_node;
>> + struct device_node *rmem_np;
>> + struct reserved_mem *rmem;
>> + int num_rmems;
>> + int ret, i;
>> +
>> + num_rmems = of_property_count_elems_of_size(np, "memory-region",
>> + sizeof(phandle));
>> + if (num_rmems <= 0) {
>> + dev_err(dev, "device does not reserved memory regions, ret = %d\n",
>> + num_rmems);
>> + return -EINVAL;
>> + }
>> + if (num_rmems < 2) {
>> + dev_err(dev, "device needs atleast two memory regions to be defined, num = %d\n",
>> + num_rmems);
>> + return -EINVAL;
>> + }
>> +
>> + /* use reserved memory region 0 for vring DMA allocations */
>> + ret = of_reserved_mem_device_init_by_idx(dev, np, 0);
>> + if (ret) {
>> + dev_err(dev, "device cannot initialize DMA pool, ret = %d\n",
>> + ret);
>> + return ret;
>> + }
>> +
>> + num_rmems--;
>> + kproc->rmem = kcalloc(num_rmems, sizeof(*kproc->rmem), GFP_KERNEL);
>> + if (!kproc->rmem) {
>> + ret = -ENOMEM;
>> + goto release_rmem;
>> + }
>> +
>> + /* use remaining reserved memory regions for static carveouts */
>> + for (i = 0; i < num_rmems; i++) {
>> + rmem_np = of_parse_phandle(np, "memory-region", i + 1);
>> + if (!rmem_np) {
>> + ret = -EINVAL;
>> + goto unmap_rmem;
>> + }
>> +
>> + rmem = of_reserved_mem_lookup(rmem_np);
>> + if (!rmem) {
>> + of_node_put(rmem_np);
>> + ret = -EINVAL;
>> + goto unmap_rmem;
>> + }
>> + of_node_put(rmem_np);
>> +
>> + kproc->rmem[i].bus_addr = rmem->base;
>> + /* 64-bit address regions currently not supported */
>> + kproc->rmem[i].dev_addr = (u32)rmem->base;
>> + kproc->rmem[i].size = rmem->size;
>> + kproc->rmem[i].cpu_addr = ioremap_wc(rmem->base, rmem->size);
>> + if (!kproc->rmem[i].cpu_addr) {
>> + dev_err(dev, "failed to map reserved memory#%d at %pa of size %pa\n",
>> + i + 1, &rmem->base, &rmem->size);
>> + ret = -ENOMEM;
>> + goto unmap_rmem;
>> + }
>> +
>> + dev_dbg(dev, "reserved memory%d: bus addr %pa size 0x%zx va %pK da 0x%x\n",
>> + i + 1, &kproc->rmem[i].bus_addr,
>> + kproc->rmem[i].size, kproc->rmem[i].cpu_addr,
>> + kproc->rmem[i].dev_addr);
>> + }
>> + kproc->num_rmems = num_rmems;
>> +
>> + return 0;
>> +
>> +unmap_rmem:
>> + for (i--; i >= 0; i--) {
>> + if (kproc->rmem[i].cpu_addr)
>> + iounmap(kproc->rmem[i].cpu_addr);
>> + }
>> + kfree(kproc->rmem);
>> +release_rmem:
>> + of_reserved_mem_device_release(kproc->dev);
>> + return ret;
>> +}
>
> Other than the type of structure passed to the function, this is an exact
> replica of k3_r5_reserved_mem_init(). Do you foresee either of them changing
> to a point where reusing code would be counter productive? I think we are right
> on the edge where duplication is better than using the same function.
Yeah, nothing at the moment. The number of regions can change, I have
not enabled the support for addresses beyond 32-bit atm, so that is
another factor.
>
>> +
>> +static void k3_dsp_reserved_mem_exit(struct k3_dsp_rproc *kproc)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < kproc->num_rmems; i++)
>> + iounmap(kproc->rmem[i].cpu_addr);
>> + kfree(kproc->rmem);
>> +
>> + of_reserved_mem_device_release(kproc->dev);
>> +}
>> +
>> +static
>> +struct ti_sci_proc *k3_dsp_rproc_of_get_tsp(struct device *dev,
>> + const struct ti_sci_handle *sci)
>> +{
>> + struct ti_sci_proc *tsp;
>> + u32 temp[2];
>> + int ret;
>> +
>> + ret = of_property_read_u32_array(dev->of_node, "ti,sci-proc-ids",
>> + temp, 2);
>> + if (ret < 0)
>> + return ERR_PTR(ret);
>> +
>> + tsp = kzalloc(sizeof(*tsp), GFP_KERNEL);
>> + if (!tsp)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + tsp->dev = dev;
>> + tsp->sci = sci;
>> + tsp->ops = &sci->ops.proc_ops;
>> + tsp->proc_id = temp[0];
>> + tsp->host_id = temp[1];
>> +
>> + return tsp;
>> +}
>
> Contrary to k3_dsp_reserved_mem_init(), this one can definitely be reused for
> both c66 and r5.
Yeah, but is it worth it introduce a common module for one function?
Little bit large to define this as an inline function like I have done
with most of the ti_sci_proc helpers.
>
>> +
>> +static int k3_dsp_rproc_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct device_node *np = dev->of_node;
>> + const struct k3_dsp_dev_data *data;
>> + struct k3_dsp_rproc *kproc;
>> + struct rproc *rproc;
>> + const char *fw_name;
>> + int ret = 0;
>> + int ret1;
>> +
>> + data = of_device_get_match_data(dev);
>> + if (!data)
>> + return -ENODEV;
>> +
>> + fw_name = k3_dsp_rproc_get_firmware(dev);
>> + if (IS_ERR(fw_name))
>> + return PTR_ERR(fw_name);
>> +
>> + rproc = rproc_alloc(dev, dev_name(dev), &k3_dsp_rproc_ops, fw_name,
>> + sizeof(*kproc));
>> + if (!rproc)
>> + return -ENOMEM;
>> +
>> + rproc->has_iommu = false;
>> + rproc->recovery_disabled = true;
>> + kproc = rproc->priv;
>> + kproc->rproc = rproc;
>> + kproc->dev = dev;
>> + kproc->data = data;
>> +
>> + kproc->ti_sci = ti_sci_get_by_phandle(np, "ti,sci");
>> + if (IS_ERR(kproc->ti_sci)) {
>> + ret = PTR_ERR(kproc->ti_sci);
>> + if (ret != -EPROBE_DEFER) {
>> + dev_err(dev, "failed to get ti-sci handle, ret = %d\n",
>> + ret);
>> + }
>> + kproc->ti_sci = NULL;
>> + goto free_rproc;
>> + }
>> +
>> + ret = of_property_read_u32(np, "ti,sci-dev-id", &kproc->ti_sci_id);
>> + if (ret) {
>> + dev_err(dev, "missing 'ti,sci-dev-id' property\n");
>> + goto put_sci;
>> + }
>> +
>> + kproc->reset = devm_reset_control_get_exclusive(dev, NULL);
>> + if (IS_ERR(kproc->reset)) {
>> + ret = PTR_ERR(kproc->reset);
>> + dev_err(dev, "failed to get reset, status = %d\n", ret);
>> + goto put_sci;
>> + }
>> +
>> + kproc->tsp = k3_dsp_rproc_of_get_tsp(dev, kproc->ti_sci);
>> + if (IS_ERR(kproc->tsp)) {
>> + dev_err(dev, "failed to construct ti-sci proc control, ret = %d\n",
>> + ret);
>> + ret = PTR_ERR(kproc->tsp);
>> + goto put_sci;
>> + }
>> +
>> + ret = ti_sci_proc_request(kproc->tsp);
>> + if (ret < 0) {
>> + dev_err(dev, "ti_sci_proc_request failed, ret = %d\n", ret);
>> + goto free_tsp;
>> + }
>> +
>> + pm_runtime_enable(dev);
>> + ret = pm_runtime_get_sync(dev);
>
> What do these give you since the dev_pm_ops is not set for the
> k3_dsp_rproc_driver platform diver and there is no clock specified in the DT?
Yeah, I can drop this. Adding a clock in DT would not have made any
difference here, but a power-domains property would have. And I don't
use the power-domains property because of the genpd handling in driver
core that messes with the device state.
regards
Sumahn
>
> Thanks,
> Mathieu
>
>> + if (ret < 0) {
>> + dev_err(dev, "failed to enable clock, status = %d\n", ret);
>> + pm_runtime_put_noidle(dev);
>> + goto disable_rpm;
>> + }
>> +
>> + ret = k3_dsp_rproc_of_get_memories(pdev, kproc);
>> + if (ret)
>> + goto disable_clk;
>> +
>> + ret = k3_dsp_reserved_mem_init(kproc);
>> + if (ret) {
>> + dev_err(dev, "reserved memory init failed, ret = %d\n", ret);
>> + goto disable_clk;
>> + }
>> +
>> + ret = rproc_add(rproc);
>> + if (ret) {
>> + dev_err(dev, "failed to add register device with remoteproc core, status = %d\n",
>> + ret);
>> + goto release_mem;
>> + }
>> +
>> + platform_set_drvdata(pdev, kproc);
>> +
>> + return 0;
>> +
>> +release_mem:
>> + k3_dsp_reserved_mem_exit(kproc);
>> +disable_clk:
>> + pm_runtime_put_sync(dev);
>> +disable_rpm:
>> + pm_runtime_disable(dev);
>> + ret1 = ti_sci_proc_release(kproc->tsp);
>> + if (ret1)
>> + dev_err(dev, "failed to release proc, ret = %d\n", ret1);
>> +free_tsp:
>> + kfree(kproc->tsp);
>> +put_sci:
>> + ret1 = ti_sci_put_handle(kproc->ti_sci);
>> + if (ret1)
>> + dev_err(dev, "failed to put ti_sci handle, ret = %d\n", ret1);
>> +free_rproc:
>> + rproc_free(rproc);
>> + return ret;
>> +}
>> +
>> +static int k3_dsp_rproc_remove(struct platform_device *pdev)
>> +{
>> + struct k3_dsp_rproc *kproc = platform_get_drvdata(pdev);
>> + struct device *dev = &pdev->dev;
>> + int ret;
>> +
>> + rproc_del(kproc->rproc);
>> + pm_runtime_put_sync(&pdev->dev);
>> + pm_runtime_disable(&pdev->dev);
>> +
>> + ret = ti_sci_proc_release(kproc->tsp);
>> + if (ret)
>> + dev_err(dev, "failed to release proc, ret = %d\n", ret);
>> +
>> + kfree(kproc->tsp);
>> +
>> + ret = ti_sci_put_handle(kproc->ti_sci);
>> + if (ret)
>> + dev_err(dev, "failed to put ti_sci handle, ret = %d\n", ret);
>> +
>> + k3_dsp_reserved_mem_exit(kproc);
>> + rproc_free(kproc->rproc);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct k3_dsp_mem_data c66_mems[] = {
>> + { .name = "l2sram", .dev_addr = 0x800000 },
>> + { .name = "l1pram", .dev_addr = 0xe00000 },
>> + { .name = "l1dram", .dev_addr = 0xf00000 },
>> +};
>> +
>> +static const struct k3_dsp_dev_data c66_data = {
>> + .mems = c66_mems,
>> + .num_mems = ARRAY_SIZE(c66_mems),
>> + .boot_align_addr = SZ_1K,
>> + .uses_lreset = true,
>> +};
>> +
>> +static const struct of_device_id k3_dsp_of_match[] = {
>> + { .compatible = "ti,j721e-c66-dsp", .data = &c66_data, },
>> + { /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, k3_dsp_of_match);
>> +
>> +static struct platform_driver k3_dsp_rproc_driver = {
>> + .probe = k3_dsp_rproc_probe,
>> + .remove = k3_dsp_rproc_remove,
>> + .driver = {
>> + .name = "k3-dsp-rproc",
>> + .of_match_table = k3_dsp_of_match,
>> + },
>> +};
>> +
>> +module_platform_driver(k3_dsp_rproc_driver);
>> +
>> +MODULE_AUTHOR("Suman Anna <s-anna@ti.com>");
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("TI K3 DSP Remoteproc driver");
>> --
>> 2.23.0
>>
^ permalink raw reply
* Re: [PATCH net-next v1] net: phy: tja11xx: add cable-test support
From: Andrew Lunn @ 2020-05-13 18:01 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Mark Rutland, Marek Vasut, Florian Fainelli, devicetree, netdev,
linux-kernel, Rob Herring, Pengutronix Kernel Team, David Jander,
David S. Miller, Heiner Kallweit
In-Reply-To: <20200513174011.kl6l767cimeo6dpy@pengutronix.de>
> What would be the best place to do a test before the link is getting up?
> Can it be done in the phy core, or it should be done in the PHY driver?
>
> So far, no action except of logging these errors is needed.
You could do it in the config_aneg callback.
A kernel log entry is not very easy to use. You might want to see how
easy it is to send a cable test result to userspace. Anything which is
interested in this information can then listen for it. All the needed
code is there, you will just need to rearrange it a bit.
Andrew
^ permalink raw reply
* Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile
From: Florian Fainelli @ 2020-05-13 17:46 UTC (permalink / raw)
To: Alan Stern, Greg Kroah-Hartman
Cc: Al Cooper, linux-kernel, Andy Shevchenko,
bcm-kernel-feedback-list, devicetree, Krzysztof Kozlowski,
linux-usb, Mathias Nyman, Rob Herring, Yoshihiro Shimoda,
Andy Shevchenko
In-Reply-To: <20200513173920.GA2862@rowland.harvard.edu>
On 5/13/2020 10:39 AM, Alan Stern wrote:
> On Wed, May 13, 2020 at 07:05:05PM +0200, Greg Kroah-Hartman wrote:
>> On Wed, May 13, 2020 at 09:31:11AM -0700, Florian Fainelli wrote:
>>>
>>>
>>> On 5/13/2020 9:27 AM, Greg Kroah-Hartman wrote:
>>>> On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
>>>>>
>>>>>
>>>>> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
>>>>>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
>>>>>>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
>>>>>>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
>>>>>>> devices and OHCI handles <2.0 devices. Currently the Makefile
>>>>>>> has XHCI linking at the bottom which will result in the XHIC driver
>>>>>>> initalizing after the EHCI and OHCI drivers and any installed 3.0
>>>>>>> device will be seen as a 2.0 device. Moving the XHCI linking
>>>>>>> above the EHCI and OHCI linking fixes the issue.
>>>>>>
>>>>>> What happens if all of these are modules and they are loaded in a
>>>>>> different order? This makefile change will not help with that, you need
>>>>>> to have logic in the code in order to properly coordinate this type of
>>>>>> mess, sorry.
>>>>>
>>>>> I believe we should be using module soft dependencies to instruct the
>>>>> module loaders to load the modules in the correct order, so something
>>>>> like this would do (not tested) for xhci-plat-hcd.c:
>>>>>
>>>>> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
>>>>>
>>>>> and I am not sure whether we need to add the opposite for ehci-hcd and
>>>>> ohci-hcd:
>>>>>
>>>>> MODULE_SOFTDEP("pre: xhci-plat-hcd");
>>>>
>>>> That's a nice start, but what happens if that isn't honored? This
>>>> really needs to work properly for any order as you never can guarantee
>>>> module/driver loading order in a system of modules.
>>>
>>> I also suggested that device links may help, though I am not sure. What
>>> do you suggest to be done?
>>
>> No idea. device links will help if you defer the probe properly until
>> you see the proper drivers binding correctly.
>
> I suspect that in general there is no way to do this properly.
>
> We can't modify ehci-hcd and ohci-hcd to make them wait. In fact, for
> all they know, xhci-hcd will _never_ be loaded.
>
> One thing that might be possible (although not all platforms may support
> it) is if xhci-hcd could somehow disconnect all devices attached to a
> peer port when it starts up. But that would be disruptive to any
> devices that aren't USB-3.
>
> We faced a very similar ordering problem between ehci-hcd and
> [ou]hci-hcd many years ago, and we never found a good solution.
> We did arrange the link order so that ehci-hcd precedes the others, and
> we added a warning message to ehci-hcd which gets printed if the module
> initialization routine runs after [ou]hci-hcd is loaded. Also, there
> are MODULE_SOFTDEP lines in ohci-pci.c and uhci-pci.c.
Given that these modules are used on specific SoC platforms, where we
usually provide a reference implementation of user space and kernel
space and documentation, it seems to me that the MODULE_SOFTDEP(),
despite being a hint and best effort from user space module loaders is
probably acceptable.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v1] net: phy: tja11xx: add cable-test support
From: Oleksij Rempel @ 2020-05-13 17:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Rutland, Marek Vasut, Florian Fainelli, devicetree, netdev,
linux-kernel, Rob Herring, Pengutronix Kernel Team, David Jander,
David S. Miller, Heiner Kallweit
In-Reply-To: <20200513133925.GD499265@lunn.ch>
On Wed, May 13, 2020 at 03:39:25PM +0200, Andrew Lunn wrote:
> On Wed, May 13, 2020 at 02:34:40PM +0200, Oleksij Rempel wrote:
> > Add initial cable testing support.
> > This PHY needs only 100usec for this test and it is recommended to run it
> > before the link is up. For now, provide at least ethtool support, so it
> > can be tested by more developers.
> >
> > This patch was tested with TJA1102 PHY with following results:
> > - No cable, is detected as open
> > - 1m cable, with no connected other end and detected as open
> > - a 40m cable (out of spec, max lenght should be 15m) is detected as OK.
> >
> > Current patch do not provide polarity test support. This test would
> > indicate not proper wire connection, where "+" wire of main phy is
> > connected to the "-" wire of the link partner.
> >
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > ---
> > drivers/net/phy/nxp-tja11xx.c | 106 +++++++++++++++++++++++++++++++++-
> > 1 file changed, 105 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/nxp-tja11xx.c b/drivers/net/phy/nxp-tja11xx.c
> > index ca5f9d4dc57ed..8b743d25002b9 100644
> > --- a/drivers/net/phy/nxp-tja11xx.c
> > +++ b/drivers/net/phy/nxp-tja11xx.c
> > @@ -5,6 +5,7 @@
> > */
> > #include <linux/delay.h>
> > #include <linux/ethtool.h>
> > +#include <linux/ethtool_netlink.h>
> > #include <linux/kernel.h>
> > #include <linux/mdio.h>
> > #include <linux/mii.h>
> > @@ -26,6 +27,7 @@
> > #define MII_ECTRL_POWER_MODE_NO_CHANGE (0x0 << 11)
> > #define MII_ECTRL_POWER_MODE_NORMAL (0x3 << 11)
> > #define MII_ECTRL_POWER_MODE_STANDBY (0xc << 11)
> > +#define MII_ECTRL_CABLE_TEST BIT(5)
> > #define MII_ECTRL_CONFIG_EN BIT(2)
> > #define MII_ECTRL_WAKE_REQUEST BIT(0)
> >
> > @@ -55,6 +57,11 @@
> > #define MII_GENSTAT 24
> > #define MII_GENSTAT_PLL_LOCKED BIT(14)
> >
> > +#define MII_EXTSTAT 25
> > +#define MII_EXTSTAT_SHORT_DETECT BIT(8)
> > +#define MII_EXTSTAT_OPEN_DETECT BIT(7)
> > +#define MII_EXTSTAT_POLARITY_DETECT BIT(6)
> > +
>
> Do these registers all conform to the standard? Can we pull this code
> out into a library which all standards conformant PHY drivers can use?
According to opensig, this functionality should be present on all new T1 PHYs.
But the register/bit layout is no specified as standard. At least I was not able
to find it. I assume, current layout is TJA11xx specific.
> The code itself looks O.K.
What would be the best place to do a test before the link is getting up?
Can it be done in the phy core, or it should be done in the PHY driver?
So far, no action except of logging these errors is needed.
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile
From: Alan Stern @ 2020-05-13 17:39 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Florian Fainelli, Al Cooper, linux-kernel, Andy Shevchenko,
bcm-kernel-feedback-list, devicetree, Krzysztof Kozlowski,
linux-usb, Mathias Nyman, Rob Herring, Yoshihiro Shimoda,
Andy Shevchenko
In-Reply-To: <20200513170505.GB1369204@kroah.com>
On Wed, May 13, 2020 at 07:05:05PM +0200, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2020 at 09:31:11AM -0700, Florian Fainelli wrote:
> >
> >
> > On 5/13/2020 9:27 AM, Greg Kroah-Hartman wrote:
> > > On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
> > >>
> > >>
> > >> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> > >>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
> > >>>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
> > >>>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
> > >>>> devices and OHCI handles <2.0 devices. Currently the Makefile
> > >>>> has XHCI linking at the bottom which will result in the XHIC driver
> > >>>> initalizing after the EHCI and OHCI drivers and any installed 3.0
> > >>>> device will be seen as a 2.0 device. Moving the XHCI linking
> > >>>> above the EHCI and OHCI linking fixes the issue.
> > >>>
> > >>> What happens if all of these are modules and they are loaded in a
> > >>> different order? This makefile change will not help with that, you need
> > >>> to have logic in the code in order to properly coordinate this type of
> > >>> mess, sorry.
> > >>
> > >> I believe we should be using module soft dependencies to instruct the
> > >> module loaders to load the modules in the correct order, so something
> > >> like this would do (not tested) for xhci-plat-hcd.c:
> > >>
> > >> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
> > >>
> > >> and I am not sure whether we need to add the opposite for ehci-hcd and
> > >> ohci-hcd:
> > >>
> > >> MODULE_SOFTDEP("pre: xhci-plat-hcd");
> > >
> > > That's a nice start, but what happens if that isn't honored? This
> > > really needs to work properly for any order as you never can guarantee
> > > module/driver loading order in a system of modules.
> >
> > I also suggested that device links may help, though I am not sure. What
> > do you suggest to be done?
>
> No idea. device links will help if you defer the probe properly until
> you see the proper drivers binding correctly.
I suspect that in general there is no way to do this properly.
We can't modify ehci-hcd and ohci-hcd to make them wait. In fact, for
all they know, xhci-hcd will _never_ be loaded.
One thing that might be possible (although not all platforms may support
it) is if xhci-hcd could somehow disconnect all devices attached to a
peer port when it starts up. But that would be disruptive to any
devices that aren't USB-3.
We faced a very similar ordering problem between ehci-hcd and
[ou]hci-hcd many years ago, and we never found a good solution.
We did arrange the link order so that ehci-hcd precedes the others, and
we added a warning message to ehci-hcd which gets printed if the module
initialization routine runs after [ou]hci-hcd is loaded. Also, there
are MODULE_SOFTDEP lines in ohci-pci.c and uhci-pci.c.
Alan Stern
^ permalink raw reply
* Re: [PATCH v3 04/20] arm64: dts: arm: vexpress: Move fixed devices out of bus node
From: Sudeep Holla @ 2020-05-13 17:26 UTC (permalink / raw)
To: Andre Przywara
Cc: Rob Herring, Liviu Dudau, Lorenzo Pieralisi, devicetree,
linux-arm-kernel, Mark Rutland
In-Reply-To: <20200513103016.130417-5-andre.przywara@arm.com>
On Wed, May 13, 2020 at 11:30:00AM +0100, Andre Przywara wrote:
> The devicetree compiler complains when DT nodes without a reg property
> live inside a (simple) bus node:
> Warning (simple_bus_reg): Node /bus@8000000/motherboard-bus/refclk32khz
> missing or empty reg/ranges property
>
> Move the fixed clocks, the fixed regulator, the leds and the config bus
> subtree to the root node, since they do not depend on any busses.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 308 ++++++++++++------------
> 1 file changed, 154 insertions(+), 154 deletions(-)
>
$subject tells this is arm64 while patch is arm32, I can fix up in case
you don't respin.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v8 1/3] dt-bindings: phy: Add DT bindings for Xilinx ZynqMP PSGTR PHY
From: Laurent Pinchart @ 2020-05-13 17:22 UTC (permalink / raw)
To: linux-kernel
Cc: Kishon Vijay Abraham I, Anurag Kumar Vulisha, Michal Simek,
Vinod Koul, Rob Herring, devicetree
In-Reply-To: <20200513172239.26444-1-laurent.pinchart@ideasonboard.com>
From: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
Add DT bindings for the Xilinx ZynqMP PHY. ZynqMP SoCs have a High Speed
Processing System Gigabit Transceiver which provides PHY capabilities to
USB, SATA, PCIE, Display Port and Ehernet SGMII controllers.
Signed-off-by: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Changes since v7:
- Switch to GPL-2.0-only OR BSD-2-Clause
Changes since v6:
- Fixed specification of compatible-dependent xlnx,tx-termination-fix
property
- Dropped status property from example
- Use 4 spaces to indent example
Changes since v5:
- Document clocks and clock-names properties
- Document resets and reset-names properties
- Replace subnodes with an additional entry in the PHY cells
- Drop lane frequency PHY cell, replaced by reference clock phandle
- Convert bindings to YAML
- Reword the subject line
- Drop Rob's R-b as the bindings have significantly changed
- Drop resets and reset-names properties
---
.../bindings/phy/xlnx,zynqmp-psgtr.yaml | 105 ++++++++++++++++++
include/dt-bindings/phy/phy.h | 1 +
2 files changed, 106 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml
diff --git a/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml b/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml
new file mode 100644
index 000000000000..09e3cde7ebca
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/xlnx,zynqmp-psgtr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx ZynqMP Gigabit Transceiver PHY Device Tree Bindings
+
+maintainers:
+ - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+description: |
+ This binding describes the Xilinx ZynqMP Gigabit Transceiver (GTR) PHY. The
+ GTR provides four lanes and is used by USB, SATA, PCIE, Display port and
+ Ethernet SGMII controllers.
+
+properties:
+ "#phy-cells":
+ const: 4
+ description: |
+ The cells contain the following arguments.
+
+ - description: The GTR lane
+ minimum: 0
+ maximum: 3
+ - description: The PHY type
+ enum:
+ - PHY_TYPE_DP
+ - PHY_TYPE_PCIE
+ - PHY_TYPE_SATA
+ - PHY_TYPE_SGMII
+ - PHY_TYPE_USB
+ - description: The PHY instance
+ minimum: 0
+ maximum: 1 # for DP, SATA or USB
+ maximum: 3 # for PCIE or SGMII
+ - description: The reference clock number
+ minimum: 0
+ maximum: 3
+
+ compatible:
+ enum:
+ - xlnx,zynqmp-psgtr-v1.1
+ - xlnx,zynqmp-psgtr
+
+ clocks:
+ minItems: 1
+ maxItems: 4
+ description: |
+ Clock for each PS_MGTREFCLK[0-3] reference clock input. Unconnected
+ inputs shall not have an entry.
+
+ clock-names:
+ minItems: 1
+ maxItems: 4
+ items:
+ pattern: "^ref[0-3]$"
+
+ reg:
+ items:
+ - description: SERDES registers block
+ - description: SIOU registers block
+
+ reg-names:
+ items:
+ - const: serdes
+ - const: siou
+
+ xlnx,tx-termination-fix:
+ description: |
+ Include this for fixing functional issue with the TX termination
+ resistance in GT, which can be out of spec for the XCZU9EG silicon
+ version.
+ type: boolean
+
+required:
+ - "#phy-cells"
+ - compatible
+ - reg
+ - reg-names
+
+if:
+ properties:
+ compatible:
+ const: xlnx,zynqmp-psgtr-v1.1
+
+then:
+ properties:
+ xlnx,tx-termination-fix: false
+
+additionalProperties: false
+
+examples:
+ - |
+ phy: phy@fd400000 {
+ compatible = "xlnx,zynqmp-psgtr-v1.1";
+ reg = <0x0 0xfd400000 0x0 0x40000>,
+ <0x0 0xfd3d0000 0x0 0x1000>;
+ reg-names = "serdes", "siou";
+ clocks = <&refclks 3>, <&refclks 2>, <&refclks 0>;
+ clock-names = "ref1", "ref2", "ref3";
+ #phy-cells = <4>;
+ };
+
+...
diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h
index 1f3f866fae7b..f6bc83b66ae9 100644
--- a/include/dt-bindings/phy/phy.h
+++ b/include/dt-bindings/phy/phy.h
@@ -17,5 +17,6 @@
#define PHY_TYPE_USB3 4
#define PHY_TYPE_UFS 5
#define PHY_TYPE_DP 6
+#define PHY_TYPE_SGMII 7
#endif /* _DT_BINDINGS_PHY */
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* Re: [PATCH v3 03/20] arm64: dts: arm: fvp: Move fixed devices out of bus node
From: Sudeep Holla @ 2020-05-13 17:22 UTC (permalink / raw)
To: Andre Przywara
Cc: Rob Herring, Liviu Dudau, Lorenzo Pieralisi, devicetree,
linux-arm-kernel, Sudeep Holla, Mark Rutland
In-Reply-To: <20200513103016.130417-4-andre.przywara@arm.com>
On Wed, May 13, 2020 at 11:29:59AM +0100, Andre Przywara wrote:
> The devicetree compiler complains when DT nodes without a reg property
> live inside a (simple) bus node:
> Warning (simple_bus_reg): Node /bus@8000000/motherboard-bus/v2m_refclk32khz
> missing or empty reg/ranges property
>
> Move the fixed clocks, the fixed regulator, and the config bus subtree
> to the root node, since they do not depend on any busses.
>
[nit] only if you respin the series, you can drop extra "arm:" in the
subject. Also if it contains both fvp and juno change, use fvp/juno.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v2] video: fbdev: ssd1307fb: Added support to Column offset
From: Rodrigo Alencar @ 2020-05-13 17:20 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-fbdev, Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz,
devicetree, Rodrigo Rolim Mendes de Alencar
In-Reply-To: <CAHp75VeycGutrfTCrVP-9V61ag-KbNHfykQXHWU-8hwEFOerMQ@mail.gmail.com>
Em qua., 13 de mai. de 2020 às 14:13, Andy Shevchenko
<andy.shevchenko@gmail.com> escreveu:
>
> On Wed, May 13, 2020 at 7:56 PM Rodrigo Rolim Mendes de Alencar
> <455.rodrigo.alencar@gmail.com> wrote:
> >
> > This patch provides support for displays like VGM128064B0W10,
> > which requires a column offset of 2, i.e., its segments starts
> > in SEG2 and ends in SEG129.
>
> Also, include Rob as well into Cc.
>
> ...
>
> > + if (device_property_read_u32(node, "solomon,col-offset", &par->col_offset))
> > + par->col_offset = 0;
> > +
> > if (device_property_read_u32(dev, "solomon,com-offset", &par->com_offset))
> > par->com_offset = 0;
>
> Have you ever compile it?
hmm I did it now. Sorry... found another issue. I'll fix it again
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs
From: Suman Anna @ 2020-05-13 17:20 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Bjorn Andersson, Rob Herring, Lokesh Vutla, linux-remoteproc,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20200427194915.GA10552@xps15>
On 4/27/20 2:49 PM, Mathieu Poirier wrote:
> Hi Suman,
>
> I have started to review this set - comments will come over the next few days.
>
> On Wed, Mar 25, 2020 at 03:18:37PM -0500, Suman Anna wrote:
>> Some Texas Instruments K3 family of SoCs have one of more Digital Signal
>> Processor (DSP) subsystems that are comprised of either a TMS320C66x
>> CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
>> Add the device tree bindings document for the C66x DSP devices on these
>> SoCs. The added example illustrates the DT nodes for the first C66x DSP
>> device present on the K3 J721E family of SoCs.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>> .../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 180 ++++++++++++++++++
>> 1 file changed, 180 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>> new file mode 100644
>> index 000000000000..416e3abe7937
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>> @@ -0,0 +1,180 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: TI K3 DSP devices
>> +
>> +maintainers:
>> + - Suman Anna <s-anna@ti.com>
>> +
>> +description: |
>> + The TI K3 family of SoCs usually have one or more TI DSP Core sub-systems
>> + that are used to offload some of the processor-intensive tasks or algorithms,
>> + for achieving various system level goals.
>> +
>> + These processor sub-systems usually contain additional sub-modules like
>> + L1 and/or L2 caches/SRAMs, an Interrupt Controller, an external memory
>> + controller, a dedicated local power/sleep controller etc. The DSP processor
>> + cores in the K3 SoCs are usually either a TMS320C66x CorePac processor or a
>> + TMS320C71x CorePac processor.
>> +
>> + Each DSP Core sub-system is represented as a single DT node. Each node has a
>> + number of required or optional properties that enable the OS running on the
>> + host processor (Arm CorePac) to perform the device management of the remote
>> + processor and to communicate with the remote processor.
>> +
>> +properties:
>> + compatible:
>> + const: ti,j721e-c66-dsp
>> + description:
>> + Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
>> +
>> + reg:
>> + description: |
>> + Should contain an entry for each value in 'reg-names'.
>> + Each entry should have the memory region's start address
>> + and the size of the region, the representation matching
>> + the parent node's '#address-cells' and '#size-cells' values.
>> + minItems: 3
>> + maxItems: 3
>> +
>> + reg-names:
>> + description: |
>> + Should contain strings with the names of the specific internal
>> + internal memory regions, and should be defined in this order
>
> The word "internal" is found twice in a row.
>
>> + maxItems: 3
>> + items:
>> + - const: l2sram
>> + - const: l1pram
>> + - const: l1dram
>> +
>> + ti,sci:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + Should be a phandle to the TI-SCI System Controller node
>> +
>> + ti,sci-dev-id:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description: |
>> + Should contain the TI-SCI device id corresponding to the DSP core.
>> + Please refer to the corresponding System Controller documentation
>> + for valid values for the DSP cores.
>> +
>> + ti,sci-proc-ids:
>> + description: Should contain a single tuple of <proc_id host_id>.
>> + allOf:
>> + - $ref: /schemas/types.yaml#/definitions/uint32-matrix
>> + - maxItems: 1
>> + items:
>> + items:
>> + - description: TI-SCI processor id for the DSP core device
>> + - description: TI-SCI host id to which processor control
>> + ownership should be transferred to
>> +
>> + resets:
>> + description: |
>> + Should contain the phandle to the reset controller node
>> + managing the resets for this device, and a reset
>> + specifier. Please refer to the following reset bindings
>> + for the reset argument specifier,
>> + Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>> +
>> + firmware-name:
>> + description: |
>> + Should contain the name of the default firmware image
>> + file located on the firmware search path
>> +
>> + mboxes:
>> + description: |
>> + OMAP Mailbox specifier denoting the sub-mailbox, to be used for
>> + communication with the remote processor. This property should match
>> + with the sub-mailbox node used in the firmware image. The specifier
>> + format is as per the bindings,
>> + Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
>> +
>> + memory-region:
>> + minItems: 2
>> + description: |
>> + phandle to the reserved memory nodes to be associated with the remoteproc
>> + device. There should be atleast two reserved memory nodes defined - the
>> + first one would be used for dynamic DMA allocations like vrings and vring
>> + buffers, and the remaining ones used for the firmware image sections. The
>> + reserved memory nodes should be carveout nodes, and should be defined as
>> + per the bindings in
>> + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>> +
>> +# Optional properties:
>> +# --------------------
>> +
>> + sram:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + minItems: 1
>> + description: |
>> + pHandles to one or more reserved on-chip SRAM regions. The regions
>
> s/pHandle/phandle
Thanks Mathieu, will fix both of these in the next version.
regards
Suman
>
> Thanks,
> Mathieu
>
>> + should be defined as child nodes of the respective SRAM node, and
>> + should be defined as per the generic bindings in,
>> + Documentation/devicetree/bindings/sram/sram.yaml
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - reg-names
>> + - ti,sci
>> + - ti,sci-dev-id
>> + - ti,sci-proc-ids
>> + - resets
>> + - firmware-name
>> + - mboxes
>> + - memory-region
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> +
>> + //Example: J721E SoC
>> + /* DSP Carveout reserved memory nodes */
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + c66_0_dma_memory_region: c66-dma-memory@a6000000 {
>> + compatible = "shared-dma-pool";
>> + reg = <0x00 0xa6000000 0x00 0x100000>;
>> + no-map;
>> + };
>> +
>> + c66_0_memory_region: c66-memory@a6100000 {
>> + compatible = "shared-dma-pool";
>> + reg = <0x00 0xa6100000 0x00 0xf00000>;
>> + no-map;
>> + };
>> + };
>> +
>> + cbass_main: interconnect@100000 {
>> + compatible = "simple-bus";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges = <0x4d 0x80800000 0x4d 0x80800000 0x00 0x00800000>, /* C66_0 */
>> + <0x4d 0x81800000 0x4d 0x81800000 0x00 0x00800000>; /* C66_1 */
>> +
>> + /* J721E C66_0 DSP node */
>> + c66_0: dsp@4d80800000 {
>> + compatible = "ti,j721e-c66-dsp";
>> + reg = <0x4d 0x80800000 0x00 0x00048000>,
>> + <0x4d 0x80e00000 0x00 0x00008000>,
>> + <0x4d 0x80f00000 0x00 0x00008000>;
>> + reg-names = "l2sram", "l1pram", "l1dram";
>> + ti,sci = <&dmsc>;
>> + ti,sci-dev-id = <142>;
>> + ti,sci-proc-ids = <0x03 0xFF>;
>> + resets = <&k3_reset 142 1>;
>> + firmware-name = "j7-c66_0-fw";
>> + memory-region = <&c66_0_dma_memory_region>,
>> + <&c66_0_memory_region>;
>> + mboxes = <&mailbox0_cluster3 &mbox_c66_0>;
>> + };
>> + };
>> --
>> 2.23.0
>>
^ permalink raw reply
* Re: [PATCH v2] video: fbdev: ssd1307fb: Added support to Column offset
From: Andy Shevchenko @ 2020-05-13 17:13 UTC (permalink / raw)
To: Rodrigo Rolim Mendes de Alencar
Cc: linux-fbdev, Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz,
devicetree, Rodrigo Rolim Mendes de Alencar
In-Reply-To: <1589388975-15499-1-git-send-email-alencar.fmce@imbel.gov.br>
On Wed, May 13, 2020 at 7:56 PM Rodrigo Rolim Mendes de Alencar
<455.rodrigo.alencar@gmail.com> wrote:
>
> This patch provides support for displays like VGM128064B0W10,
> which requires a column offset of 2, i.e., its segments starts
> in SEG2 and ends in SEG129.
Also, include Rob as well into Cc.
...
> + if (device_property_read_u32(node, "solomon,col-offset", &par->col_offset))
> + par->col_offset = 0;
> +
> if (device_property_read_u32(dev, "solomon,com-offset", &par->com_offset))
> par->com_offset = 0;
Have you ever compile it?
--
With Best Regards,
Andy Shevchenko
^ 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