* [PATCH v3 2/2] clk: davinci: pll-dm355: fix SYSCLKn parent names
From: David Lechner @ 2018-05-09 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509153642.22399-1-david@lechnology.com>
This fixes the parent clock names of the SYSCLKn clocks for the DM355
SoC in the TI DaVinici PLL clock driver.
It appears that this name just didn't get updated to the correct name
like the other SoCs during the driver's development.
Reported-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: David Lechner <david@lechnology.com>
---
drivers/clk/davinci/pll-dm355.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/davinci/pll-dm355.c b/drivers/clk/davinci/pll-dm355.c
index 718d9bbbf30d..93f4a53d6b44 100644
--- a/drivers/clk/davinci/pll-dm355.c
+++ b/drivers/clk/davinci/pll-dm355.c
@@ -22,10 +22,10 @@ static const struct davinci_pll_clk_info dm355_pll1_info = {
PLL_POSTDIV_ALWAYS_ENABLED | PLL_POSTDIV_FIXED_DIV,
};
-SYSCLK(1, pll1_sysclk1, pll1, 5, SYSCLK_FIXED_DIV | SYSCLK_ALWAYS_ENABLED);
-SYSCLK(2, pll1_sysclk2, pll1, 5, SYSCLK_FIXED_DIV | SYSCLK_ALWAYS_ENABLED);
-SYSCLK(3, pll1_sysclk3, pll1, 5, SYSCLK_ALWAYS_ENABLED);
-SYSCLK(4, pll1_sysclk4, pll1, 5, SYSCLK_ALWAYS_ENABLED);
+SYSCLK(1, pll1_sysclk1, pll1_pllen, 5, SYSCLK_FIXED_DIV | SYSCLK_ALWAYS_ENABLED);
+SYSCLK(2, pll1_sysclk2, pll1_pllen, 5, SYSCLK_FIXED_DIV | SYSCLK_ALWAYS_ENABLED);
+SYSCLK(3, pll1_sysclk3, pll1_pllen, 5, SYSCLK_ALWAYS_ENABLED);
+SYSCLK(4, pll1_sysclk4, pll1_pllen, 5, SYSCLK_ALWAYS_ENABLED);
int dm355_pll1_init(struct device *dev, void __iomem *base)
{
@@ -62,7 +62,7 @@ static const struct davinci_pll_clk_info dm355_pll2_info = {
PLL_POSTDIV_ALWAYS_ENABLED | PLL_POSTDIV_FIXED_DIV,
};
-SYSCLK(1, pll2_sysclk1, pll2, 5, SYSCLK_FIXED_DIV | SYSCLK_ALWAYS_ENABLED);
+SYSCLK(1, pll2_sysclk1, pll2_pllen, 5, SYSCLK_FIXED_DIV | SYSCLK_ALWAYS_ENABLED);
int dm355_pll2_init(struct device *dev, void __iomem *base)
{
--
2.17.0
^ permalink raw reply related
* [PATCH v3 1/2] clk: davinci: pll-dm355: drop pll2_sysclk2
From: David Lechner @ 2018-05-09 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509153642.22399-1-david@lechnology.com>
This removes pll2_sysclk2 from the TI DM355 clock driver. This SoC
doesn't have such a clock. Also, SYSCLK_ALWAYS_ENABLED is transferred
to pll2_sysclk1 since it drives the DDR and doesn't have another
mechanism to keep it on.
Reported-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: David Lechner <david@lechnology.com>
---
drivers/clk/davinci/pll-dm355.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/clk/davinci/pll-dm355.c b/drivers/clk/davinci/pll-dm355.c
index 5345f8286c50..718d9bbbf30d 100644
--- a/drivers/clk/davinci/pll-dm355.c
+++ b/drivers/clk/davinci/pll-dm355.c
@@ -62,8 +62,7 @@ static const struct davinci_pll_clk_info dm355_pll2_info = {
PLL_POSTDIV_ALWAYS_ENABLED | PLL_POSTDIV_FIXED_DIV,
};
-SYSCLK(1, pll2_sysclk1, pll2, 5, SYSCLK_FIXED_DIV);
-SYSCLK(2, pll2_sysclk2, pll2, 5, SYSCLK_FIXED_DIV | SYSCLK_ALWAYS_ENABLED);
+SYSCLK(1, pll2_sysclk1, pll2, 5, SYSCLK_FIXED_DIV | SYSCLK_ALWAYS_ENABLED);
int dm355_pll2_init(struct device *dev, void __iomem *base)
{
@@ -71,8 +70,6 @@ int dm355_pll2_init(struct device *dev, void __iomem *base)
davinci_pll_sysclk_register(dev, &pll2_sysclk1, base);
- davinci_pll_sysclk_register(dev, &pll2_sysclk2, base);
-
davinci_pll_sysclkbp_clk_register(dev, "pll2_sysclkbp", base);
return 0;
--
2.17.0
^ permalink raw reply related
* [PATCH v3 0/2] clk: davinci: pll-dm355: fix SYSCLKn parent names
From: David Lechner @ 2018-05-09 15:36 UTC (permalink / raw)
To: linux-arm-kernel
v3 changes:
* swap order of patches
v2 changes:
* add new patch to remove non-existent PLL2 SYSCLK2
David Lechner (2):
clk: davinci: pll-dm355: drop pll2_sysclk2
clk: davinci: pll-dm355: fix SYSCLKn parent names
drivers/clk/davinci/pll-dm355.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
--
2.17.0
^ permalink raw reply
* [PATCH] ARM: DTS: imx53: Add support for imx53 HSC/DDC boards from K+P
From: Lukasz Majewski @ 2018-05-09 15:34 UTC (permalink / raw)
To: linux-arm-kernel
This commit provides support for HSC and DDC boards from
Kieback&Peter GmbH vendor.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx53-kp-ddc.dts | 146 ++++++++++++++++++++++++++++
arch/arm/boot/dts/imx53-kp-hsc.dts | 53 ++++++++++
arch/arm/boot/dts/imx53-kp.dtsi | 191 +++++++++++++++++++++++++++++++++++++
4 files changed, 392 insertions(+)
create mode 100644 arch/arm/boot/dts/imx53-kp-ddc.dts
create mode 100644 arch/arm/boot/dts/imx53-kp-hsc.dts
create mode 100644 arch/arm/boot/dts/imx53-kp.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fbc04b0db781..00854a5b6ac4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -360,6 +360,8 @@ dtb-$(CONFIG_SOC_IMX51) += \
dtb-$(CONFIG_SOC_IMX53) += \
imx53-ard.dtb \
imx53-cx9020.dtb \
+ imx53-kp-ddc.dtb \
+ imx53-kp-hsc.dtb \
imx53-m53evk.dtb \
imx53-mba53.dtb \
imx53-ppd.dtb \
diff --git a/arch/arm/boot/dts/imx53-kp-ddc.dts b/arch/arm/boot/dts/imx53-kp-ddc.dts
new file mode 100644
index 000000000000..acaf477a52c5
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-kp-ddc.dts
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx53-kp.dtsi"
+
+/ {
+ model = "K+P imx53 DDC";
+ compatible = "kiebackpeter,imx53-ddc", "fsl,imx53";
+
+ backlight_lcd: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm2 0 50000>;
+ power-supply = <®_backlight>;
+ brightness-levels = <0 24 28 32 36
+ 40 44 48 52 56
+ 60 64 68 72 76
+ 80 84 88 92 96 100>;
+ default-brightness-level = <20>;
+ };
+
+ lcd_display: disp1 {
+ compatible = "fsl,imx-parallel-display";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interface-pix-fmt = "rgb24";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_disp>;
+
+ port at 0 {
+ reg = <0>;
+
+ display1_in: endpoint {
+ remote-endpoint = <&ipu_di1_disp1>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ lcd_display_out: endpoint {
+ remote-endpoint = <&lcd_panel_in>;
+ };
+ };
+ };
+
+ lcd_panel: lcd-panel {
+ compatible = "koe,tx14d24vm1bpa";
+ backlight = <&backlight_lcd>;
+ power-supply = <®_3v3>;
+
+ port {
+ lcd_panel_in: endpoint {
+ remote-endpoint = <&lcd_display_out>;
+ };
+ };
+ };
+
+ reg_backlight: regulator-backlight {
+ compatible = "regulator-fixed";
+ regulator-name = "backlight-supply";
+ regulator-min-microvolt = <15000000>;
+ regulator-max-microvolt = <15000000>;
+ regulator-always-on;
+ };
+};
+
+&i2c3 {
+ adc at 48 {
+ compatible = "ti,ads1015";
+ reg = <0x48>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel at 4 {
+ reg = <4>;
+ ti,gain = <2>;
+ ti,datarate = <4>;
+ };
+
+ channel at 6 {
+ reg = <6>;
+ ti,gain = <2>;
+ ti,datarate = <4>;
+ };
+ };
+
+ gpio_expander2 at 21 {
+ compatible = "nxp,pcf8574";
+ reg = <0x21>;
+ interrupts = <109>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+};
+
+&iomuxc {
+ imx53-kp-ddc {
+ pinctrl_disp: dispgrp {
+ fsl,pins = <
+ MX53_PAD_EIM_A16__IPU_DI1_DISP_CLK 0x4
+ MX53_PAD_EIM_DA10__IPU_DI1_PIN15 0x4
+ MX53_PAD_EIM_DA9__IPU_DISP1_DAT_0 0x4
+ MX53_PAD_EIM_DA8__IPU_DISP1_DAT_1 0x4
+ MX53_PAD_EIM_DA7__IPU_DISP1_DAT_2 0x4
+ MX53_PAD_EIM_DA6__IPU_DISP1_DAT_3 0x4
+ MX53_PAD_EIM_DA5__IPU_DISP1_DAT_4 0x4
+ MX53_PAD_EIM_DA4__IPU_DISP1_DAT_5 0x4
+ MX53_PAD_EIM_DA3__IPU_DISP1_DAT_6 0x4
+ MX53_PAD_EIM_DA2__IPU_DISP1_DAT_7 0x4
+ MX53_PAD_EIM_DA1__IPU_DISP1_DAT_8 0x4
+ MX53_PAD_EIM_DA0__IPU_DISP1_DAT_9 0x4
+ MX53_PAD_EIM_EB1__IPU_DISP1_DAT_10 0x4
+ MX53_PAD_EIM_EB0__IPU_DISP1_DAT_11 0x4
+ MX53_PAD_EIM_A17__IPU_DISP1_DAT_12 0x4
+ MX53_PAD_EIM_A18__IPU_DISP1_DAT_13 0x4
+ MX53_PAD_EIM_A19__IPU_DISP1_DAT_14 0x4
+ MX53_PAD_EIM_A20__IPU_DISP1_DAT_15 0x4
+ MX53_PAD_EIM_A21__IPU_DISP1_DAT_16 0x4
+ MX53_PAD_EIM_A22__IPU_DISP1_DAT_17 0x4
+ MX53_PAD_EIM_A23__IPU_DISP1_DAT_18 0x4
+ MX53_PAD_EIM_A24__IPU_DISP1_DAT_19 0x4
+ MX53_PAD_EIM_D31__IPU_DISP1_DAT_20 0x4
+ MX53_PAD_EIM_D30__IPU_DISP1_DAT_21 0x4
+ MX53_PAD_EIM_D26__IPU_DISP1_DAT_22 0x4
+ MX53_PAD_EIM_D27__IPU_DISP1_DAT_23 0x4
+ MX53_PAD_GPIO_1__PWM2_PWMO 0x4
+ >;
+ };
+ };
+};
+
+&ipu_di1_disp1 {
+ remote-endpoint = <&display1_in>;
+};
+
+&fec {
+ status = "okay";
+};
+
+&pmic {
+ fsl,mc13xxx-uses-touch;
+};
diff --git a/arch/arm/boot/dts/imx53-kp-hsc.dts b/arch/arm/boot/dts/imx53-kp-hsc.dts
new file mode 100644
index 000000000000..fff358395c9d
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-kp-hsc.dts
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx53-kp.dtsi"
+
+/ {
+ model = "K+P imx53 HSC";
+ compatible = "kiebackpeter,imx53-hsc", "fsl,imx53";
+
+};
+
+&fec {
+ status = "okay";
+
+ fixed-link { /* RMII fixed link to LAN9303 */
+ speed = <100>;
+ full-duplex;
+ };
+};
+
+&i2c3 {
+ switch: switch at a {
+ compatible = "smsc,lan9303-i2c";
+ reg = <0xa>;
+ reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+ reset-duration = <400>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 { /* RMII fixed link to master */
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&fec>;
+ };
+
+ port at 1 { /* external port 1 */
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port at 2 { /* external port 2 */
+ reg = <2>;
+ label = "lan2";
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/imx53-kp.dtsi b/arch/arm/boot/dts/imx53-kp.dtsi
new file mode 100644
index 000000000000..86bea3217f18
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-kp.dtsi
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx53-tqma53.dtsi"
+
+/ {
+ buzzer {
+ compatible = "pwm-beeper";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_buzzer>;
+
+ pwms = <&pwm1 0 500000>;
+ };
+
+ gpio_buttons {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpiobuttons>;
+
+ button at 1 {
+ label = "Kaltstart";
+ linux,code = <64>; /* KEY_F6 */
+ gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
+ };
+ button at 2 {
+ label = "PowerFailInterrupt";
+ linux,code = <65>; /* KEY_F7 */
+ gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led_bus {
+ label = "bus";
+ gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "gpio";
+ default-state = "off";
+ };
+
+ led_error {
+ label = "error";
+ gpios = <&gpio3 28 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "gpio";
+ default-state = "off";
+ };
+
+ led_flash {
+ label = "flash";
+ gpios = <&gpio5 0 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+};
+
+&can1 {
+ status = "okay";
+};
+
+&can2 {
+ status = "okay";
+};
+
+&i2c3 {
+ status = "okay";
+
+ gpio_expander1 at 22 {
+ compatible = "nxp,pcf8574";
+ reg = <0x22>;
+ interrupts = <109>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ rtc at 51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_kp_common>;
+
+ imx53-kp-common {
+ pinctrl_buzzer: buzzergrp {
+ fsl,pins = <
+ MX53_PAD_SD1_DATA3__PWM1_PWMO 0x1e4
+ >;
+ };
+
+ pinctrl_gpiobuttons: gpiobuttonsgrp {
+ fsl,pins = <
+ MX53_PAD_EIM_RW__GPIO2_26 0x1e4
+ MX53_PAD_EIM_D22__GPIO3_22 0x1e4
+ >;
+ };
+
+ pinctrl_kp_common: kpcommongrp {
+ fsl,pins = <
+ MX53_PAD_EIM_CS0__GPIO2_23 0x1e4
+ MX53_PAD_GPIO_19__GPIO4_5 0x1e4
+ MX53_PAD_PATA_DATA6__GPIO2_6 0x1e4
+ MX53_PAD_PATA_DATA7__GPIO2_7 0xe0
+ MX53_PAD_CSI0_DAT14__GPIO6_0 0x1e4
+ MX53_PAD_CSI0_DAT16__GPIO6_2 0x1e4
+ MX53_PAD_CSI0_DAT18__GPIO6_4 0x1e4
+ MX53_PAD_EIM_D17__GPIO3_17 0x1e4
+ MX53_PAD_EIM_D18__GPIO3_18 0x1e4
+ MX53_PAD_EIM_D21__GPIO3_21 0x1e4
+ MX53_PAD_EIM_D29__GPIO3_29 0x1e4
+ MX53_PAD_EIM_DA11__GPIO3_11 0x1e4
+ MX53_PAD_EIM_DA13__GPIO3_13 0x1e4
+ MX53_PAD_EIM_DA14__GPIO3_14 0x1e4
+ MX53_PAD_SD1_DATA0__GPIO1_16 0x1e4
+ MX53_PAD_SD1_CMD__GPIO1_18 0x1e4
+ MX53_PAD_SD1_CLK__GPIO1_20 0x1e4
+ >;
+ };
+
+ pinctrl_leds: ledgrp {
+ fsl,pins = <
+ MX53_PAD_EIM_EB2__GPIO2_30 0x1d4
+ MX53_PAD_EIM_D28__GPIO3_28 0x1d4
+ MX53_PAD_EIM_WAIT__GPIO5_0 0x1d4
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX53_PAD_CSI0_DAT12__UART4_TXD_MUX 0x1e4
+ MX53_PAD_CSI0_DAT13__UART4_RXD_MUX 0x1e4
+ >;
+ };
+ };
+};
+
+&pinctrl_uart1 {
+ fsl,pins = <
+ MX53_PAD_EIM_D23__GPIO3_23 0x1e4
+ MX53_PAD_EIM_EB3__GPIO2_31 0x1e4
+ MX53_PAD_EIM_D24__GPIO3_24 0x1e4
+ MX53_PAD_EIM_D25__GPIO3_25 0x1e4
+ MX53_PAD_EIM_D19__GPIO3_19 0x1e4
+ MX53_PAD_EIM_D20__GPIO3_20 0x1e4
+ >;
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbphy0 {
+ status = "disabled";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules
From: Mathieu Poirier @ 2018-05-09 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d0y5toed.fsf@xmission.com>
On Tue, May 08, 2018 at 11:59:38PM -0500, Eric W. Biederman wrote:
> Kim Phillips <kim.phillips@arm.com> writes:
>
> > This patch is in the context of allowing the Coresight h/w
> > trace driver suite to be loaded as modules. Coresight uses
> > find_task_by_vpid when running in direct capture mode (via sysfs)
> > when getting/setting the context ID comparator to trigger on
> > (/sys/bus/coresight/devices/<x>.etm/ctxid_pid).
>
> Aside from my objection about how bad an interface a pid in sysfs is.
> The implementation of coresight_vpid_to_pid is horrible.
>
> The code should be just:
>
> static inline pid_t coresight_vpid_to_pid(pid_t vpid)
> {
> rcu_read_lock();
> pid = pid_nr(find_vpid(vpid));
> rcu_read_unlock();
>
> return pid;
> }
> Which takes find_task_by_vpid out of the picture.
Many thanks for pointing out the right way to do this. When Chunyan added
this feature she broadly published her work and find_task_by_vpid() is the
function she was asked to used.
>
> But reading further I am seeing code writing a pid to hardware. That is
> broken. That is a layering violation of the first order. Giving
> implementation details like that to hardware.
This is how the feature works - as Robin pointed out tracers are designed to
match pid values with the CPU's contextID register. The input value has no
other effect than triggering trace collection, which has absolutely no baring on
the CPU.
>
> Any chance while you are working on this you can modify this code so
> that it does something sensible and defensible instead of every line of
> code I read be wrong in at least one detail?
>
> Thank you,
> Eric
>
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: renesas: r8a77970: Add Cortex-A53 PMU node
From: Geert Uytterhoeven @ 2018-05-09 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525879403-12207-1-git-send-email-geert+renesas@glider.be>
Enable the performance monitor unit for the Cortex-A53 cores on the
R-Car V3M (r8a77970) SoC.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- Move the pmu node from the soc subnode to the root node, as it
doesn't have registers.
---
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index ccc955e89cea4d32..71157ad893910a97 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -73,6 +73,13 @@
clock-frequency = <0>;
};
+ pmu_a53 {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts-extended = <&gic GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&a53_0>, <&a53_1>;
+ };
+
psci {
compatible = "arm,psci-1.0", "arm,psci-0.2";
method = "smc";
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: renesas: r8a77970: Add secondary CA53 CPU core
From: Geert Uytterhoeven @ 2018-05-09 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525879403-12207-1-git-send-email-geert+renesas@glider.be>
Add a device node for the second Cortex-A53 CPU core on the Renesas
R-Car V3M (r8a77970) SoC, and adjust the interrupt delivery masks for
ARM Generic Interrupt Controller and Architectured Timer.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- Adjust GIC_CPU_MASK_SIMPLE(),
- Use symbolic core clock and power domain indices.
---
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index 6ed2e95eb53dbb15..ccc955e89cea4d32 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -41,6 +41,16 @@
enable-method = "psci";
};
+ a53_1: cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <1>;
+ clocks = <&cpg CPG_CORE R8A77970_CLK_Z2>;
+ power-domains = <&sysc R8A77970_PD_CA53_CPU1>;
+ next-level-cache = <&L2_CA53>;
+ enable-method = "psci";
+ };
+
L2_CA53: cache-controller {
compatible = "cache";
power-domains = <&sysc R8A77970_PD_CA53_SCU>;
@@ -603,7 +613,7 @@
<0 0xf1020000 0 0x20000>,
<0 0xf1040000 0 0x20000>,
<0 0xf1060000 0 0x20000>;
- interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(1) |
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_HIGH)>;
clocks = <&cpg CPG_MOD 408>;
clock-names = "clk";
@@ -694,9 +704,9 @@
timer {
compatible = "arm,armv8-timer";
- interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
- <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
- <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
- <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>;
+ interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/2] arm64: dts: renesas: r8a77970: Add SMP Support
From: Geert Uytterhoeven @ 2018-05-09 15:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon, Magnus,
This patch series enables SMP support on the R-Car V3M SoC, by adding
the second Cortex-A53 CPU core. It also adds the performance monitor
unit, and links it to both CPU cores.
Changes compared to v1:
- Adjust GIC_CPU_MASK_SIMPLE(),
- Use symbolic core clock and power domain indices,
- Move the pmu node from the soc subnode to the root node, as it
doesn't have registers.
Note that the PSCI implementation on Eagle may be a preliminary version
with some familiar quirks:
- SMP bringup works, and both CPUs can be used,
- Offlining CPU0 crashes the system,
- CPU1 can be offlined, but trying to bring it online again crashes
the system, too.
I'm confident these will be fixed in future firmware versions, just like
on H3/Salvator-X. Note that
git at github.com:renesas-rcar/arm-trusted-firmware.git does not have
support for R-Car V3M, V3H, and D3.
Thanks!
Geert Uytterhoeven (2):
arm64: dts: renesas: r8a77970: Add secondary CA53 CPU core
arm64: dts: renesas: r8a77970: Add Cortex-A53 PMU node
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 27 ++++++++++++++++++++++-----
1 file changed, 22 insertions(+), 5 deletions(-)
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 2/2] ARM: dts: stm32: update rtc st, syscfg property on stm32f746
From: Amelie Delaunay @ 2018-05-09 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525879094-19562-1-git-send-email-amelie.delaunay@st.com>
To fit with latest rtc driver updates, rtc st,syscfg property must contain
the control register offset of pwrcfg and the mask corresponding to the
DBP (Disable Backup Protection) bit.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/boot/dts/stm32f746.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index 1479e3e..f48d06a 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -297,7 +297,7 @@
interrupt-parent = <&exti>;
interrupts = <17 1>;
interrupt-names = "alarm";
- st,syscfg = <&pwrcfg>;
+ st,syscfg = <&pwrcfg 0x00 0x100>;
status = "disabled";
};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: stm32: update rtc st, syscfg property on stm32f429
From: Amelie Delaunay @ 2018-05-09 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525879094-19562-1-git-send-email-amelie.delaunay@st.com>
To fit with latest rtc driver updates, rtc st,syscfg property must contain
the control register offset of pwrcfg and the mask corresponding to the
DBP (Disable Backup Protection) bit.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index ede77e0..309e7e3 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -302,7 +302,7 @@
interrupt-parent = <&exti>;
interrupts = <17 1>;
interrupt-names = "alarm";
- st,syscfg = <&pwrcfg>;
+ st,syscfg = <&pwrcfg 0x00 0x100>;
status = "disabled";
};
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] ARM: dts: stm32: update rtc st,syscfg
From: Amelie Delaunay @ 2018-05-09 15:18 UTC (permalink / raw)
To: linux-arm-kernel
With the lastest STM32 RTC driver updates, it is mandatory to define
pwrcfg control register and DBP (Disable Backup Protection) bit through
st,syscfg property. This patchset updates RTC nodes on stm32f429 and
stm32f746 accordingly.
Amelie Delaunay (2):
ARM: dts: stm32: update rtc st,syscfg property on stm32f429
ARM: dts: stm32: update rtc st,syscfg property on stm32f746
arch/arm/boot/dts/stm32f429.dtsi | 2 +-
arch/arm/boot/dts/stm32f746.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v3] mtd: nxp-spifi: release flash_np in nxp_spifi_probe()
From: Alexey Khoroshilov @ 2018-05-09 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509170310.65d19c49@bbrezillon>
nxp_spifi_probe() increments refcnt of SPI flash device node by
of_get_next_available_child() and leaves it undecremented on both
successful and error paths.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
v3: Move of_node_put() before return value check as Boris Brezillon suggested.
drivers/mtd/spi-nor/nxp-spifi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi-nor/nxp-spifi.c b/drivers/mtd/spi-nor/nxp-spifi.c
index 15374216d4d9..0c9094ec5966 100644
--- a/drivers/mtd/spi-nor/nxp-spifi.c
+++ b/drivers/mtd/spi-nor/nxp-spifi.c
@@ -436,6 +436,7 @@ static int nxp_spifi_probe(struct platform_device *pdev)
}
ret = nxp_spifi_setup_flash(spifi, flash_np);
+ of_node_put(flash_np);
if (ret) {
dev_err(&pdev->dev, "unable to setup flash chip\n");
goto dis_clks;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device
From: Andrzej Hajda @ 2018-05-09 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504135212.26977-2-peda@axentia.se>
On 04.05.2018 15:51, Peter Rosin wrote:
> Bridge drivers can now (temporarily, in a transition phase) select if
> they want to provide a full owner device or keep just providing an
> of_node.
>
> By providing a full owner device, the bridge drivers no longer need
> to provide an of_node since that node is available via the owner
> device.
>
> When all bridge drivers provide an owner device, that will become
> mandatory and the .of_node member will be removed.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> drivers/gpu/drm/drm_bridge.c | 3 ++-
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
What is the reason to put rockchip here? Shouldn't be in separate patch?
> include/drm/drm_bridge.h | 2 ++
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 1638bfe9627c..3872f5379998 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -365,7 +365,8 @@ struct drm_bridge *of_drm_find_bridge(struct device_node *np)
> mutex_lock(&bridge_lock);
>
> list_for_each_entry(bridge, &bridge_list, list) {
> - if (bridge->of_node == np) {
> + if ((bridge->odev && bridge->odev->of_node == np) ||
> + bridge->of_node == np) {
> mutex_unlock(&bridge_lock);
> return bridge;
> }
> diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> index 4bd94b167d2c..557e0079c98d 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> @@ -377,8 +377,10 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
> }
> if (lvds->panel)
> remote = lvds->panel->dev->of_node;
> - else
> + else if (lvds->bridge->of_node)
> remote = lvds->bridge->of_node;
> + else
> + remote = lvds->bridge->odev->of_node;
I guess odev should be NULL here, or have I missed something.
Regards
Andrzej
> if (of_property_read_string(dev->of_node, "rockchip,output", &name))
> /* default set it as output rgb */
> lvds->output = DISPLAY_OUTPUT_RGB;
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 3270fec46979..7c17977c3537 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -254,6 +254,7 @@ struct drm_bridge_timings {
>
> /**
> * struct drm_bridge - central DRM bridge control structure
> + * @odev: device that owns the bridge
> * @dev: DRM device this bridge belongs to
> * @encoder: encoder to which this bridge is connected
> * @next: the next bridge in the encoder chain
> @@ -265,6 +266,7 @@ struct drm_bridge_timings {
> * @driver_private: pointer to the bridge driver's internal context
> */
> struct drm_bridge {
> + struct device *odev;
> struct drm_device *dev;
> struct drm_encoder *encoder;
> struct drm_bridge *next;
^ permalink raw reply
* [PATCH v2] mtd: nxp-spifi: release flash_np in nxp_spifi_probe()
From: Boris Brezillon @ 2018-05-09 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525877806-21148-1-git-send-email-khoroshilov@ispras.ru>
On Wed, 9 May 2018 17:56:46 +0300
Alexey Khoroshilov <khoroshilov@ispras.ru> wrote:
> nxp_spifi_probe() increments refcnt of SPI flash device node by
> of_get_next_available_child() and leaves it undecremented on both
> successful and error paths.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
> ---
> drivers/mtd/spi-nor/nxp-spifi.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/nxp-spifi.c b/drivers/mtd/spi-nor/nxp-spifi.c
> index 15374216d4d9..7b047951d0a2 100644
> --- a/drivers/mtd/spi-nor/nxp-spifi.c
> +++ b/drivers/mtd/spi-nor/nxp-spifi.c
> @@ -438,11 +438,15 @@ static int nxp_spifi_probe(struct platform_device *pdev)
> ret = nxp_spifi_setup_flash(spifi, flash_np);
Just put the of_node_put() here and that's the only change you'll need.
> if (ret) {
> dev_err(&pdev->dev, "unable to setup flash chip\n");
> - goto dis_clks;
> + goto put_np;
> }
>
> + of_node_put(flash_np);
> +
> return 0;
>
> +put_np:
> + of_node_put(flash_np);
> dis_clks:
> clk_disable_unprepare(spifi->clk_spifi);
> dis_clk_reg:
^ permalink raw reply
* [PATCH v2] mtd: nxp-spifi: release flash_np in nxp_spifi_probe()
From: Alexey Khoroshilov @ 2018-05-09 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509163920.67a5f203@bbrezillon>
nxp_spifi_probe() increments refcnt of SPI flash device node by
of_get_next_available_child() and leaves it undecremented on both
successful and error paths.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
drivers/mtd/spi-nor/nxp-spifi.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/nxp-spifi.c b/drivers/mtd/spi-nor/nxp-spifi.c
index 15374216d4d9..7b047951d0a2 100644
--- a/drivers/mtd/spi-nor/nxp-spifi.c
+++ b/drivers/mtd/spi-nor/nxp-spifi.c
@@ -438,11 +438,15 @@ static int nxp_spifi_probe(struct platform_device *pdev)
ret = nxp_spifi_setup_flash(spifi, flash_np);
if (ret) {
dev_err(&pdev->dev, "unable to setup flash chip\n");
- goto dis_clks;
+ goto put_np;
}
+ of_node_put(flash_np);
+
return 0;
+put_np:
+ of_node_put(flash_np);
dis_clks:
clk_disable_unprepare(spifi->clk_spifi);
dis_clk_reg:
--
2.7.4
^ permalink raw reply related
* [PATCH] mtd: nxp-spifi: decrement flash_np refcnt on error paths
From: Boris Brezillon @ 2018-05-09 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <04eca940-cf53-d365-9899-336eb213e089@ispras.ru>
On Wed, 9 May 2018 17:35:41 +0300
Alexey Khoroshilov <khoroshilov@ispras.ru> wrote:
> On 09.05.2018 12:42, Boris Brezillon wrote:
> > On Tue, 8 May 2018 23:47:36 +0300
> > Alexey Khoroshilov <khoroshilov@ispras.ru> wrote:
> >
> >> nxp_spifi_probe() increments refcnt of SPI flash device node by
> >> of_get_next_available_child() and then it passes the node
> >> to mtd device in nxp_spifi_setup_flash().
> >> But if a failure happens before mtd_device_register() succeed,
> >> the refcnt is left undecremented.
> >
> > Why not doing that in the error path of the probe function? Also, you
> > probably want to call of_node_put() in the ->remove() function.
> >
>
>
> You are right.
>
> I believed that after successful mtd_device_register()
> the node is managed by mtd device. I missed that it calls of_node_get()
> in add_mtd_device() by itself.
>
> I will prepare v2.
> But I guess there is no need to have of_node_put() in ->remove(), since
> probe() finishes its own usage of flash_np, while mtd_device incremented
> refcnt by itself and will decrement it in ->remove() in
> mtd_device_unregister(&spifi->nor.mtd). So, I would propose
> of_node_put() on both successful and error path.
Sounds good.
^ permalink raw reply
* [PATCH 0/8] ARM: dts: renesas: Add PMU device nodes
From: Geert Uytterhoeven @ 2018-05-09 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
On Mon, May 7, 2018 at 3:56 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> This patch series enables support for the ARM Performance Monitor Units
> in Cortex-A7, Cortex-A9, and Cortex-A15 CPU cores on Renesas RZ/A1,
> R-Car Gen2, and RZ/G1 SoCs. This allows for better performance analysis
> using the "perf" tool.
[...]
> This has been tested on r8a7791/koelsch, and boot-tested on
> r7s72100/genmai, r8a7790/lager, r8a7792/blanche, and r8a7794/silk.
... and r8a7793/gose and r8a7794/alt.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] mtd: nxp-spifi: decrement flash_np refcnt on error paths
From: Alexey Khoroshilov @ 2018-05-09 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509114250.120eb299@bbrezillon>
On 09.05.2018 12:42, Boris Brezillon wrote:
> On Tue, 8 May 2018 23:47:36 +0300
> Alexey Khoroshilov <khoroshilov@ispras.ru> wrote:
>
>> nxp_spifi_probe() increments refcnt of SPI flash device node by
>> of_get_next_available_child() and then it passes the node
>> to mtd device in nxp_spifi_setup_flash().
>> But if a failure happens before mtd_device_register() succeed,
>> the refcnt is left undecremented.
>
> Why not doing that in the error path of the probe function? Also, you
> probably want to call of_node_put() in the ->remove() function.
>
You are right.
I believed that after successful mtd_device_register()
the node is managed by mtd device. I missed that it calls of_node_get()
in add_mtd_device() by itself.
I will prepare v2.
But I guess there is no need to have of_node_put() in ->remove(), since
probe() finishes its own usage of flash_np, while mtd_device incremented
refcnt by itself and will decrement it in ->remove() in
mtd_device_unregister(&spifi->nor.mtd). So, I would propose
of_node_put() on both successful and error path.
Thank you,
Alexey
^ permalink raw reply
* [PATCH]irqchip/irq-gic-v3:Avoid a waste of LPI resource
From: Mark Langsdorf @ 2018-05-09 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8898674D84E3B24BA3A2D289B872026A69EF9AF9@G01JPEXMBKW03>
On 04/30/2018 02:53 AM, Zhang, Lei wrote:
> Hi Marc
>
> thanks for your opinions.
>
>> How many is many? Are they PCI? Or something else?
>
>> As it is, this patch will break Multi-MSI and some other platforms that
>> do require a higher allocation granule.
>>
>> Depending on whether you're using PCI or some other bus, we can probably
>> come up with a solution that works for everyone. But I need more
>> information on this.
>
> Actually it is our original interconnect device not on PCI but on our original bus.
> This device has many sub devices around one thousand, and each sub device requires only a few LPIs.
>
> As I explained in point1, each Device ID can still allocate enough LPIs more than IRQS_PER_CHUNK by increasing chunks.
> So I couldn't understand why this patch will break Multi-MSI.
>
> By the way, 32 seems a good default value for IRQS_PER_CHUNK.
> So, I want to write another patch to make IRQ_PER_CHUNK a variable which can be changed by kernel parameter.
> What do you think of this idea?
If you intend your devices to be supported by server distributions,
instead of embedded kernels, having IRQ_PER_CHUNK as a kernel parameter
is not a good idea. The server distributions are going to compile, test,
and support a single kernel for all server systems, and are not going to
have a special kernel to support one vendor's systems that has a
different IRQ_PER_CHUNK parameter.
So even if you wrote that patch and it was accepted into the kernel, the
server distribution kernels are still going to set IRQ_PER_CHUNK to 32.
Marc's suggestion of implementing a glue layer, and then changing the
glue layer interface to pass the allocation requirements up to this
driver is the best solution that can be supported for server products.
--Mark Langsdorf
^ permalink raw reply
* [PATCH] arm64: defconfig: enable rockchip efuse
From: Heiko Stuebner @ 2018-05-09 14:32 UTC (permalink / raw)
To: linux-arm-kernel
The efuses on Rockchip socs often contain informations
about specifics of the chip its running on (leakage currents etc)
which components might want to read to adjust settings accordingly.
So enable the efuse early for that.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 34037d24fbf4..74abf140e332 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -612,6 +612,7 @@ CONFIG_QCOM_L2_PMU=y
CONFIG_QCOM_L3_PMU=y
CONFIG_MESON_EFUSE=m
CONFIG_QCOM_QFPROM=y
+CONFIG_ROCKCHIP_EFUSE=y
CONFIG_UNIPHIER_EFUSE=y
CONFIG_TEE=y
CONFIG_OPTEE=y
--
2.16.2
^ permalink raw reply related
* [PATCH v2 2/6] arm64: alternative: Apply alternatives early in boot process
From: Daniel Thompson @ 2018-05-09 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c935a9e6-94a0-03cb-eb64-7e2eef8f8d86@arm.com>
On Fri, May 04, 2018 at 11:06:56AM +0100, Julien Thierry wrote:
> Hi,
>
> In order to prepare the v3 of this patchset, I'd like people's opinion on
> what this patch does. More below.
>
> On 17/01/18 11:54, Julien Thierry wrote:
> > From: Daniel Thompson <daniel.thompson@linaro.org>
> >
> > Currently alternatives are applied very late in the boot process (and
> > a long time after we enable scheduling). Some alternative sequences,
> > such as those that alter the way CPU context is stored, must be applied
> > much earlier in the boot sequence.
> >
> > Introduce apply_alternatives_early() to allow some alternatives to be
> > applied immediately after we detect the CPU features of the boot CPU.
> >
> > Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
> > Signed-off-by: Julien Thierry <julien.thierry@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > ---
> > arch/arm64/include/asm/alternative.h | 1 +
> > arch/arm64/kernel/alternative.c | 39 +++++++++++++++++++++++++++++++++---
> > arch/arm64/kernel/smp.c | 6 ++++++
> > 3 files changed, 43 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
> > index 4a85c69..1fc1cdb 100644
> > --- a/arch/arm64/include/asm/alternative.h
> > +++ b/arch/arm64/include/asm/alternative.h
> > @@ -20,6 +20,7 @@ struct alt_instr {
> > u8 alt_len; /* size of new instruction(s), <= orig_len */
> > };
> >
> > +void __init apply_alternatives_early(void);
> > void __init apply_alternatives_all(void);
> > void apply_alternatives(void *start, size_t length);
> >
> > diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
> > index 6dd0a3a3..78051d4 100644
> > --- a/arch/arm64/kernel/alternative.c
> > +++ b/arch/arm64/kernel/alternative.c
> > @@ -28,6 +28,18 @@
> > #include <asm/sections.h>
> > #include <linux/stop_machine.h>
> >
> > +/*
> > + * early-apply features are detected using only the boot CPU and checked on
> > + * secondary CPUs startup, even then,
> > + * These early-apply features should only include features where we must
> > + * patch the kernel very early in the boot process.
> > + *
> > + * Note that the cpufeature logic *must* be made aware of early-apply
> > + * features to ensure they are reported as enabled without waiting
> > + * for other CPUs to boot.
> > + */
> > +#define EARLY_APPLY_FEATURE_MASK BIT(ARM64_HAS_SYSREG_GIC_CPUIF)
> > +
>
> Following the change in the cpufeature infrastructure,
> ARM64_HAS_SYSREG_GIC_CPUIF will have the scope ARM64_CPUCAP_SCOPE_BOOT_CPU
> in order to be checked early in the boot process.
>
> Now, regarding the early application of alternative, I am wondering whether
> we can apply all the alternatives associated with SCOPE_BOOT features that
> *do not* have a cpu_enable callback.
>
> Otherwise we can keep the macro to list individually each feature that is
> patchable at boot time as the current patch does (or put this info in a flag
> within the arm64_cpu_capabilities structure).
>
> Any thoughts or preferences on this?
If I understand ARM64_CPUCAP_SCOPE_BOOT_CPU correctly it certainly seems
safe to apply the alternatives early (it means that a CPU that
contradicts a CSCOPE_BOOT_CPU won't be allowed to join the system,
right?).
It also makes the system to apply errata fixes more powerful: maybe a
future errata must be applied before we commence threading.
This I have a preference for striping this out and relying on
SCOPE_BOOT_CPU instead. It's a weak preference though since I haven't
studied exactly what errate fixes this will bring into the scope of
early boot.
I don't think you'll regret changing it. This patch has always been
a *total* PITA to rebase so aligning it better with upstream will make
it easier to nurse the patch set until the if-and-when point it hits
the upstream.
Daniel.
> Thanks,
>
> > #define __ALT_PTR(a,f) ((void *)&(a)->f + (a)->f)
> > #define ALT_ORIG_PTR(a) __ALT_PTR(a, orig_offset)
> > #define ALT_REPL_PTR(a) __ALT_PTR(a, alt_offset)
> > @@ -105,7 +117,8 @@ static u32 get_alt_insn(struct alt_instr *alt, __le32 *insnptr, __le32 *altinsnp
> > return insn;
> > }
> >
> > -static void __apply_alternatives(void *alt_region, bool use_linear_alias)
> > +static void __apply_alternatives(void *alt_region, bool use_linear_alias,
> > + unsigned long feature_mask)
> > {
> > struct alt_instr *alt;
> > struct alt_region *region = alt_region;
> > @@ -115,6 +128,9 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
> > u32 insn;
> > int i, nr_inst;
> >
> > + if ((BIT(alt->cpufeature) & feature_mask) == 0)
> > + continue;
> > +
> > if (!cpus_have_cap(alt->cpufeature))
> > continue;
> >
> > @@ -138,6 +154,21 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
> > }
> >
> > /*
> > + * This is called very early in the boot process (directly after we run
> > + * a feature detect on the boot CPU). No need to worry about other CPUs
> > + * here.
> > + */
> > +void apply_alternatives_early(void)
> > +{
> > + struct alt_region region = {
> > + .begin = (struct alt_instr *)__alt_instructions,
> > + .end = (struct alt_instr *)__alt_instructions_end,
> > + };
> > +
> > + __apply_alternatives(®ion, true, EARLY_APPLY_FEATURE_MASK);
> > +}
> > +
> > +/*
> > * We might be patching the stop_machine state machine, so implement a
> > * really simple polling protocol here.
> > */
> > @@ -156,7 +187,9 @@ static int __apply_alternatives_multi_stop(void *unused)
> > isb();
> > } else {
> > BUG_ON(patched);
> > - __apply_alternatives(®ion, true);
> > +
> > + __apply_alternatives(®ion, true, ~EARLY_APPLY_FEATURE_MASK);
> > +
> > /* Barriers provided by the cache flushing */
> > WRITE_ONCE(patched, 1);
> > }
> > @@ -177,5 +210,5 @@ void apply_alternatives(void *start, size_t length)
> > .end = start + length,
> > };
> >
> > - __apply_alternatives(®ion, false);
> > + __apply_alternatives(®ion, false, -1);
> > }
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index 551eb07..37361b5 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -453,6 +453,12 @@ void __init smp_prepare_boot_cpu(void)
> > * cpuinfo_store_boot_cpu() above.
> > */
> > update_cpu_errata_workarounds();
> > + /*
> > + * We now know enough about the boot CPU to apply the
> > + * alternatives that cannot wait until interrupt handling
> > + * and/or scheduling is enabled.
> > + */
> > + apply_alternatives_early();
> > }
> >
> > static u64 __init of_get_cpu_mpidr(struct device_node *dn)
> > --
> > 1.9.1
> >
>
> --
> Julien Thierry
^ permalink raw reply
* [PATCH] clk: imx6ull: use OSC clock during AXI rate change
From: Stefan Agner @ 2018-05-09 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB3113135433766196E708685887990@HE1PR04MB3113.eurprd04.prod.outlook.com>
On 09.05.2018 03:26, Jacky Bai wrote:
>> Subject: Re: [PATCH] clk: imx6ull: use OSC clock during AXI rate change
>>
>> Quoting Stefan Agner (2018-05-08 06:20:03)
>> > On 08.05.2018 09:32, Jacky Bai wrote:
>> > >
>> > > I have tried two 6ULL board, I don't meet such issue. System can
>> > > boot up successfully with commit 6f9575e55632 included.
>> > > Anyway, the change in this patch is ok for me. it is no harm to the
>> > > BUS clock change flow.
>> >
>> > Hm, that is interesting, maybe it is because we use a different SKU?
>> > Or maybe bootloader?
>> >
>> > I tested here with a 800 MHz clocked variant on a Colibri iMX6ULL
>> > using U-Boot 2016.11.
>> >
>>
>> I'll throw this into fixes today because it fixes something to be useful. It's still
>> interesting to see what's different between the two setups though.
>
> Thanks.
>
> I will find some 800MHz parts and have a try with different bootloader later.
> Will let you know, when I have some results.
>
FWIW, I tried two SKUs here:
MCIMX6Z2DVM05AA (528Mhz)
MCIMX6Z2CVM08AA (800MHz)
Both run at 396MHz in U-Boot, and both freeze and the same location.
--
Stefan
^ permalink raw reply
* [xlnx:xlnx_rebase_v4.14 809/917] drivers/ptp/ptp_clock.c:274: undefined reference to `posix_clock_register'
From: kbuild test robot @ 2018-05-09 13:55 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.14
head: a24ae3acb778c948234fa8f227bacd818034055d
commit: b1b0dab4c89c1a42e4108cef8aa118373302b33d [809/917] net: macb: Select PTP_1588_CLOCK in Kconfig
config: i386-randconfig-i1-201818 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout b1b0dab4c89c1a42e4108cef8aa118373302b33d
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/ptp/ptp_clock.o: In function `ptp_clock_register':
>> drivers/ptp/ptp_clock.c:274: undefined reference to `posix_clock_register'
drivers/ptp/ptp_clock.o: In function `ptp_clock_unregister':
>> drivers/ptp/ptp_clock.c:320: undefined reference to `posix_clock_unregister'
vim +274 drivers/ptp/ptp_clock.c
d94ba80e Richard Cochran 2011-04-22 202
1ef76158 Richard Cochran 2012-09-22 203 struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info,
1ef76158 Richard Cochran 2012-09-22 204 struct device *parent)
d94ba80e Richard Cochran 2011-04-22 205 {
d94ba80e Richard Cochran 2011-04-22 206 struct ptp_clock *ptp;
d94ba80e Richard Cochran 2011-04-22 207 int err = 0, index, major = MAJOR(ptp_devt);
d94ba80e Richard Cochran 2011-04-22 208
d94ba80e Richard Cochran 2011-04-22 209 if (info->n_alarm > PTP_MAX_ALARMS)
d94ba80e Richard Cochran 2011-04-22 210 return ERR_PTR(-EINVAL);
d94ba80e Richard Cochran 2011-04-22 211
d94ba80e Richard Cochran 2011-04-22 212 /* Initialize a clock structure. */
d94ba80e Richard Cochran 2011-04-22 213 err = -ENOMEM;
d94ba80e Richard Cochran 2011-04-22 214 ptp = kzalloc(sizeof(struct ptp_clock), GFP_KERNEL);
d94ba80e Richard Cochran 2011-04-22 215 if (ptp == NULL)
d94ba80e Richard Cochran 2011-04-22 216 goto no_memory;
d94ba80e Richard Cochran 2011-04-22 217
7356a764 Jiri Benc 2013-04-12 218 index = ida_simple_get(&ptp_clocks_map, 0, MINORMASK + 1, GFP_KERNEL);
7356a764 Jiri Benc 2013-04-12 219 if (index < 0) {
7356a764 Jiri Benc 2013-04-12 220 err = index;
7356a764 Jiri Benc 2013-04-12 221 goto no_slot;
7356a764 Jiri Benc 2013-04-12 222 }
7356a764 Jiri Benc 2013-04-12 223
d94ba80e Richard Cochran 2011-04-22 224 ptp->clock.ops = ptp_clock_ops;
d94ba80e Richard Cochran 2011-04-22 225 ptp->clock.release = delete_ptp_clock;
d94ba80e Richard Cochran 2011-04-22 226 ptp->info = info;
d94ba80e Richard Cochran 2011-04-22 227 ptp->devid = MKDEV(major, index);
d94ba80e Richard Cochran 2011-04-22 228 ptp->index = index;
d94ba80e Richard Cochran 2011-04-22 229 spin_lock_init(&ptp->tsevq.lock);
d94ba80e Richard Cochran 2011-04-22 230 mutex_init(&ptp->tsevq_mux);
6092315d Richard Cochran 2014-03-20 231 mutex_init(&ptp->pincfg_mux);
d94ba80e Richard Cochran 2011-04-22 232 init_waitqueue_head(&ptp->tsev_wq);
d94ba80e Richard Cochran 2011-04-22 233
d9535cb7 Grygorii Strashko 2017-07-28 234 if (ptp->info->do_aux_work) {
d9535cb7 Grygorii Strashko 2017-07-28 235 char *worker_name = kasprintf(GFP_KERNEL, "ptp%d", ptp->index);
d9535cb7 Grygorii Strashko 2017-07-28 236
d9535cb7 Grygorii Strashko 2017-07-28 237 kthread_init_delayed_work(&ptp->aux_work, ptp_aux_kworker);
d9535cb7 Grygorii Strashko 2017-07-28 238 ptp->kworker = kthread_create_worker(0, worker_name ?
d9535cb7 Grygorii Strashko 2017-07-28 239 worker_name : info->name);
d9535cb7 Grygorii Strashko 2017-07-28 240 kfree(worker_name);
d9535cb7 Grygorii Strashko 2017-07-28 241 if (IS_ERR(ptp->kworker)) {
d9535cb7 Grygorii Strashko 2017-07-28 242 err = PTR_ERR(ptp->kworker);
d9535cb7 Grygorii Strashko 2017-07-28 243 pr_err("failed to create ptp aux_worker %d\n", err);
d9535cb7 Grygorii Strashko 2017-07-28 244 goto kworker_err;
d9535cb7 Grygorii Strashko 2017-07-28 245 }
d9535cb7 Grygorii Strashko 2017-07-28 246 }
d9535cb7 Grygorii Strashko 2017-07-28 247
85a66e55 Dmitry Torokhov 2017-02-14 248 err = ptp_populate_pin_groups(ptp);
85a66e55 Dmitry Torokhov 2017-02-14 249 if (err)
85a66e55 Dmitry Torokhov 2017-02-14 250 goto no_pin_groups;
85a66e55 Dmitry Torokhov 2017-02-14 251
d94ba80e Richard Cochran 2011-04-22 252 /* Create a new device in our class. */
85a66e55 Dmitry Torokhov 2017-02-14 253 ptp->dev = device_create_with_groups(ptp_class, parent, ptp->devid,
85a66e55 Dmitry Torokhov 2017-02-14 254 ptp, ptp->pin_attr_groups,
d94ba80e Richard Cochran 2011-04-22 255 "ptp%d", ptp->index);
d94ba80e Richard Cochran 2011-04-22 256 if (IS_ERR(ptp->dev))
d94ba80e Richard Cochran 2011-04-22 257 goto no_device;
d94ba80e Richard Cochran 2011-04-22 258
d94ba80e Richard Cochran 2011-04-22 259 /* Register a new PPS source. */
d94ba80e Richard Cochran 2011-04-22 260 if (info->pps) {
d94ba80e Richard Cochran 2011-04-22 261 struct pps_source_info pps;
d94ba80e Richard Cochran 2011-04-22 262 memset(&pps, 0, sizeof(pps));
d94ba80e Richard Cochran 2011-04-22 263 snprintf(pps.name, PPS_MAX_NAME_LEN, "ptp%d", index);
d94ba80e Richard Cochran 2011-04-22 264 pps.mode = PTP_PPS_MODE;
d94ba80e Richard Cochran 2011-04-22 265 pps.owner = info->owner;
d94ba80e Richard Cochran 2011-04-22 266 ptp->pps_source = pps_register_source(&pps, PTP_PPS_DEFAULTS);
d94ba80e Richard Cochran 2011-04-22 267 if (!ptp->pps_source) {
d94ba80e Richard Cochran 2011-04-22 268 pr_err("failed to register pps source\n");
d94ba80e Richard Cochran 2011-04-22 269 goto no_pps;
d94ba80e Richard Cochran 2011-04-22 270 }
d94ba80e Richard Cochran 2011-04-22 271 }
d94ba80e Richard Cochran 2011-04-22 272
d94ba80e Richard Cochran 2011-04-22 273 /* Create a posix clock. */
d94ba80e Richard Cochran 2011-04-22 @274 err = posix_clock_register(&ptp->clock, ptp->devid);
d94ba80e Richard Cochran 2011-04-22 275 if (err) {
d94ba80e Richard Cochran 2011-04-22 276 pr_err("failed to create posix clock\n");
d94ba80e Richard Cochran 2011-04-22 277 goto no_clock;
d94ba80e Richard Cochran 2011-04-22 278 }
d94ba80e Richard Cochran 2011-04-22 279
d94ba80e Richard Cochran 2011-04-22 280 return ptp;
d94ba80e Richard Cochran 2011-04-22 281
d94ba80e Richard Cochran 2011-04-22 282 no_clock:
d94ba80e Richard Cochran 2011-04-22 283 if (ptp->pps_source)
d94ba80e Richard Cochran 2011-04-22 284 pps_unregister_source(ptp->pps_source);
d94ba80e Richard Cochran 2011-04-22 285 no_pps:
d94ba80e Richard Cochran 2011-04-22 286 device_destroy(ptp_class, ptp->devid);
d94ba80e Richard Cochran 2011-04-22 287 no_device:
85a66e55 Dmitry Torokhov 2017-02-14 288 ptp_cleanup_pin_groups(ptp);
85a66e55 Dmitry Torokhov 2017-02-14 289 no_pin_groups:
d9535cb7 Grygorii Strashko 2017-07-28 290 if (ptp->kworker)
d9535cb7 Grygorii Strashko 2017-07-28 291 kthread_destroy_worker(ptp->kworker);
d9535cb7 Grygorii Strashko 2017-07-28 292 kworker_err:
d94ba80e Richard Cochran 2011-04-22 293 mutex_destroy(&ptp->tsevq_mux);
6092315d Richard Cochran 2014-03-20 294 mutex_destroy(&ptp->pincfg_mux);
b9118b72 Christophe Jaillet 2016-10-02 295 ida_simple_remove(&ptp_clocks_map, index);
7356a764 Jiri Benc 2013-04-12 296 no_slot:
d94ba80e Richard Cochran 2011-04-22 297 kfree(ptp);
d94ba80e Richard Cochran 2011-04-22 298 no_memory:
d94ba80e Richard Cochran 2011-04-22 299 return ERR_PTR(err);
d94ba80e Richard Cochran 2011-04-22 300 }
d94ba80e Richard Cochran 2011-04-22 301 EXPORT_SYMBOL(ptp_clock_register);
d94ba80e Richard Cochran 2011-04-22 302
d94ba80e Richard Cochran 2011-04-22 303 int ptp_clock_unregister(struct ptp_clock *ptp)
d94ba80e Richard Cochran 2011-04-22 304 {
d94ba80e Richard Cochran 2011-04-22 305 ptp->defunct = 1;
d94ba80e Richard Cochran 2011-04-22 306 wake_up_interruptible(&ptp->tsev_wq);
d94ba80e Richard Cochran 2011-04-22 307
d9535cb7 Grygorii Strashko 2017-07-28 308 if (ptp->kworker) {
d9535cb7 Grygorii Strashko 2017-07-28 309 kthread_cancel_delayed_work_sync(&ptp->aux_work);
d9535cb7 Grygorii Strashko 2017-07-28 310 kthread_destroy_worker(ptp->kworker);
d9535cb7 Grygorii Strashko 2017-07-28 311 }
d9535cb7 Grygorii Strashko 2017-07-28 312
d94ba80e Richard Cochran 2011-04-22 313 /* Release the clock's resources. */
d94ba80e Richard Cochran 2011-04-22 314 if (ptp->pps_source)
d94ba80e Richard Cochran 2011-04-22 315 pps_unregister_source(ptp->pps_source);
85a66e55 Dmitry Torokhov 2017-02-14 316
d94ba80e Richard Cochran 2011-04-22 317 device_destroy(ptp_class, ptp->devid);
85a66e55 Dmitry Torokhov 2017-02-14 318 ptp_cleanup_pin_groups(ptp);
d94ba80e Richard Cochran 2011-04-22 319
d94ba80e Richard Cochran 2011-04-22 @320 posix_clock_unregister(&ptp->clock);
d94ba80e Richard Cochran 2011-04-22 321 return 0;
d94ba80e Richard Cochran 2011-04-22 322 }
d94ba80e Richard Cochran 2011-04-22 323 EXPORT_SYMBOL(ptp_clock_unregister);
d94ba80e Richard Cochran 2011-04-22 324
:::::: The code at line 274 was first introduced by commit
:::::: d94ba80ebbea17f036cecb104398fbcd788aa742 ptp: Added a brand new class driver for ptp clocks.
:::::: TO: Richard Cochran <richardcochran@gmail.com>
:::::: CC: John Stultz <john.stultz@linaro.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 33833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180509/bf7d5c28/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2] arm64: dts: r8a77965: Add SDHI device nodes
From: Geert Uytterhoeven @ 2018-05-09 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525869504-3361-1-git-send-email-ykaneko0929@gmail.com>
Hi Kaneko-san,
On Wed, May 9, 2018 at 2:38 PM, Yoshihiro Kaneko <ykaneko0929@gmail.com> wrote:
> From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
>
> Add SDHI nodes to the DT of the r8a77965 SoC.
>
> Based on several similar patches of the R8A7796 device tree
> by Simon Horman <horms+renesas@verge.net.au>.
>
> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
> ---
>
> This patch is based on the devel branch of Simon Horman's renesas tree.
>
> v2 [Yoshihiro Kaneko]
> * As suggested by Simon Horman
> Rebased on top of the devel branch of the renesas tree.
Thanks for the update!
> arch/arm64/boot/dts/renesas/r8a77965.dtsi | 36 +++++++++++++++++++++++++++----
> 1 file changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> index ba0edda..510815e 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> @@ -978,23 +978,51 @@
> };
>
> sdhi0: sd at ee100000 {
> + compatible = "renesas,sdhi-r8a77965",
> + "renesas,rcar-gen3-sdhi";
> reg = <0 0xee100000 0 0x2000>;
> - /* placeholder */
> + interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 314>;
> + max-frequency = <200000000>;
> + power-domains = <&sysc 32>;
In the mean time, <dt-bindings/power/r8a77965-sysc.h> has landed
upstream, so please use R8A77965_PD_ALWAYS_ON.
With the above fixed:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/4] amba: Export amba_bustype
From: Robin Murphy @ 2018-05-09 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508140628.f30774c70c4c481bff3f8000@arm.com>
Hi Kim,
On 08/05/18 20:06, Kim Phillips wrote:
> This patch is provided in the context of allowing the Coresight driver
> subsystem to be loaded as modules. Coresight uses amba_bus in its call
> to bus_find_device() in of_coresight_get_endpoint_device() when
> searching for a configurable endpoint device. This patch allows
> Coresight to reference amba_bustype when built as a module.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Alex Williamson <alex.williamson@redhat.com>
> Cc: Eric Auger <eric.auger@redhat.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Todd Kjos <tkjos@google.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Thierry Reding <treding@nvidia.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Kim Phillips <kim.phillips@arm.com>
> ---
> There was a prior patch submitted by Alex W. here:
>
> https://lkml.org/lkml/2017/6/19/811
>
> But I can't tell its fate - presume simply delayed?
>
> Coresight uses amba_bus in its call to bus_find_device() here:
>
> https://lxr.missinglinkelectronics.com/linux/drivers/hwtracing/coresight/of_coresight.c#L51
>
> Grepping for bus_type and EXPORT shows other busses exporting their
> type, so I don't think this is the wrong approach. If, OTOH, Coresight
> needs to do something differently, please comment.
Exposing raw bus_types is pretty ugly, but it is indeed the status quo,
so this probably is the reasonable thing to do. I suppose an amba_bus
equivalent of of_find_device_by_node() could be implemented, but for
only a single potential user that doesn't seem particularly worthwhile,
since unless some massive shake-up of how buses work comes along the
bus_type will inevitably end up being exported for other reasons anyway.
So, in the context of this series;
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
However, as a wild idea for sidestepping the issue completely (or at
least keeping it within the CoreSight framework), at first glance it
appears something like the below might be feasible, although I may well
be missing some obvious reason why not.
Thanks,
Robin.
----->8-----
diff --git a/drivers/hwtracing/coresight/of_coresight.c
b/drivers/hwtracing/coresight/of_coresight.c
index 7c375443ede6..2c3fdc9b63e6 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -27,28 +27,13 @@
static int of_dev_node_match(struct device *dev, void *data)
{
- return dev->of_node == data;
+ return dev->parent->of_node == data;
}
static struct device *
of_coresight_get_endpoint_device(struct device_node *endpoint)
{
- struct device *dev = NULL;
-
- /*
- * If we have a non-configurable replicator, it will be found on the
- * platform bus.
- */
- dev = bus_find_device(&platform_bus_type, NULL,
- endpoint, of_dev_node_match);
- if (dev)
- return dev;
-
- /*
- * We have a configurable component - circle through the AMBA bus
- * looking for the device that matches the endpoint node.
- */
- return bus_find_device(&amba_bustype, NULL,
+ return bus_find_device(&coresight_bustype, NULL,
endpoint, of_dev_node_match);
}
^ 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