* [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
* Re: [PATCH v10 00/27] ARM: davinci: convert to common clock framework
From: Adam Ford @ 2018-05-14 0:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509172606.29387-1-david@lechnology.com>
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.
adam
>
> Changes:
>
> v10 changes (also see individual patches for details):
> - Reworked device tree bindings for DaVinci timer.
> - Dropped helper functions to conditionally call devm_* versions of functions
> - Fix some typos
> - Fix some rebasing issues introduced in v9
>
> v9 changes (also see individual patches for details):
> - Rebased on linux-davnci/master (f5e3203bb775)
> - Dropped drivers/clk patches that landed in v4.17
> - New drivers/clk patches for early boot special case
> - New patch for ti,davinci-timer device tree bindings
> - Updated mach/davinci patches to register clocks in early boot when needed
>
> v8 changes (also see individual patches for details):
> - Rebased on linux-davinci/master
> - Dropped use of __init and __initconst attributes in clk drivers
> - Add clkdev lookups for PLL SYSCLKs
> - Fix genpd clock reference counting issue
> - Fix PSC clock driver loading order issue
> - Fix typo in device tree and add more power-domains properties
>
> v7 changes (also see individual patches for details):
> - Rebased on linux-davinci/master (v4.16-rc)
> - Convert clock drivers to platform devices
> - New patch "ARM: davinci: pass clock as parameter to davinci_timer_init()"
> - Fix issues with lcdk and aemif clock lookups and power domains
> - Fixed other minor issues brought up in v6 review
>
> v6 changes (also see individual patches for details):
> - All of the device tree bindings are changed
> - All of the clock drivers are changed significantly
> - Fixed issues brought up during review of v5
> - "ARM: davinci: move davinci_clk_init() to init_time" is removed from this
> series and submitted separately
>
> v5 changes:
> - Basically, this is an entirely new series
> - Patches are broken up into bite-sized pieces
> - Converted PSC clock driver to use regmap
> - Restored "force" flag for certain DA850 clocks
> - Added device tree bindings
> - Moved more of the clock init to drivers/clk
> - Fixed frequency scaling (maybe*)
>
> * I have frequency scaling using cpufreq-dt, so I know the clocks are doing
> what they need to do to make this work, but I haven't figured out how to
> test davinci-cpufreq driver yet. (Patches to make cpufreq-dt work will be
> sent separately after this series has landed.)
>
>
> Dependencies:
>
> There are still some outstanding fixes to get everything working correctly.
> These are all just runtime dependencies and only needed for certain platforms.
>
> - "drm/tilcdc: Fix setting clock divider for omap-l138"[1]
> - "clk: davinci: pll-dm355: fix SYSCLKn parent names"[2]
> - "remoteproc/davinci: common clock framework related fixes"[3]
>
> [1]: https://patchwork.freedesktop.org/patch/210696/
> [2]: https://lkml.org/lkml/2018/5/9/626
> [3]: https://lkml.org/lkml/2018/5/2/201
>
> You can find a working branch with everything included (plus a few extras, like
> cpufreq-dt) in the "common-clk-v10" branch of https://github.com/dlech/ev3dev-kernel.git.
>
>
> Testing/debugging for the uninitiated:
>
> I only have one device to test with, which is based on da850, so I will
> have to rely on others to do some testing here. Since we are dealing with
> clocks, if something isn't working, you most likely won't see output on
> the serial port. To figure out what is going on, you need to enable...
>
> CONFIG_DEBUG_LL=y
> CONFIG_EARLY_PRINTK=y
>
> and add "earlyprintk clk_ignore_unused" to the kernel command line options.
> You may need to select a different UART for this depending on your board. I
> think UART1 is the default in the kernel configuration.
>
> On da850 devices comment out the lines:
>
> /* pll1_sysclk2 is not affected by CPU scaling, so use it for async3 */
> parent = clk_hw_get_parent_by_index(&mux->hw, 1);
> if (parent)
> clk_set_parent(mux->hw.clk, parent->clk);
> else
> dev_warn(dev, "Failed to find async3 parent clock\n");
>
> in da8xx-cfgchip.c or, if using device tree, comment out the lines:
>
> assigned-clocks = <&async3_clk>;
> assigned-clock-parents = <&pll1_sysclk 2>;
>
> in da850.dtsi when doing earlyprintk, otherwise the UART1 and UART2 clock
> source will change during boot and cause garbled output after a point.
>
>
> David Lechner (27):
> clk: davinci: pll: allow dev == NULL
> clk: davinci: da850-pll: change PLL0 to CLK_OF_DECLARE
> clk: davinci: psc: allow for dev == NULL
> ARM: davinci: pass clock as parameter to davinci_timer_init()
> ARM: davinci: da830: add new clock init using common clock framework
> ARM: davinci: da850: add new clock init using common clock framework
> ARM: davinci: dm355: add new clock init using common clock framework
> ARM: davinci: dm365: add new clock init using common clock framework
> ARM: davinci: dm644x: add new clock init using common clock framework
> ARM: davinci: dm646x: add new clock init using common clock framework
> ARM: davinci: da8xx: add new USB PHY clock init using common clock
> framework
> ARM: davinci: da8xx: add new sata_refclk init using common clock
> framework
> ARM: davinci: remove CONFIG_DAVINCI_RESET_CLOCKS
> ARM: davinci_all_defconfig: remove CONFIG_DAVINCI_RESET_CLOCKS
> ARM: davinci: switch to common clock framework
> ARM: davinci: da830: Remove legacy clock init
> ARM: davinci: da850: Remove legacy clock init
> ARM: davinci: dm355: Remove legacy clock init
> ARM: davinci: dm365: Remove legacy clock init
> ARM: davinci: dm644x: Remove legacy clock init
> ARM: davinci: dm646x: Remove legacy clock init
> ARM: davinci: da8xx: Remove legacy USB and SATA clock init
> ARM: davinci: remove legacy clocks
> dt-bindings: timer: new bindings for TI DaVinci timer
> ARM: davinci: add device tree support to timer
> ARM: davinci: da8xx-dt: switch to device tree clocks
> ARM: dts: da850: Add clocks
>
> .../bindings/timer/ti,davinci-timer.txt | 37 +
> arch/arm/Kconfig | 5 +-
> arch/arm/boot/dts/da850-enbw-cmc.dts | 4 +
> arch/arm/boot/dts/da850-evm.dts | 4 +
> arch/arm/boot/dts/da850-lcdk.dts | 9 +
> arch/arm/boot/dts/da850-lego-ev3.dts | 4 +
> arch/arm/boot/dts/da850.dtsi | 168 ++++
> arch/arm/configs/davinci_all_defconfig | 1 -
> arch/arm/mach-davinci/Kconfig | 13 +-
> arch/arm/mach-davinci/Makefile | 4 +-
> arch/arm/mach-davinci/board-da830-evm.c | 12 +-
> arch/arm/mach-davinci/board-da850-evm.c | 2 +
> arch/arm/mach-davinci/board-dm355-evm.c | 2 +
> arch/arm/mach-davinci/board-dm355-leopard.c | 2 +
> arch/arm/mach-davinci/board-dm365-evm.c | 2 +
> arch/arm/mach-davinci/board-dm644x-evm.c | 2 +
> arch/arm/mach-davinci/board-dm646x-evm.c | 2 +
> arch/arm/mach-davinci/board-mityomapl138.c | 2 +
> arch/arm/mach-davinci/board-neuros-osd2.c | 2 +
> arch/arm/mach-davinci/board-omapl138-hawk.c | 11 +-
> arch/arm/mach-davinci/board-sffsdr.c | 2 +
> arch/arm/mach-davinci/clock.c | 745 -----------------
> arch/arm/mach-davinci/clock.h | 76 --
> arch/arm/mach-davinci/common.c | 3 -
> arch/arm/mach-davinci/da830.c | 462 ++---------
> arch/arm/mach-davinci/da850.c | 778 +++---------------
> arch/arm/mach-davinci/da8xx-dt.c | 66 --
> arch/arm/mach-davinci/davinci.h | 8 +
> arch/arm/mach-davinci/devices-da8xx.c | 43 +-
> arch/arm/mach-davinci/devices.c | 1 -
> arch/arm/mach-davinci/dm355.c | 406 ++-------
> arch/arm/mach-davinci/dm365.c | 485 +----------
> arch/arm/mach-davinci/dm644x.c | 344 +-------
> arch/arm/mach-davinci/dm646x.c | 372 +--------
> arch/arm/mach-davinci/include/mach/clock.h | 3 -
> arch/arm/mach-davinci/include/mach/common.h | 11 +-
> arch/arm/mach-davinci/include/mach/da8xx.h | 6 +-
> arch/arm/mach-davinci/pm_domain.c | 5 +
> arch/arm/mach-davinci/psc.c | 137 ---
> arch/arm/mach-davinci/psc.h | 12 -
> arch/arm/mach-davinci/time.c | 39 +-
> arch/arm/mach-davinci/usb-da8xx.c | 242 +-----
> drivers/clk/davinci/pll-da830.c | 4 +-
> drivers/clk/davinci/pll-da850.c | 36 +-
> drivers/clk/davinci/pll-dm355.c | 8 +-
> drivers/clk/davinci/pll-dm365.c | 8 +-
> drivers/clk/davinci/pll-dm644x.c | 8 +-
> drivers/clk/davinci/pll-dm646x.c | 8 +-
> drivers/clk/davinci/pll.c | 110 +--
> drivers/clk/davinci/pll.h | 30 +-
> drivers/clk/davinci/psc-dm355.c | 2 +-
> drivers/clk/davinci/psc-dm365.c | 2 +-
> drivers/clk/davinci/psc-dm644x.c | 2 +-
> drivers/clk/davinci/psc-dm646x.c | 2 +-
> drivers/clk/davinci/psc.c | 27 +-
> include/linux/clk/davinci.h | 29 +
> 56 files changed, 860 insertions(+), 3950 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/timer/ti,davinci-timer.txt
> delete mode 100644 arch/arm/mach-davinci/clock.c
> delete mode 100644 arch/arm/mach-davinci/psc.c
> create mode 100644 include/linux/clk/davinci.h
>
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH] ARM: dts: imx6qdl-phytec-pfla02: Use IRQ_TYPE specifier
From: Hernán Gonzalez @ 2018-05-13 23:28 UTC (permalink / raw)
To: linux-arm-kernel
Replace magic number with the proper IRQ_TYPE specifier to improve DT
readability.
Signed-off-by: Hern?n Gonzalez <hernan@vanguardiasur.com.ar>
---
arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
index c58f344..1b79ee7 100644
--- a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
@@ -115,7 +115,7 @@
compatible = "dlg,da9063";
reg = <0x58>;
interrupt-parent = <&gpio2>;
- interrupts = <9 0x8>; /* active-low GPIO2_9 */
+ interrupts = <9 IRQ_TYPE_LOW_LEVEL>; /* active-low GPIO2_9 */
regulators {
vddcore_reg: bcore1 {
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: imx53-voipac-dmm-668: Use IRQ_TYPE specifier
From: Hernán Gonzalez @ 2018-05-13 23:27 UTC (permalink / raw)
To: linux-arm-kernel
Replace magic number with the proper IRQ_TYPE specifier to improve DT
readability.
Signed-off-by: Hern?n Gonzalez <hernan@vanguardiasur.com.ar>
---
arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi b/arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi
index df8dafe..f83a8c6 100644
--- a/arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi
+++ b/arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi
@@ -150,7 +150,7 @@
compatible = "dlg,da9053-aa", "dlg,da9052";
reg = <0x48>;
interrupt-parent = <&gpio7>;
- interrupts = <11 0x8>; /* low-level active IRQ at GPIO7_11 */
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>; /* low-level active IRQ at GPIO7_11 */
regulators {
buck1_reg: buck1 {
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: imx53-qsb: Use IRQ_TYPE specifier
From: Hernán Gonzalez @ 2018-05-13 23:26 UTC (permalink / raw)
To: linux-arm-kernel
Replace magic number with the proper IRQ_TYPE specifier to improve DT
readability.
Signed-off-by: Hern?n Gonzalez <hernan@vanguardiasur.com.ar>
---
arch/arm/boot/dts/imx53-qsb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
index d3d662e..dca6c32 100644
--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@ -23,7 +23,7 @@
compatible = "dlg,da9053-aa", "dlg,da9052";
reg = <0x48>;
interrupt-parent = <&gpio7>;
- interrupts = <11 0x8>; /* low-level active IRQ at GPIO7_11 */
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>; /* low-level active IRQ at GPIO7_11 */
regulators {
buck1_reg: buck1 {
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: vf-colibri-eval-v3.dtsi: Use IRQ_TYPE specifier
From: Hernán Gonzalez @ 2018-05-13 23:24 UTC (permalink / raw)
To: linux-arm-kernel
GPIO_ACTIVE_LOW was being used to specify an interrupt, use
IRQ_TYPE_EDGE_RISING instead. This improves DT readability.
Signed-off-by: Hern?n Gonzalez <hernan@vanguardiasur.com.ar>
---
arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index d8b2972..e2da122 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -117,7 +117,7 @@
clocks = <&clk16m>;
spi-max-frequency = <10000000>;
interrupt-parent = <&gpio1>;
- interrupts = <11 GPIO_ACTIVE_LOW>;
+ interrupts = <11 IRQ_TYPE_EDGE_RISING>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: at91-sama5d2_xplained: Use IRQ_TYPE specifier
From: Hernán Gonzalez @ 2018-05-13 23:22 UTC (permalink / raw)
To: linux-arm-kernel
GPIO_ACTIVE_LOW was being used to specify an interrupt, use
IRQ_TYPE_EDGE_RISING instead. This improves DT readability.
Signed-off-by: Hern?n Gonzalez <hernan@vanguardiasur.com.ar>
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index e4bbb7e..fcc85d7 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -232,7 +232,7 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_charger_chglev &pinctrl_charger_lbo &pinctrl_charger_irq>;
interrupt-parent = <&pioA>;
- interrupts = <PIN_PB13 GPIO_ACTIVE_LOW>;
+ interrupts = <PIN_PB13 IRQ_TYPE_EDGE_RISING>;
active-semi,chglev-gpios = <&pioA PIN_PA12 GPIO_ACTIVE_HIGH>;
active-semi,lbo-gpios = <&pioA PIN_PC8 GPIO_ACTIVE_LOW>;
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox