* [PATCH v2 12/13] dt-bindings: add binding for px30 power domains
From: Elaine Zhang @ 2018-05-14 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
From: Finley Xiao <finley.xiao@rock-chips.com>
Add binding documentation for the power domains
found on Rockchip PX30 SoCs.
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
index affe36dcfa17..5d49d0a2ff29 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -5,6 +5,7 @@ powered up/down by software based on different application scenes to save power.
Required properties for power domain controller:
- compatible: Should be one of the following.
+ "rockchip,px30-power-controller" - for PX30 SoCs.
"rockchip,rk3036-power-controller" - for RK3036 SoCs.
"rockchip,rk3128-power-controller" - for RK3128 SoCs.
"rockchip,rk3228-power-controller" - for RK3228 SoCs.
@@ -20,6 +21,7 @@ Required properties for power domain controller:
Required properties for power domain sub nodes:
- reg: index of the power domain, should use macros in:
+ "include/dt-bindings/power/px30-power.h" - for PX30 type power domain.
"include/dt-bindings/power/rk3036-power.h" - for RK3036 type power domain.
"include/dt-bindings/power/rk3128-power.h" - for RK3128 type power domain.
"include/dt-bindings/power/rk3228-power.h" - for RK3228 type power domain.
@@ -99,6 +101,7 @@ Node of a device using power domains must have a power-domains property,
containing a phandle to the power device node and an index specifying which
power domain to use.
The index should use macros in:
+ "include/dt-bindings/power/px30-power.h" - for px30 type power domain.
"include/dt-bindings/power/rk3036-power.h" - for rk3036 type power domain.
"include/dt-bindings/power/rk3128-power.h" - for rk3128 type power domain.
"include/dt-bindings/power/rk3128-power.h" - for rk3228 type power domain.
--
1.9.1
^ permalink raw reply related
* [PATCH v2 11/13] dt-bindings: power: add PX30 SoCs header for power-domain
From: Elaine Zhang @ 2018-05-14 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
From: Finley Xiao <finley.xiao@rock-chips.com>
According to a description from TRM, add all the power domains.
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
include/dt-bindings/power/px30-power.h | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
create mode 100644 include/dt-bindings/power/px30-power.h
diff --git a/include/dt-bindings/power/px30-power.h b/include/dt-bindings/power/px30-power.h
new file mode 100644
index 000000000000..4ed482e80950
--- /dev/null
+++ b/include/dt-bindings/power/px30-power.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#ifndef __DT_BINDINGS_POWER_PX30_POWER_H__
+#define __DT_BINDINGS_POWER_PX30_POWER_H__
+
+/* VD_CORE */
+#define PX30_PD_A35_0 0
+#define PX30_PD_A35_1 1
+#define PX30_PD_A35_2 2
+#define PX30_PD_A35_3 3
+#define PX30_PD_SCU 4
+
+/* VD_LOGIC */
+#define PX30_PD_USB 5
+#define PX30_PD_DDR 6
+#define PX30_PD_SDCARD 7
+#define PX30_PD_CRYPTO 8
+#define PX30_PD_GMAC 9
+#define PX30_PD_MMC_NAND 10
+#define PX30_PD_VPU 11
+#define PX30_PD_VO 12
+#define PX30_PD_VI 13
+#define PX30_PD_GPU 14
+
+/* VD_PMU */
+#define PX30_PD_PMU 15
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v2 10/13] soc: rockchip: power-domain: add power domain support for rk3228
From: Elaine Zhang @ 2018-05-14 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
This driver is modified to support RK3228 SoC.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
drivers/soc/rockchip/pm_domains.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 99a2dd8a7801..90dcd5e21ae6 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -20,6 +20,7 @@
#include <linux/mfd/syscon.h>
#include <dt-bindings/power/rk3036-power.h>
#include <dt-bindings/power/rk3128-power.h>
+#include <dt-bindings/power/rk3228-power.h>
#include <dt-bindings/power/rk3288-power.h>
#include <dt-bindings/power/rk3328-power.h>
#include <dt-bindings/power/rk3366-power.h>
@@ -729,6 +730,20 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
[RK3128_PD_GPU] = DOMAIN_RK3288(1, 1, 3, false),
};
+static const struct rockchip_domain_info rk3228_pm_domains[] = {
+ [RK3228_PD_CORE] = DOMAIN_RK3036(0, 0, 16, true),
+ [RK3228_PD_MSCH] = DOMAIN_RK3036(1, 1, 17, true),
+ [RK3228_PD_BUS] = DOMAIN_RK3036(2, 2, 18, true),
+ [RK3228_PD_SYS] = DOMAIN_RK3036(3, 3, 19, true),
+ [RK3228_PD_VIO] = DOMAIN_RK3036(4, 4, 20, false),
+ [RK3228_PD_VOP] = DOMAIN_RK3036(5, 5, 21, false),
+ [RK3228_PD_VPU] = DOMAIN_RK3036(6, 6, 22, false),
+ [RK3228_PD_RKVDEC] = DOMAIN_RK3036(7, 7, 23, false),
+ [RK3228_PD_GPU] = DOMAIN_RK3036(8, 8, 24, false),
+ [RK3228_PD_PERI] = DOMAIN_RK3036(9, 9, 25, true),
+ [RK3228_PD_GMAC] = DOMAIN_RK3036(10, 10, 26, false),
+};
+
static const struct rockchip_domain_info rk3288_pm_domains[] = {
[RK3288_PD_VIO] = DOMAIN_RK3288(7, 7, 4, false),
[RK3288_PD_HEVC] = DOMAIN_RK3288(14, 10, 9, false),
@@ -816,6 +831,15 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
.domain_info = rk3128_pm_domains,
};
+static const struct rockchip_pmu_info rk3228_pmu = {
+ .req_offset = 0x40c,
+ .idle_offset = 0x488,
+ .ack_offset = 0x488,
+
+ .num_domains = ARRAY_SIZE(rk3228_pm_domains),
+ .domain_info = rk3228_pm_domains,
+};
+
static const struct rockchip_pmu_info rk3288_pmu = {
.pwr_offset = 0x08,
.status_offset = 0x0c,
@@ -899,6 +923,10 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
.data = (void *)&rk3128_pmu,
},
{
+ .compatible = "rockchip,rk3228-power-controller",
+ .data = (void *)&rk3228_pmu,
+ },
+ {
.compatible = "rockchip,rk3288-power-controller",
.data = (void *)&rk3288_pmu,
},
--
1.9.1
^ permalink raw reply related
* [PATCH v2 09/13] dt-bindings: add binding for rk3228 power domains
From: Elaine Zhang @ 2018-05-14 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
Add binding documentation for the power domains
found on Rockchip RK3228 SoCs.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
index 9a3f5fd36a80..affe36dcfa17 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -7,6 +7,7 @@ Required properties for power domain controller:
- compatible: Should be one of the following.
"rockchip,rk3036-power-controller" - for RK3036 SoCs.
"rockchip,rk3128-power-controller" - for RK3128 SoCs.
+ "rockchip,rk3228-power-controller" - for RK3228 SoCs.
"rockchip,rk3288-power-controller" - for RK3288 SoCs.
"rockchip,rk3328-power-controller" - for RK3328 SoCs.
"rockchip,rk3366-power-controller" - for RK3366 SoCs.
@@ -21,6 +22,7 @@ Required properties for power domain sub nodes:
- reg: index of the power domain, should use macros in:
"include/dt-bindings/power/rk3036-power.h" - for RK3036 type power domain.
"include/dt-bindings/power/rk3128-power.h" - for RK3128 type power domain.
+ "include/dt-bindings/power/rk3228-power.h" - for RK3228 type power domain.
"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain.
"include/dt-bindings/power/rk3328-power.h" - for RK3328 type power domain.
"include/dt-bindings/power/rk3366-power.h" - for RK3366 type power domain.
@@ -99,6 +101,7 @@ power domain to use.
The index should use macros in:
"include/dt-bindings/power/rk3036-power.h" - for rk3036 type power domain.
"include/dt-bindings/power/rk3128-power.h" - for rk3128 type power domain.
+ "include/dt-bindings/power/rk3128-power.h" - for rk3228 type power domain.
"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain.
"include/dt-bindings/power/rk3328-power.h" - for rk3328 type power domain.
"include/dt-bindings/power/rk3366-power.h" - for rk3366 type power domain.
--
1.9.1
^ permalink raw reply related
* [PATCH v2 08/13] dt-bindings: power: add RK3228 SoCs header for power-domain
From: Elaine Zhang @ 2018-05-14 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
According to a description from TRM, add all the power domains.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
include/dt-bindings/power/rk3228-power.h | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 include/dt-bindings/power/rk3228-power.h
diff --git a/include/dt-bindings/power/rk3228-power.h b/include/dt-bindings/power/rk3228-power.h
new file mode 100644
index 000000000000..fa1264d5a995
--- /dev/null
+++ b/include/dt-bindings/power/rk3228-power.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (c) 2018 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#ifndef __DT_BINDINGS_POWER_RK3228_POWER_H__
+#define __DT_BINDINGS_POWER_RK3228_POWER_H__
+
+/**
+ * RK3228 idle id Summary.
+ */
+
+#define RK3228_PD_CORE 0
+#define RK3228_PD_MSCH 1
+#define RK3228_PD_BUS 2
+#define RK3228_PD_SYS 3
+#define RK3228_PD_VIO 4
+#define RK3228_PD_VOP 5
+#define RK3228_PD_VPU 6
+#define RK3228_PD_RKVDEC 7
+#define RK3228_PD_GPU 8
+#define RK3228_PD_PERI 9
+#define RK3228_PD_GMAC 10
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v2 07/13] soc: rockchip: power-domain: add power domain support for rk3128
From: Elaine Zhang @ 2018-05-14 3:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
This driver is modified to support RK3128 SoC.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
drivers/soc/rockchip/pm_domains.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 01d4ba26a054..99a2dd8a7801 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -19,6 +19,7 @@
#include <linux/regmap.h>
#include <linux/mfd/syscon.h>
#include <dt-bindings/power/rk3036-power.h>
+#include <dt-bindings/power/rk3128-power.h>
#include <dt-bindings/power/rk3288-power.h>
#include <dt-bindings/power/rk3328-power.h>
#include <dt-bindings/power/rk3366-power.h>
@@ -720,6 +721,14 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
[RK3036_PD_SYS] = DOMAIN_RK3036(8, 22, 29, false),
};
+static const struct rockchip_domain_info rk3128_pm_domains[] = {
+ [RK3128_PD_CORE] = DOMAIN_RK3288(0, 0, 4, false),
+ [RK3128_PD_MSCH] = DOMAIN_RK3288(-1, -1, 6, true),
+ [RK3128_PD_VIO] = DOMAIN_RK3288(3, 3, 2, false),
+ [RK3128_PD_VIDEO] = DOMAIN_RK3288(2, 2, 1, false),
+ [RK3128_PD_GPU] = DOMAIN_RK3288(1, 1, 3, false),
+};
+
static const struct rockchip_domain_info rk3288_pm_domains[] = {
[RK3288_PD_VIO] = DOMAIN_RK3288(7, 7, 4, false),
[RK3288_PD_HEVC] = DOMAIN_RK3288(14, 10, 9, false),
@@ -796,6 +805,17 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
.domain_info = rk3036_pm_domains,
};
+static const struct rockchip_pmu_info rk3128_pmu = {
+ .pwr_offset = 0x04,
+ .status_offset = 0x08,
+ .req_offset = 0x0c,
+ .idle_offset = 0x10,
+ .ack_offset = 0x10,
+
+ .num_domains = ARRAY_SIZE(rk3128_pm_domains),
+ .domain_info = rk3128_pm_domains,
+};
+
static const struct rockchip_pmu_info rk3288_pmu = {
.pwr_offset = 0x08,
.status_offset = 0x0c,
@@ -875,6 +895,10 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
.data = (void *)&rk3036_pmu,
},
{
+ .compatible = "rockchip,rk3128-power-controller",
+ .data = (void *)&rk3128_pmu,
+ },
+ {
.compatible = "rockchip,rk3288-power-controller",
.data = (void *)&rk3288_pmu,
},
--
1.9.1
^ permalink raw reply related
* [PATCH v2 06/13] dt-bindings: add binding for rk3128 power domains
From: Elaine Zhang @ 2018-05-14 3:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
Add binding documentation for the power domains
found on Rockchip RK3128 SoCs.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
index 79924ee9ae86..9a3f5fd36a80 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -6,6 +6,7 @@ powered up/down by software based on different application scenes to save power.
Required properties for power domain controller:
- compatible: Should be one of the following.
"rockchip,rk3036-power-controller" - for RK3036 SoCs.
+ "rockchip,rk3128-power-controller" - for RK3128 SoCs.
"rockchip,rk3288-power-controller" - for RK3288 SoCs.
"rockchip,rk3328-power-controller" - for RK3328 SoCs.
"rockchip,rk3366-power-controller" - for RK3366 SoCs.
@@ -19,6 +20,7 @@ Required properties for power domain controller:
Required properties for power domain sub nodes:
- reg: index of the power domain, should use macros in:
"include/dt-bindings/power/rk3036-power.h" - for RK3036 type power domain.
+ "include/dt-bindings/power/rk3128-power.h" - for RK3128 type power domain.
"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain.
"include/dt-bindings/power/rk3328-power.h" - for RK3328 type power domain.
"include/dt-bindings/power/rk3366-power.h" - for RK3366 type power domain.
@@ -96,6 +98,7 @@ containing a phandle to the power device node and an index specifying which
power domain to use.
The index should use macros in:
"include/dt-bindings/power/rk3036-power.h" - for rk3036 type power domain.
+ "include/dt-bindings/power/rk3128-power.h" - for rk3128 type power domain.
"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain.
"include/dt-bindings/power/rk3328-power.h" - for rk3328 type power domain.
"include/dt-bindings/power/rk3366-power.h" - for rk3366 type power domain.
--
1.9.1
^ permalink raw reply related
* [PATCH v2 05/13] dt-bindings: power: add RK3128 SoCs header for power-domain
From: Elaine Zhang @ 2018-05-14 3:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
According to a description from TRM, add all the power domains.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
include/dt-bindings/power/rk3128-power.h | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 include/dt-bindings/power/rk3128-power.h
diff --git a/include/dt-bindings/power/rk3128-power.h b/include/dt-bindings/power/rk3128-power.h
new file mode 100644
index 000000000000..26aef519cd94
--- /dev/null
+++ b/include/dt-bindings/power/rk3128-power.h
@@ -0,0 +1,28 @@
+/*
+ * Copyright (c) 2017 Rockchip Electronics Co. Ltd.
+ * Author: Elaine Zhang <zhangqing@rock-chips.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __DT_BINDINGS_POWER_RK3128_POWER_H__
+#define __DT_BINDINGS_POWER_RK3128_POWER_H__
+
+/* VD_CORE */
+#define RK3128_PD_CORE 0
+
+/* VD_LOGIC */
+#define RK3128_PD_VIO 1
+#define RK3128_PD_VIDEO 2
+#define RK3128_PD_GPU 3
+#define RK3128_PD_MSCH 4
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v2 04/13] soc: rockchip: power-domain: Fix wrong value when power up pd
From: Elaine Zhang @ 2018-05-14 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
From: Finley Xiao <finley.xiao@rock-chips.com>
Solve the pd could only ever turn off but never turn them on again,
If the pd registers have the writemask bits.
Fix up the code error for commit:
commit 79bb17ce8edb3141339b5882e372d0ec7346217c
Author: Elaine Zhang <zhangqing@rock-chips.com>
Date: Fri Dec 23 11:47:52 2016 +0800
soc: rockchip: power-domain: Support domain control in hiword-registers
New Rockchips SoCs may have their power-domain control in registers
using a writemask-based access scheme (upper 16bit being the write
mask). So add a DOMAIN_M type and handle this case accordingly.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
drivers/soc/rockchip/pm_domains.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index ebd7c41898c0..01d4ba26a054 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -264,7 +264,7 @@ static void rockchip_do_pmu_set_power_domain(struct rockchip_pm_domain *pd,
return;
else if (pd->info->pwr_w_mask)
regmap_write(pmu->regmap, pmu->info->pwr_offset,
- on ? pd->info->pwr_mask :
+ on ? pd->info->pwr_w_mask :
(pd->info->pwr_mask | pd->info->pwr_w_mask));
else
regmap_update_bits(pmu->regmap, pmu->info->pwr_offset,
--
1.9.1
^ permalink raw reply related
* [PATCH v2 03/13] Soc: rockchip: power-domain: add power domain support for rk3036
From: Elaine Zhang @ 2018-05-14 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
From: Caesar Wang <wxt@rock-chips.com>
This driver is modified to support RK3036 SoC.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
drivers/soc/rockchip/pm_domains.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 53efc386b1ad..ebd7c41898c0 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -18,6 +18,7 @@
#include <linux/clk.h>
#include <linux/regmap.h>
#include <linux/mfd/syscon.h>
+#include <dt-bindings/power/rk3036-power.h>
#include <dt-bindings/power/rk3288-power.h>
#include <dt-bindings/power/rk3328-power.h>
#include <dt-bindings/power/rk3366-power.h>
@@ -102,6 +103,14 @@ struct rockchip_pmu {
.ack_mask = (ack >= 0) ? BIT(ack) : 0, \
.active_wakeup = wakeup, \
}
+#define DOMAIN_RK3036(req, ack, idle, wakeup) \
+{ \
+ .req_mask = (req >= 0) ? BIT(req) : 0, \
+ .req_w_mask = (req >= 0) ? BIT(req + 16) : 0, \
+ .ack_mask = (ack >= 0) ? BIT(ack) : 0, \
+ .idle_mask = (idle >= 0) ? BIT(idle) : 0, \
+ .active_wakeup = wakeup, \
+}
#define DOMAIN_RK3288(pwr, status, req, wakeup) \
DOMAIN(pwr, status, req, req, (req) + 16, wakeup)
@@ -701,6 +710,16 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
return error;
}
+static const struct rockchip_domain_info rk3036_pm_domains[] = {
+ [RK3036_PD_MSCH] = DOMAIN_RK3036(14, 23, 30, true),
+ [RK3036_PD_CORE] = DOMAIN_RK3036(13, 17, 24, false),
+ [RK3036_PD_PERI] = DOMAIN_RK3036(12, 18, 25, false),
+ [RK3036_PD_VIO] = DOMAIN_RK3036(11, 19, 26, false),
+ [RK3036_PD_VPU] = DOMAIN_RK3036(10, 20, 27, false),
+ [RK3036_PD_GPU] = DOMAIN_RK3036(9, 21, 28, false),
+ [RK3036_PD_SYS] = DOMAIN_RK3036(8, 22, 29, false),
+};
+
static const struct rockchip_domain_info rk3288_pm_domains[] = {
[RK3288_PD_VIO] = DOMAIN_RK3288(7, 7, 4, false),
[RK3288_PD_HEVC] = DOMAIN_RK3288(14, 10, 9, false),
@@ -768,6 +787,15 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
[RK3399_PD_SDIOAUDIO] = DOMAIN_RK3399(31, 31, 29, true),
};
+static const struct rockchip_pmu_info rk3036_pmu = {
+ .req_offset = 0x148,
+ .idle_offset = 0x14c,
+ .ack_offset = 0x14c,
+
+ .num_domains = ARRAY_SIZE(rk3036_pm_domains),
+ .domain_info = rk3036_pm_domains,
+};
+
static const struct rockchip_pmu_info rk3288_pmu = {
.pwr_offset = 0x08,
.status_offset = 0x0c,
@@ -843,6 +871,10 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
static const struct of_device_id rockchip_pm_domain_dt_match[] = {
{
+ .compatible = "rockchip,rk3036-power-controller",
+ .data = (void *)&rk3036_pmu,
+ },
+ {
.compatible = "rockchip,rk3288-power-controller",
.data = (void *)&rk3288_pmu,
},
--
1.9.1
^ permalink raw reply related
* [PATCH v2 02/13] dt-bindings: add binding for rk3036 power domains
From: Elaine Zhang @ 2018-05-14 3:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
From: Caesar Wang <wxt@rock-chips.com>
Add binding documentation for the power domains
found on Rockchip RK3036 SoCs.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
index 301d2a9bc1b8..79924ee9ae86 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -5,6 +5,7 @@ powered up/down by software based on different application scenes to save power.
Required properties for power domain controller:
- compatible: Should be one of the following.
+ "rockchip,rk3036-power-controller" - for RK3036 SoCs.
"rockchip,rk3288-power-controller" - for RK3288 SoCs.
"rockchip,rk3328-power-controller" - for RK3328 SoCs.
"rockchip,rk3366-power-controller" - for RK3366 SoCs.
@@ -17,6 +18,7 @@ Required properties for power domain controller:
Required properties for power domain sub nodes:
- reg: index of the power domain, should use macros in:
+ "include/dt-bindings/power/rk3036-power.h" - for RK3036 type power domain.
"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain.
"include/dt-bindings/power/rk3328-power.h" - for RK3328 type power domain.
"include/dt-bindings/power/rk3366-power.h" - for RK3366 type power domain.
@@ -93,6 +95,7 @@ Node of a device using power domains must have a power-domains property,
containing a phandle to the power device node and an index specifying which
power domain to use.
The index should use macros in:
+ "include/dt-bindings/power/rk3036-power.h" - for rk3036 type power domain.
"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain.
"include/dt-bindings/power/rk3328-power.h" - for rk3328 type power domain.
"include/dt-bindings/power/rk3366-power.h" - for rk3366 type power domain.
--
1.9.1
^ permalink raw reply related
* [PATCH v2 01/13] dt-bindings: power: add RK3036 SoCs header for power-domain
From: Elaine Zhang @ 2018-05-14 3:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
From: Caesar Wang <wxt@rock-chips.com>
According to a description from TRM, add all the power domains.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
include/dt-bindings/power/rk3036-power.h | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 include/dt-bindings/power/rk3036-power.h
diff --git a/include/dt-bindings/power/rk3036-power.h b/include/dt-bindings/power/rk3036-power.h
new file mode 100644
index 000000000000..59e09f1c5af7
--- /dev/null
+++ b/include/dt-bindings/power/rk3036-power.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (c) 2017 Rockchip Electronics Co. Ltd.
+ * Author: Caesar Wang <wxt@rock-chips.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __DT_BINDINGS_POWER_RK3036_POWER_H__
+#define __DT_BINDINGS_POWER_RK3036_POWER_H__
+
+#define RK3036_PD_MSCH 0
+#define RK3036_PD_CORE 1
+#define RK3036_PD_PERI 2
+#define RK3036_PD_VIO 3
+#define RK3036_PD_VPU 4
+#define RK3036_PD_GPU 5
+#define RK3036_PD_SYS 6
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v2 00/13] add power domain support for Rockchip Socs
From: Elaine Zhang @ 2018-05-14 3:27 UTC (permalink / raw)
To: linux-arm-kernel
add power domain support for RK3036/RK3128/RK3228/PX30 Soc.
fix up the wrong value when set power domain up.
Change in V2:
Fix up the commit message description and Assign author.
Caesar Wang (3):
dt-bindings: power: add RK3036 SoCs header for power-domain
dt-bindings: add binding for rk3036 power domains
Soc: rockchip: power-domain: add power domain support for rk3036
Elaine Zhang (6):
dt-bindings: power: add RK3128 SoCs header for power-domain
dt-bindings: add binding for rk3128 power domains
soc: rockchip: power-domain: add power domain support for rk3128
dt-bindings: power: add RK3228 SoCs header for power-domain
dt-bindings: add binding for rk3228 power domains
soc: rockchip: power-domain: add power domain support for rk3228
Finley Xiao (4):
soc: rockchip: power-domain: Fix wrong value when power up pd
dt-bindings: power: add PX30 SoCs header for power-domain
dt-bindings: add binding for px30 power domains
soc: rockchip: power-domain: add power domain support for px30
.../bindings/soc/rockchip/power_domain.txt | 12 +++
drivers/soc/rockchip/pm_domains.c | 116 ++++++++++++++++++++-
include/dt-bindings/power/px30-power.h | 32 ++++++
include/dt-bindings/power/rk3036-power.h | 27 +++++
include/dt-bindings/power/rk3128-power.h | 28 +++++
include/dt-bindings/power/rk3228-power.h | 26 +++++
6 files changed, 240 insertions(+), 1 deletion(-)
create mode 100644 include/dt-bindings/power/px30-power.h
create mode 100644 include/dt-bindings/power/rk3036-power.h
create mode 100644 include/dt-bindings/power/rk3128-power.h
create mode 100644 include/dt-bindings/power/rk3228-power.h
--
1.9.1
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Laurent Pinchart @ 2018-05-14 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513125755.GQ18974@bigcity.dyn.berto.se>
Hello,
On Sunday, 13 May 2018 15:57:55 EEST Niklas S?derlund wrote:
> On 2018-05-11 12:00:02 +0200, Jacopo Mondi wrote:
> > Describe HDMI input connected to VIN4 interface for R-Car D3 Draak
> > development board.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> >
> > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 68 +++++++++++++++++++++
> > 1 file changed, 68 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts index d03f194..e0ce462
> > 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > @@ -59,6 +59,17 @@
> >
> > };
> >
> > };
> >
> > + hdmi-in {
> > + compatible = "hdmi-connector";
> > + type = "a";
> > +
> > + port {
> > + hdmi_con_in: endpoint {
> > + remote-endpoint = <&adv7612_in>;
> > + };
> > + };
> > + };
> > +
> >
> > memory at 48000000 {
> >
> > device_type = "memory";
> > /* first 128MB is reserved for secure area. */
> >
> > @@ -142,6 +153,11 @@
> >
> > groups = "usb0";
> > function = "usb0";
> >
> > };
> >
> > +
> > + vin4_pins: vin4 {
> > + groups = "vin4_data24", "vin4_sync", "vin4_clk", "vin4_clkenb";
> > + function = "vin4";
> > + };
> >
> > };
> >
> > &i2c0 {
> >
> > @@ -154,6 +170,35 @@
> >
> > reg = <0x50>;
> > pagesize = <8>;
> >
> > };
> >
> > +
> > + hdmi-decoder at 4c {
> > + compatible = "adi,adv7612";
> > + reg = <0x4c>;
> > + default-input = <0>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port at 0 {
> > + reg = <0>;
> > + adv7612_in: endpoint {
> > + remote-endpoint = <&hdmi_con_in>;
> > + };
> > + };
> > +
> > + port at 2 {
> > + reg = <2>;
> > + adv7612_out: endpoint {
> > + pclk-sample = <0>;
> > + hsync-active = <0>;
> > + vsync-active = <0>;
>
> This differs from the Gen2 DT bindings which is a very similar hardware
> setup using the same components. Defining these properties will make the
> bus marked as V4L2_MBUS_PARALLEL instead of V4L2_MBUS_BT656.
>
> This will change how the hardware is configured for capture if the media
> bus is in a UYVY format, see VNMC_INF register in rvin_setup(). Maybe
> this it not an issue here but still I'm curious to why this differ
> between Gen2 and Gen3 :-)
>
> > +
> > + remote-endpoint = <&vin4_in>;
> > + };
> > + };
> > + };
> > + };
> >
> > };
> >
> > &i2c1 {
> >
> > @@ -246,3 +291,26 @@
> >
> > timeout-sec = <60>;
> > status = "okay";
> >
> > };
> >
> > +
> > +&vin4 {
> > + pinctrl-0 = <&vin4_pins>;
> > + pinctrl-names = "default";
> > +
> > + status = "okay";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port at 0 {
> > + reg = <0>;
> > +
> > + vin4_in: endpoint {
> > + hsync-active = <0>;
> > + vsync-active = <0>;
>
> Comparing this to the Gen2 bindings some properties are missing,
>
> bus-width = <24>;
> pclk-sample = <1>;
> data-active = <1>;
>
> This is not a big deal as the VIN driver don't use these properties so
> no functional change should come of this but still a difference.
I think the VIN DT bindings should be updated to explicitly list the endpoint
properties that are mandatory, optional, or not allowed.
> Over all I'm happy with this change but before I add my tag I would like
> to understand why it differs from the Gen2 configuration for the adv7612
> properties.
>
> Also on a side not it is possible with hardware switches on the board
> switch the VIN4 source to a completely different pipeline CVBS connector
> -> adv7180 -> VIN4. But I think it's best we keep the HDMI as default as
> this seems to be how the boards are shipped. But maybe mentioning this
> in the commit message would not hurt if you end-up resending the patch.
>
> > +
> > + remote-endpoint = <&adv7612_out>;
> > + };
> > + };
> > + };
> > +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 2/3] arm64: dts: renesas: r8a77995: Add VIN4
From: Laurent Pinchart @ 2018-05-14 2:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511134516.omsv25i2wi4cxypc@verge.net.au>
Hello,
On Friday, 11 May 2018 16:45:16 EEST Simon Horman wrote:
> On Fri, May 11, 2018 at 01:25:23PM +0200, Niklas S?derlund wrote:
> > Hi Jacopo,
> >
> > Thanks for your work.
> >
> > On 2018-05-11 12:00:01 +0200, Jacopo Mondi wrote:
> > > Describe VIN4 interface for R-Car D3 R8A77995 SoC.
> > >
> > > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> >
> > Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
> >
> >> ---
> >>
> >> arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 +++++++++++
> >> 1 file changed, 11 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> >> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index 82aed7e..bdf7017
> >> 100644
> >> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> >> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> >> @@ -783,6 +783,17 @@
> >> };
> >> };
> >> };
> >> +
> >> + vin4: video at e6ef4000 {
> >> + compatible = "renesas,vin-r8a77995";
> >> + reg = <0 0xe6ef4000 0 0x1000>;
> >> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> >> + clocks = <&cpg CPG_MOD 807>;
> >> + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> >> + resets = <&cpg 807>;
> >> + renesas,id = <4>;
> >> + status = "disabled";
> >> + };
> >> };
>
> Thanks, I have moved the new node to preserve sorting of nodes by bus
> address and applied the result. It is as follows:
>
> From: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Subject: [PATCH] arm64: dts: renesas: r8a77995: Add VIN4
>
> Describe VIN4 interface for R-Car D3 R8A77995 SoC.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
> [simon: sorted node by bus address]
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index
> ba98865b0c9b..2506f46293e8 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -610,6 +610,17 @@
> status = "disabled";
> };
>
> + vin4: video at e6ef4000 {
> + compatible = "renesas,vin-r8a77995";
> + reg = <0 0xe6ef4000 0 0x1000>;
> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 807>;
> + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> + resets = <&cpg 807>;
> + renesas,id = <4>;
> + status = "disabled";
> + };
> +
> ohci0: usb at ee080000 {
> compatible = "generic-ohci";
> reg = <0 0xee080000 0 0x100>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 1/3] dt-bindings: media: rcar-vin: Add R8A77995 support
From: Laurent Pinchart @ 2018-05-14 2:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526032802-14376-2-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thank you for the patch.
On Friday, 11 May 2018 13:00:00 EEST Jacopo Mondi wrote:
> Add compatible string for R-Car D3 R8A7795 to list of SoCs supported by
> rcar-vin driver.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
> b/Documentation/devicetree/bindings/media/rcar_vin.txt index
> a19517e1..5c6f2a7 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -22,6 +22,7 @@ on Gen3 platforms to a CSI-2 receiver.
> - "renesas,vin-r8a7795" for the R8A7795 device
> - "renesas,vin-r8a7796" for the R8A7796 device
> - "renesas,vin-r8a77970" for the R8A77970 device
> + - "renesas,vin-r8a77995" for the R8A77995 device
> - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
> device.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] KVM: arm/arm64: fix unaligned hva start and end in handle_hva_to_gpa
From: Jia He @ 2018-05-14 2:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0f134188-12d5-7184-3fbd-0ec8204cf649@arm.com>
On 5/11/2018 9:39 PM, Suzuki K Poulose Wrote:
> Marc
>
> Thanks for looping me in. Comments below.
>
>
> On 03/05/18 03:02, Jia He wrote:
>> Hi Marc
>>
>> Thanks for the review
>>
>>
>> On 5/2/2018 10:26 PM, Marc Zyngier Wrote:
>>> [+ Suzuki]
>>>
>>> On 02/05/18 08:08, Jia He wrote:
>>>> From: Jia He <jia.he@hxt-semitech.com>
>>>>
>>>> In our armv8a server (QDF2400), I noticed a WARN_ON as follows:
>>>>
>>>> [? 800.202850] WARNING: CPU: 33 PID: 255 at arch/arm64/kvm/../../../virt/kvm/arm/mmu.c:1670 kvm_age_hva_handler+0xcc/0xd4
>>> Which kernel version is that? I don't have a WARN_ON() at this line in
>>> 4.17. Do you have a reproducer?
>> My running kernel version is v4.14-15, but I can reproduced it in 4.17 (start 20 guests and run memhog in the host)
>> In 4.17, the warn_on is at
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/virt/kvm/arm/mmu.c#n1826
>>>> [? 800.213535] Modules linked in: vhost_net vhost tap xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm vfat fat iw_cm mlx5_ib ib_core dm_mirror dm_region_hash dm_log dm_mod crc32_ce ipmi_ssif sg nfsd
>>>> [? 800.284115]? auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c mlx5_core ixgbe mlxfw devlink mdio ahci_platform libahci_platform qcom_emac libahci hdma hdma_mgmt i2c_qup
>>>> [? 800.300382] CPU: 33 PID: 255 Comm: khugepaged Tainted: G??????? W?????? 4.14.36+ #6
>>>> [? 800.308030] Hardware name: <snip for confidential issues>
>>> Well, that's QDF2400, right? ;-)
>> yes, exactly :)
>>>> [? 800.318717] task: ffff8017c949c000 task.stack: ffff8017c9498000
>>>> [? 800.324629] PC is at kvm_age_hva_handler+0xcc/0xd4
>>>> [? 800.329412] LR is at handle_hva_to_gpa+0xec/0x15c
>>>> [? 800.334109] pc : [<ffff0000080b4f2c>] lr : [<ffff0000080b4838>] pstate: 20400145
>>>> [? 800.341496] sp : ffff8017c949b260
>>>> [? 800.344804] x29: ffff8017c949b260 x28: ffff801663e25008
>>>> [? 800.350110] x27: 0000000000020000 x26: 00000001fb1a0000
>>>> [? 800.355416] x25: 0000ffff605b0200 x24: 0000ffff605a0200
>>>> [? 800.360722] x23: 0000000000000000 x22: 000000000000ffff
>>>> [? 800.366028] x21: 00000001fb1a0000 x20: ffff8017c085a000
>>>> [? 800.371334] x19: ffff801663e20008 x18: 0000000000000000
>>>> [? 800.376641] x17: 0000000000000000 x16: 0000000000000000
>>>> [? 800.381947] x15: 0000000000000000 x14: 3d646e655f617668
>>>> [? 800.387254] x13: 2c30303230623530 x12: 36666666663d646e
>>>> [? 800.392560] x11: 652c303032306135 x10: 3036666666663d74
>>>> [? 800.397867] x9 : 0000000000003796 x8 : 655f6e66672c3030
>>>> [? 800.403173] x7 : ffff00000859434c x6 : ffff8017f9c30cb8
>>>> [? 800.408479] x5 : ffff8017f9c30cb8 x4 : ffff0000080b4e60
>>>> [? 800.413786] x3 : 0000000000000000 x2 : 0000000000020000
>>>> [? 800.419092] x1 : 00000001fb1a0000 x0 : 0000000020000000
>>>> [? 800.424398] Call trace:
>>>> [? 800.426838] Exception stack(0xffff8017c949b120 to 0xffff8017c949b260)
>>>> [? 800.433272] b120: 0000000020000000 00000001fb1a0000 0000000000020000 0000000000000000
>>>> [? 800.441095] b140: ffff0000080b4e60 ffff8017f9c30cb8 ffff8017f9c30cb8 ffff00000859434c
>>>> [? 800.448918] b160: 655f6e66672c3030 0000000000003796 3036666666663d74 652c303032306135
>>>> [? 800.456740] b180: 36666666663d646e 2c30303230623530 3d646e655f617668 0000000000000000
>>>> [? 800.464563] b1a0: 0000000000000000 0000000000000000 0000000000000000 ffff801663e20008
>>>> [? 800.472385] b1c0: ffff8017c085a000 00000001fb1a0000 000000000000ffff 0000000000000000
>>>> [? 800.480208] b1e0: 0000ffff605a0200 0000ffff605b0200 00000001fb1a0000 0000000000020000
>>>> [? 800.488030] b200: ffff801663e25008 ffff8017c949b260 ffff0000080b4838 ffff8017c949b260
>>>> [? 800.495853] b220: ffff0000080b4f2c 0000000020400145 0000000000000001 ffff8017c949b2a0
>>>> [? 800.503676] b240: ffffffffffffffff ffff8017c949b260 ffff8017c949b260 ffff0000080b4f2c
>>>> [? 800.511498] [<ffff0000080b4f2c>] kvm_age_hva_handler+0xcc/0xd4
>>>> [? 800.517324] [<ffff0000080b4838>] handle_hva_to_gpa+0xec/0x15c
>>>> [? 800.523063] [<ffff0000080b6c5c>] kvm_age_hva+0x5c/0xcc
>>>> [? 800.528194] [<ffff0000080a7c3c>] kvm_mmu_notifier_clear_flush_young+0x54/0x90
>>>> [? 800.535324] [<ffff00000827a0e8>] __mmu_notifier_clear_flush_young+0x6c/0xa8
>>>> [? 800.542279] [<ffff00000825a644>] page_referenced_one+0x1e0/0x1fc
>>>> [? 800.548279] [<ffff00000827e8f8>] rmap_walk_ksm+0x124/0x1a0
>>>> [? 800.553759] [<ffff00000825c974>] rmap_walk+0x94/0x98
>>>> [? 800.558717] [<ffff00000825ca98>] page_referenced+0x120/0x180
>>>> [? 800.564369] [<ffff000008228c58>] shrink_active_list+0x218/0x4a4
>>>> [? 800.570281] [<ffff000008229470>] shrink_node_memcg+0x58c/0x6fc
>>>> [? 800.576107] [<ffff0000082296c4>] shrink_node+0xe4/0x328
>>>> [? 800.581325] [<ffff000008229c9c>] do_try_to_free_pages+0xe4/0x3b8
>>>> [? 800.587324] [<ffff00000822a094>] try_to_free_pages+0x124/0x234
>>>> [? 800.593150] [<ffff000008216aa0>] __alloc_pages_nodemask+0x564/0xf7c
>>>> [? 800.599412] [<ffff000008292814>] khugepaged_alloc_page+0x38/0xb8
>>>> [? 800.605411] [<ffff0000082933bc>] collapse_huge_page+0x74/0xd70
>>>> [? 800.611238] [<ffff00000829470c>] khugepaged_scan_mm_slot+0x654/0xa98
>>>> [? 800.617585] [<ffff000008294e0c>] khugepaged+0x2bc/0x49c
>>>> [? 800.622803] [<ffff0000080ffb70>] kthread+0x124/0x150
>>>> [? 800.627762] [<ffff0000080849f0>] ret_from_fork+0x10/0x1c
>>>> [? 800.633066] ---[ end trace 944c130b5252fb01 ]---
>>>> -------------------------------------------------------------------------
>>>>
>>>> The root cause might be: we can't guarantee that the parameter start and end
>>>> in handle_hva_to_gpa is PAGE_SIZE aligned, let alone hva_start and hva_end.
>>> So why not aligning them the first place?
>> at the first place of handle_hva_to_gpa()?
>> but boundary check is needed in each loop of kvm_for_each_memslot. Am I missing anything here?
>
>>>> This bug is introduced by commit 056aad67f836 ("kvm: arm/arm64: Rework gpa
>>>> callback handlers")
>>>>
>>>> It fixes the bug by use pfn size converted.
>>>>
>>>> Fixes: 056aad67f836 ("kvm: arm/arm64: Rework gpa callback handlers")
>>>>
>>>> Signed-off-by: jia.he at hxt-semitech.com
>>>> Signed-off-by: li.zhang at hxt-semitech.com
>>>> ---
>>>> ? virt/kvm/arm/mmu.c | 10 ++++++----
>>>> ? 1 file changed, 6 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>>>> index 7f6a944..9dd7ae4 100644
>>>> --- a/virt/kvm/arm/mmu.c
>>>> +++ b/virt/kvm/arm/mmu.c
>>>> @@ -1744,7 +1744,7 @@ static int handle_hva_to_gpa(struct kvm *kvm,
>>>> ????? /* we only care about the pages that the guest sees */
>>>> ????? kvm_for_each_memslot(memslot, slots) {
>>>> ????????? unsigned long hva_start, hva_end;
>>>> -??????? gfn_t gpa;
>>>> +??????? gpa_t gpa, gpa_end;
>>>> ????????? hva_start = max(start, memslot->userspace_addr);
>>>> ????????? hva_end = min(end, memslot->userspace_addr +
>>>> @@ -1753,7 +1753,9 @@ static int handle_hva_to_gpa(struct kvm *kvm,
>>>> ????????????? continue;
>>>> ????????? gpa = hva_to_gfn_memslot(hva_start, memslot) << PAGE_SHIFT;
>>>> -??????? ret |= handler(kvm, gpa, (u64)(hva_end - hva_start), data);
>>>> +??????? gpa_end = hva_to_gfn_memslot(hva_end + PAGE_SIZE - 1, memslot)
>>>> +???????????????????????????? << PAGE_SHIFT;
>>>> +??????? ret |= handler(kvm, gpa, (u64)(gpa_end - gpa), data);
>>> But we're looking for the mapping in the same memslot, so the distance
>>> between hva and hva_end is the same as the one between gpa and gpa_end
>>> if you didn't align it.
>> maybe not, sometimes hva_end-hva != gpa_end-gpa
>> start=fffdc37f0200,hva_start=fffdc37f0200,end=fffdc3800200,hva_end=fffdc3800000,gpa=3ff0000,gfn_end=4000000
>>
>> but sometimes it is:
>> start=ffff60590200,hva_start=ffff60590200,end=ffff605a0200,hva_end=ffff605a0200,gpa=1fb190000,gfn_end=1fb1b0000
>>
>> IMO, the unalignment is caused by the ksm stable page flag STABLE_FLAG. I will
>> propose another ksm patch to fix it?
>> But from handle_hva_to_gpa's point of view, arm kvm needs to void the followup
>> exception, just like what powerpc andx86 have done.
>
>
> As far as I can see this is triggered by someone (in this page_referenced_one via ksm?)
> triggering a clear_flush_young for a page, with a non-aligned page address.
>
> If you look at the code path, the __mmu_notifier_clear_flush_young is invoked
> via 2 code paths with the "given" address.
>
> ptep_clear_flush_young_notify(), in which case the end is set to + PAGE_SIZE
> pmdp_clear_flush_young_notify(), in which case the end is set to + PMD_SIZE
>
> We were supposed to only clear_flush_young for *the page* containing
> address (start), but we do a clear_flush_young for the next page
> as well, which (I think) is not something intended. So to me, it looks like, either
> page_referenced_one() or its caller must align the address to the PAGE_SIZE
> or PMD_SIZE depending on what it really wants to do, to avoid touching
> the adjacent entries (page or block pages).
>
> Suzuki
Suzuki, thanks for the comments.
I proposed another ksm patch https://lkml.org/lkml/2018/5/3/1042
The root cause is ksm will add some extra flags to indicate that the page
is in/not_in the stable tree. This makes address not be aligned with PAGE_SIZE.
From arm kvm mmu point of view, do you think handle_hva_to_gpa still need to handle
the unalignment case?
IMO, the PAGE_SIZE alignment is still needed because we should not let the bottom function
kvm_age_hva_handler to handle the exception. Please refer to the implementation in X86 and
powerpc kvm_handle_hva_range(). They both aligned the hva with hva_to_gfn_memslot.
Cheers,
Jia
>>> So why not align both start and end and skip the double lookup?
>>>
>>>> ????? }
>>>> ????? return ret;
>>>> @@ -1823,7 +1825,7 @@ static int kvm_age_hva_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *data)
>>>> ????? pmd_t *pmd;
>>>> ????? pte_t *pte;
>>>> -??? WARN_ON(size != PAGE_SIZE && size != PMD_SIZE);
>>>> +??? WARN_ON((size & ~PAGE_MASK) != 0);
>>>> ????? pmd = stage2_get_pmd(kvm, NULL, gpa);
>>>> ????? if (!pmd || pmd_none(*pmd))??? /* Nothing there */
>>>> ????????? return 0;
>>>> @@ -1843,7 +1845,7 @@ static int kvm_test_age_hva_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *
>>>> ????? pmd_t *pmd;
>>>> ????? pte_t *pte;
>>>> -??? WARN_ON(size != PAGE_SIZE && size != PMD_SIZE);
>>>> +??? WARN_ON((size & ~PAGE_MASK) != 0);
>>>> ????? pmd = stage2_get_pmd(kvm, NULL, gpa);
>>>> ????? if (!pmd || pmd_none(*pmd))??? /* Nothing there */
>>>> ????????? return 0;
>>>>
>>> I'll let Suzuki comment on this, but I'm a bit suspicious of this patch.
>> sure, more comments, more clear for the issue.
>>
>
^ permalink raw reply
* [PATCH] armpmu: broadcast overflow irq on multi-core system having one muxed SPI for PMU.
From: Hoeun Ryu @ 2018-05-14 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511103901.osi5lckq55jrms64@lakrids.cambridge.arm.com>
Thank you for the review.
I understand your NACK.
But I'd like to just fix the part of smp_call_function() in the next version.
You can simply ignore it.
> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: Friday, May 11, 2018 7:39 PM
> To: ????? <hoeun.ryu@lge.com>
> Cc: 'Hoeun Ryu' <hoeun.ryu@lge.com.com>; 'Will Deacon'
> <will.deacon@arm.com>; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [PATCH] armpmu: broadcast overflow irq on multi-core system
> having one muxed SPI for PMU.
>
> On Fri, May 11, 2018 at 08:20:49AM +0900, ????? wrote:
> > Thank you for the reply.
> >
> > > -----Original Message-----
> > > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > > Sent: Thursday, May 10, 2018 7:21 PM
> > > To: Hoeun Ryu <hoeun.ryu@lge.com.com>
> > > Cc: Will Deacon <will.deacon@arm.com>; Hoeun Ryu <hoeun.ryu@lge.com>;
> > > linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org
> > > Subject: Re: [PATCH] armpmu: broadcast overflow irq on multi-core
> system
> > > having one muxed SPI for PMU.
>
> > > Muxing the PMU IRQs is a really broken system design, and there's no
> good
> > > way of supporting it.
>
> > > What we should do for such systems is:
> > >
> > > * Add a flag to the DT to describe that the IRQs are muxed, as this
> > > cannot be probed.
> > >
> > > * Add hrtimer code to periodically update the counters, to avoid
> > > overflow (e.g. as we do in the l2x0 PMU).
> > >
> > > * Reject sampling for such systems, as this cannot be done reliably or
> > > efficiently.
> > >
> > > NAK to broadcasting the IRQ -- there are a number of issues with the
> > > general approach.
> >
> > The second solution would be good if sampling is necessary even like
> those
> > systems.
>
> Please note that I mean *all* of the above. There would be no sampling
> on systems with muxed PMU IRQs, since there's no correlation between
> overflow events and the hrtimer interrupts -- the results of sampling
> would be misleading.
>
> > Actually I'm working on FIQ available ARM32 system and trying to enable
> the
> > hard lockup detector by routing the PMU IRQ to FIQ.
> > Because of that, I really need the interrupt event if it is a muxed SPI,
> > beside I also need to make an dedicated IPI FIQ to broadcast the IRQ in
> > this approach.
> > What would you do if you were in the same situation ?
>
> I don't think that this can work with a muxed IRQ, sorry.
>
> It would be better to use some kind of timer.
>
> [...]
>
> > > Futher, If you ever encounter a case where you need to avoid
> preemption
> > > across enabling IRQs, preemption must be disabled *before* enabling
> IRQs.
> >
> > Ah, OK.
> > Enabling IRQs can cause scheduling tasks in the end of exception or
> other
> > scheduling points, right ?
>
> Yes. If an IRQ was taken *between* enabling IRQs and disabling
> preemption, preemption may occur as part of the exception return.
>
> Thanks,
> Mark.
^ permalink raw reply
* [PATCHv2] armpmu: broadcast overflow irq on multi-core system having one muxed SPI for PMU.
From: Hoeun Ryu @ 2018-05-14 2:23 UTC (permalink / raw)
To: linux-arm-kernel
From: Hoeun Ryu <hoeun.ryu@lge.com>
On some SoCs like i.MX6DL/QL have only one muxed SPI for multi-core system.
On the systems, a CPU can be interrupted by overflow irq but it is possible that
the overflow actually occurs on another CPU.
This patch broadcasts the irq using smp_call_function_single_async() so that other
CPUs can check and handle their overflows by themselves when a overflow doesn't
actually occur on the interrupted CPU. Per-cpu call_single_data are allocated in
arm_pmu structure for this purpose during initialization
The callback for smp_call_function_single_async() is __armpmu_handle_irq() and
the function calls armpmu->handle_irq() with an invalid irq_num because
smp_call_func_t has only one parameter and armpmu pointer is handed over by the
pointer. It can be a problem if irq_num parameter is used by handlers but no
handler uses the irq parameter for now. We could have another approach removing
irq_num argument itself in handle_irq() function.
Signed-off-by: Hoeun Ryu <hoeun.ryu@lge.com>
---
drivers/perf/arm_pmu.c | 62 ++++++++++++++++++++++++++++++++++++++++++--
include/linux/perf/arm_pmu.h | 3 +++
2 files changed, 63 insertions(+), 2 deletions(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 1a0d340..df024a0 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -322,6 +322,29 @@ validate_group(struct perf_event *event)
return 0;
}
+static void __armpmu_handle_irq(void *dev)
+{
+ struct arm_pmu *armpmu;
+ u64 start_clock, finish_clock;
+ irqreturn_t ret;
+
+ armpmu = *(void **)dev;
+ start_clock = sched_clock();
+ /*
+ * irq_num should not be used by the handler, we don't have irq_num for
+ * the first place. There is no handler using the irq_num argument for now.
+ * smp_call_func_t has one function argument and irq number cannot be handed
+ * over to this callback because we need dev pointer here.
+ * If you need valid irq_num, you need to declare a wrapper struct having
+ * irq_num and dev pointer.
+ */
+ ret = armpmu->handle_irq(-1, armpmu);
+ if (ret == IRQ_HANDLED) {
+ finish_clock = sched_clock();
+ perf_sample_event_took(finish_clock - start_clock);
+ }
+}
+
static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
{
struct arm_pmu *armpmu;
@@ -340,9 +363,34 @@ static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
start_clock = sched_clock();
ret = armpmu->handle_irq(irq, armpmu);
- finish_clock = sched_clock();
+ /*
+ * The handler just returns with IRQ_NONE when it checks the overflow
+ * and the overflow doesn't occur on the CPU.
+ *
+ * Some SoCs like i.MX6 have one muxed SPI on multi-core system.
+ * On the systems , the irq should be broadcasted to other CPUs so that the
+ * CPUs can check their own PMU overflow.
+ */
+ if (ret == IRQ_HANDLED) {
+ finish_clock = sched_clock();
+ perf_sample_event_took(finish_clock - start_clock);
+ } else if (ret == IRQ_NONE) {
+ int cpu;
+ struct cpumask mask;
+
+ cpumask_copy(&mask, cpu_online_mask);
+ cpumask_clear_cpu(raw_smp_processor_id(), &mask);
+ for_each_cpu(cpu, &mask) {
+ call_single_data_t *csd =
+ per_cpu_ptr(armpmu->ov_brdcast_csd, cpu);
+
+ csd->func = __armpmu_handle_irq;
+ csd->info = dev;
+
+ smp_call_function_single_async(cpu, csd);
+ }
+ }
- perf_sample_event_took(finish_clock - start_clock);
return ret;
}
@@ -790,6 +838,13 @@ static struct arm_pmu *__armpmu_alloc(gfp_t flags)
goto out_free_pmu;
}
+ pmu->ov_brdcast_csd = alloc_percpu_gfp(call_single_data_t, flags);
+ if (!pmu->ov_brdcast_csd) {
+ pr_info("failed to allocate per-cpu "
+ "overflow broadcasting call single data.\n");
+ goto out_free_hw_events;
+ }
+
pmu->pmu = (struct pmu) {
.pmu_enable = armpmu_enable,
.pmu_disable = armpmu_disable,
@@ -824,6 +879,8 @@ static struct arm_pmu *__armpmu_alloc(gfp_t flags)
return pmu;
+out_free_hw_events:
+ free_percpu(pmu->hw_events);
out_free_pmu:
kfree(pmu);
out:
@@ -844,6 +901,7 @@ struct arm_pmu *armpmu_alloc_atomic(void)
void armpmu_free(struct arm_pmu *pmu)
{
free_percpu(pmu->hw_events);
+ free_percpu(pmu->ov_brdcast_csd);
kfree(pmu);
}
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 40036a5..a63da63 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -107,6 +107,9 @@ struct arm_pmu {
/* Only to be used by ACPI probing code */
unsigned long acpi_cpuid;
+
+ /* per-cpu call single data for overflow broadcasting */
+ call_single_data_t __percpu *ov_brdcast_csd;
};
#define to_arm_pmu(p) (container_of(p, struct arm_pmu, pmu))
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v10 00/27] ARM: davinci: convert to common clock framework
From: David Lechner @ 2018-05-14 1:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xJ6+vmyrTQGYH=pKz5GRf7rLT4otreNgu6TJi_3UAEX5w@mail.gmail.com>
On 05/13/2018 07:40 PM, Adam Ford wrote:
> On Wed, May 9, 2018 at 12:25 PM, David Lechner <david@lechnology.com> wrote:
>> This series converts mach-davinci to use the common clock framework.
>>
>> The series works like this, the first 3 patches fix some issues with the clock
>> drivers that have already been accepted into the mainline kernel.
>>
>> Then, starting with "ARM: davinci: pass clock as parameter to
>> davinci_timer_init()", we get the mach code ready for the switch by adding the
>> code needed for the new clock drivers and adding #ifndef CONFIG_COMMON_CLK
>> around the legacy clocks so that we can switch easily between the old and the
>> new.
>>
>> "ARM: davinci: switch to common clock framework" actually flips the switch
>> to start using the new clock drivers. Then the next 8 patches remove all
>> of the old clock code.
>>
>> The final four patches add device tree clock support to the one SoC that
>> supports it.
>>
>> This series has been tested on TI OMAP-L138 LCDK (both device tree and legacy
>> board file).
>>
>
> I am not sure if I did something wrong, but I attempted to build and I
> wasn't able to boot the da850-evm.dtb your repo common-clk-v11,
> however the legacy board file boot was OK.
>
> make davinci_all_defconfig ARCH=arm
> make zImage modules da850-evm.dtb ARCH=arm CROSS_COMPILE=arm-linux- -j8
>
> 3140416 bytes read in 1464 ms (2 MiB/s)
> 20353 bytes read in 15 ms (1.3 MiB/s)
> ## Flattened Device Tree blob at c0600000
> Booting using the fdt blob at 0xc0600000
> Loading Device Tree to c7e57000, end c7e5ef80 ... OK
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
>
> (and hang)
>
> If you have some suggestions, I am try them as I get time.
>
As with each revision of this series, I have included debugging tips
in the cover letter, e.g. earlyprink and not disabling unused clocks.
^ permalink raw reply
* [PATCH v1 3/5] arm64: dts: rockchip: Add gpio-syscon10 to rk3328
From: Levin Du @ 2018-05-14 1:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLujC0nx9LpkWuSR0+fsZn4UJL9Ln6SHWyBmZ-7ErMzfw@mail.gmail.com>
On 2018-05-11 8:24 PM, Rob Herring wrote:
> On Thu, May 10, 2018 at 10:45 PM, Levin Du <djw@t-chip.com.cn> wrote:
>> On 2018-05-10 8:50 PM, Robin Murphy wrote:
>>> On 10/05/18 10:16, djw at t-chip.com.cn wrote:
>>>> From: Levin Du <djw@t-chip.com.cn>
>>>>
>>>> Adding a new gpio controller named "gpio-syscon10" to rk3328, providing
>>>> access to the pins defined in the syscon GRF_SOC_CON10.
>>>
>>> This is the GPIO_MUTE pin, right? The public TRM is rather vague, but
>>> cross-referencing against the datasheet and schematics implies that it's the
>>> "gpiomut_*" part of the GRF bit names which is most significant.
>>>
>>> It might be worth using a more descriptive name here, since "syscon10" is
>>> pretty much meaningless at the board level.
>>>
>>> Robin.
>>>
>> Previously I though other bits might be able to reference from syscon10,
>> other than GPIO_MUTE alone.
>> If it is renamed to gpio-mute, then the GPIO_MUTE pin is accessed as
>> `<&gpio-mute 1>`. Yet other
>> bits in syscon10 can also be referenced, say, `<&gpio-mute 10>`, which is
>> not good.
>>
>> I'd like to add a `gpio,syscon-bit` property to gpio-syscon, which overrides
>> the properties
>> of bit_count, data_bit_offset and dir_bit_offset in the driver. For
> No. Once you are describing individual register bits, it is too low
> level for DT.
Okay. So I'll rename it to gpio_mute, and reference the output pin as
<&gpio_mute 1>:
+ // Use <&gpio_mute 1> to ref to GPIO_MUTE pin
+ gpio_mute: gpio-mute {
+ compatible = "rockchip,gpio-syscon";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio,syscon-dev = <0 0x0428 0>;
+ };
};
Thanks
Levin
^ permalink raw reply
* [PATCH v1 3/5] arm64: dts: rockchip: Add gpio-syscon10 to rk3328
From: Levin Du @ 2018-05-14 1:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLK6S0iA=K1o=gpuJAxD6HxCSzHaJ6ZchuCz=GZ-Zb=Dg@mail.gmail.com>
On 2018-05-11 8:22 PM, Rob Herring wrote:
> On Thu, May 10, 2018 at 4:16 AM, <djw@t-chip.com.cn> wrote:
>> From: Levin Du <djw@t-chip.com.cn>
>>
>> Adding a new gpio controller named "gpio-syscon10" to rk3328, providing
>> access to the pins defined in the syscon GRF_SOC_CON10.
>>
>> Boards using these special pins to control regulators or LEDs, can now
>> utilize existing drivers like gpio-regulator and leds-gpio.
>>
>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>
>> ---
>>
>> Changes in v1:
>> - Split from V0 and add to rk3328.dtsi for general use.
>>
>> arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>> index b8e9da1..73a822d 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>> @@ -309,6 +309,12 @@
>> mode-loader = <BOOT_BL_DOWNLOAD>;
>> };
>>
>> + gpio_syscon10: gpio-syscon10 {
> GPIO controller nodes should be named just 'gpio'.
'gpio' is a general name, and there're already gpio0~gpio3 for pinctrl
GPIOs.
>> + compatible = "rockchip,gpio-syscon";
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + gpio,syscon-dev = <0 0x0428 0>;
> This property is not documented and takes a phandle.
See PATCH1 which allows fetching syscon from parent node .
This is also documented in
Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
in PATCH2.
Thanks
Levin
^ permalink raw reply
* [PATCH] ARM: dts: imx: add proper #address-cells/#size-cells for ipu_di port nodes
From: Fabio Estevam @ 2018-05-14 1:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526260306-14063-1-git-send-email-shawnguo@kernel.org>
On Sun, May 13, 2018 at 10:11 PM, Shawn Guo <shawnguo@kernel.org> wrote:
> It adds proper #address-cells/#size-cells for ipu_di port nodes to fix
> the following DTC warnings.
>
> arch/arm/boot/dts/imx6dl-aristainetos_7.dtb: Warning (reg_format): /soc/ipu at 2400000/port at 2/endpoint at 0:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
> arch/arm/boot/dts/imx6dl-aristainetos_7.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
> arch/arm/boot/dts/imx6dl-aristainetos_7.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
> arch/arm/boot/dts/imx6dl-aristainetos_7.dtb: Warning (avoid_default_addr_size): /soc/ipu at 2400000/port at 2/endpoint at 0: Relying on default #address-cells value
> ...
>
> Fixes: e6bb17850d1e ("ARM: dts: imx: fix IPU OF graph endpoint node names")
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH] ARM: dts: imx: add proper #address-cells/#size-cells for ipu_di port nodes
From: Shawn Guo @ 2018-05-14 1:11 UTC (permalink / raw)
To: linux-arm-kernel
It adds proper #address-cells/#size-cells for ipu_di port nodes to fix
the following DTC warnings.
arch/arm/boot/dts/imx6dl-aristainetos_7.dtb: Warning (reg_format): /soc/ipu at 2400000/port at 2/endpoint at 0:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
arch/arm/boot/dts/imx6dl-aristainetos_7.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
arch/arm/boot/dts/imx6dl-aristainetos_7.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/imx6dl-aristainetos_7.dtb: Warning (avoid_default_addr_size): /soc/ipu at 2400000/port at 2/endpoint at 0: Relying on default #address-cells value
...
Fixes: e6bb17850d1e ("ARM: dts: imx: fix IPU OF graph endpoint node names")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/boot/dts/imx6q.dtsi | 4 ++++
arch/arm/boot/dts/imx6qdl.dtsi | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 40d85888a6b3..70483ce72ba6 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -152,6 +152,8 @@
};
ipu2_di0: port at 2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <2>;
ipu2_di0_disp0: endpoint at 0 {
@@ -180,6 +182,8 @@
};
ipu2_di1: port at 3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <3>;
ipu2_di1_hdmi: endpoint at 1 {
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 087379c21842..e50fd1cfaee2 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1284,6 +1284,8 @@
};
ipu1_di0: port at 2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <2>;
ipu1_di0_disp0: endpoint at 0 {
@@ -1312,6 +1314,8 @@
};
ipu1_di1: port at 3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <3>;
ipu1_di1_disp1: endpoint at 0 {
--
1.9.1
^ permalink raw reply related
* reply: [PATCH v3 1/2] PCI: kirin: Add MSI support
From: songxiaowei @ 2018-05-14 1:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi, Andy Shevchenko
Yao is on maternity leave, and I'll take over the job after discussing with her.
> -----????-----
> ???: Andy Shevchenko [mailto:andy.shevchenko at gmail.com]
> ????: 2018?5?14? 7:16
> ???: chenyao (F) <chenyao11@huawei.com>
> ??: songxiaowei <songxiaowei@hisilicon.com>; Wangbinghui
> <wangbinghui@hisilicon.com>; Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>;
> Bjorn Helgaas <bhelgaas@google.com>; xuwei (O) <xuwei5@huawei.com>;
> Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>;
> Catalin Marinas <catalin.marinas@arm.com>; Will Deacon
> <will.deacon@arm.com>; linux-pci at vger.kernel.org; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; linux-arm Mailing List
> <linux-arm-kernel@lists.infradead.org>; devicetree
> <devicetree@vger.kernel.org>; dimitrysh at google.com;
> guodong.xu at linaro.org; Suzhuangluan <suzhuangluan@hisilicon.com>; Kongfei
> <kongfei@hisilicon.com>
> ??: Re: [PATCH v3 1/2] PCI: kirin: Add MSI support
>
> On Fri, May 11, 2018 at 12:15 PM, Yao Chen <chenyao11@huawei.com> wrote:
> > Add support for MSI.
>
>
> > + int ret;
> > +
> > + if (IS_ENABLED(CONFIG_PCI_MSI)) {
>
> > + pci->pp.msi_irq = platform_get_irq(pdev, 0);
> > + if (pci->pp.msi_irq < 0) {
> > + dev_err(&pdev->dev, "failed to get MSI IRQ
> (%d)\n",
> > + pci->pp.msi_irq);
>
> > + return -ENODEV;
>
> Why shadowing actual error code?
[songxiaowei] Sorry, I can't get your point about this, would you explain it for me.
>
> > + }
> > + ret = devm_request_irq(&pdev->dev, pci->pp.msi_irq,
> > + kirin_pcie_msi_irq_handler,
> > + IRQF_SHARED |
> IRQF_NO_THREAD,
> > + "kirin_pcie_msi", &pci->pp);
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to request MSI
> IRQ %d\n",
> > + pci->pp.msi_irq);
> > + return ret;
> > + }
>
> It would be easy to read and maintain if this would be a separate function.
[songxiaowei] Yes, a separate function will be better, and I'll fix it.
>
> > + }
>
>
>
> --
> With Best Regards,
> Andy Shevchenko
Thanks a lot,
Best Regards,
Xiaowei Song
^ 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