* [PATCH] ARM: dts: vf610-zii-scu4-aib: Drop "rs485-rts-delay" property
From: Andrey Smirnov @ 2019-08-20 3:13 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Andrey Smirnov, Fabio Estevam, Shawn Guo, linux-kernel,
Chris Healy
LPUART driver does not support specifying "rs485-rts-delay"
property. Drop it.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/boot/dts/vf610-zii-scu4-aib.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
index 666ec27a73e3..d8c38ef6a98a 100644
--- a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
+++ b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
@@ -685,7 +685,6 @@
linux,rs485-enabled-at-boot-time;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
- rs485-rts-delay = <0 200>;
status = "okay";
};
@@ -693,7 +692,6 @@
linux,rs485-enabled-at-boot-time;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart2>;
- rs485-rts-delay = <0 200>;
status = "okay";
};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] ARM: dts: vf610-zii-cfu1: Slow I2C0 down to 100kHz
From: Andrey Smirnov @ 2019-08-20 3:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Andrey Smirnov, Fabio Estevam, Shawn Guo, linux-kernel,
Chris Healy
Fiber-optic module attached to the bus is only rated to work at
100kHz, so drop the bus frequncy to accomodate that.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/boot/dts/vf610-zii-cfu1.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts b/arch/arm/boot/dts/vf610-zii-cfu1.dts
index ff460a1de85a..28732249cfc0 100644
--- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
+++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
@@ -207,7 +207,7 @@
};
&i2c0 {
- clock-frequency = <400000>;
+ clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c0>;
status = "okay";
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 0/9] Exynos Adaptive Supply Voltage support
From: Viresh Kumar @ 2019-08-20 3:01 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc, linux-pm, vireshk, b.zolnierkie,
linux-kernel, krzk, robh+dt, kgene, pankaj.dubey,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <b7093aaf-ea56-c390-781f-6f9d0780bd8e@samsung.com>
On 19-08-19, 15:39, Sylwester Nawrocki wrote:
> Unfortunately not, the patch set as I see it is another way of updating
> an OPP after it was parsed from DT. OPP remove/add could work equally
> well in our use case.
Adding OPPs dynamically has limitations, you can't set many values which are
otherwise possible with DT. And removing/adding is not the right thing to do
technically.
> The problem is that we have the information on how to translate the
> common OPP voltage to a voltage specific to given silicon encoded jointly
> in the ASV tables and the CHIPID registers (efuse/OTP memory).
> Additionally, algorithm of selecting ASV data (OPP voltage) based on
> the "key" data from registers is not generic, it is usually different
> per each SoC type.
>
> I tried to identify some patterns in those tables in order to simplify
> possible DT binding, but that was not really successful. I ended up just
> keeping whole tables.
Sorry but I am unable to understand the difficulty you are facing now. So what I
suggest is something like this.
- Use DT to get a frequency and voltage for each frequency.
- At runtime, based on SoC, registers, efuses, etc, update the voltage of the
OPPs.
- This algo can be different for each SoC, no one is stopping you from doing
that.
Am I missing something ?
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/1] arm64: dts: rockchip: Add support for TB-96AI board
From: Elon Zhang @ 2019-08-20 2:35 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: mark.rutland, devicetree, heiko, linux-kernel, linux-rockchip,
robh+dt, linux-arm-kernel
In-Reply-To: <20190805112810.GA19736@mani>
Hi Mani,
Thanks for your review. Please see comments inline.
在 8/5/2019 19:28, Manivannan Sadhasivam 写道:
> Hi Elon,
>
> Thanks for the v2. Still the DT needs to be cleaned up a bit. I have tested this
> patch on TB96-AI SOM/Carrier board and found that the USB ports are not working
> at all! Do we need to change any switch settings?
Yes. The USB ports can not work. I have already added all USB related
setting. I tried
rockchip internel rk3399.dtsi and the USB ports can work, so I think the
cause is SoC related
setting difference in mainline kernel.
I can not figure it out for now, should I remove the usb related node in
this patch?
>
> Comments are inline.
>
> On Mon, Aug 05, 2019 at 09:57:55AM +0800, Elon Zhang wrote:
>> Add devicetree support for RK3399Pro TB-96AI board, one of
>> the 96Boards family.
>>
>> The TB-96AI board is a 96Boards Compute SOM design, launched
>> by Linaro, Rockchip and Beiqicloud.
>>
>> More information can be obtained from the following websites:
>> 1.https://www.96boards.org/product/tb-96ai/
>> 2.http://t.rock-chips.com/
>> 3.http://www.beiqicloud.com/
>>
>> This patch add basic node for the board and support booting up
>> to Fedora.
>>
>> Signed-off-by: Elon Zhang <zhangzj@rock-chips.com>
>> ---
>> changes since v1:
>> - remove needless node
>> - using a standard LED formats for 96Boards
>>
>> arch/arm64/boot/dts/rockchip/Makefile | 1 +
>> .../boot/dts/rockchip/rk3399pro-tb-96ai.dts | 560 ++++++++++++++++++
>> 2 files changed, 561 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
>> index 5f2687acbf94..3d6c8d4363b5 100644
>> --- a/arch/arm64/boot/dts/rockchip/Makefile
>> +++ b/arch/arm64/boot/dts/rockchip/Makefile
>> @@ -27,3 +27,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
>> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-tb-96ai.dtb
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts b/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
>> new file mode 100644
>> index 000000000000..767b37b854ba
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
>> @@ -0,0 +1,560 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd.
>> + */
>> +
>> +/dts-v1/;
>> +#include "rk3399pro.dtsi"
>> +#include "rk3399-opp.dtsi"
>> +
>> +/ {
>> + compatible = "beiqi,rk3399pro-tb-96ai", "rockchip,rk3399pro";
>> +
>> + chosen {
>> + stdout-path = "serial2:1500000n8";
>> + };
>> +
>> + xin32k: xin32k {
>> + compatible = "fixed-clock";
>> + clock-frequency = <32768>;
>> + clock-output-names = "xin32k";
>> + #clock-cells = <0>;
>> + };
>> +
>> + vcc5v0_sys: vccsys {
>> + compatible = "regulator-fixed";
>> + regulator-name = "vcc5v0_sys";
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + };
>> +
>> + leds {
> Still the LEDs are not defined as per the format I shared before...
I am not very sure what the format exactly is. Is the LEDs format below
right?
49 leds {
50 compatible = "gpio-leds";
51 pinctrl-names = "default";
52 pinctrl-0 = <&user_led1>,<&user_led2>,<&user_led3>;
53
54 user_led1 {
55 label = "green:user1";
56 gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
57 retain-state-suspended;
58 };
59
60 user_led2 {
61 label = "green:user2";
62 gpios = <&gpio2 4 GPIO_ACTIVE_HIGH>;
63 retain-state-suspended;
64 };
65
66 user_led3 {
67 label = "green:user3";
68 gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
69 retain-state-suspended;
70 };
71 };
>
>> + compatible = "gpio-leds";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&work_led1>,<&work_led2>,<&work_led3>;
>> +
>> + work_led1 {
>> + gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
>> + label = "system_work_led1";
>> + retain-state-suspended;
>> + };
>> +
>> + work_led2 {
>> + gpios = <&gpio2 4 GPIO_ACTIVE_HIGH>;
>> + label = "system_work_led2";
>> + retain-state-suspended;
>> + };
>> +
>> + work_led3 {
>> + gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
>> + label = "system_work_led3";
>> + retain-state-suspended;
>> + };
>> + };
>> +};
>> +
>> +&cpu_l0 {
>> + cpu-supply = <&vdd_cpu_l>;
>> +};
>> +
>> +&cpu_l1 {
>> + cpu-supply = <&vdd_cpu_l>;
>> +};
>> +
>> +&cpu_l2 {
>> + cpu-supply = <&vdd_cpu_l>;
>> +};
>> +
>> +&cpu_l3 {
>> + cpu-supply = <&vdd_cpu_l>;
>> +};
>> +
>> +&cpu_b0 {
>> + cpu-supply = <&vdd_cpu_b>;
>> +};
>> +
>> +&cpu_b1 {
>> + cpu-supply = <&vdd_cpu_b>;
>> +};
>> +
>> +&emmc_phy {
>> + status = "okay";
>> +};
>> +
>> +&i2c0 {
>> + status = "okay";
>> + i2c-scl-rising-time-ns = <180>;
>> + i2c-scl-falling-time-ns = <30>;
>> + clock-frequency = <400000>;
>> +
>> + rk809: pmic@20 {
>> + compatible = "rockchip,rk809";
>> + reg = <0x20>;
>> + interrupt-parent = <&gpio1>;
>> + interrupts = <RK_PC2 IRQ_TYPE_LEVEL_LOW>;
>> + pinctrl-names = "default", "pmic-sleep",
>> + "pmic-power-off", "pmic-reset";
> Does these pinctrl configs useful other than default?
These pinctrl configs are used for sleep/wake. Since mainline MFD and
pinctrl driver
has no pinctrl support for RK809, these pinctrl configs will be removed
other than default.
>
>> + pinctrl-0 = <&pmic_int_l>;
>> + pinctrl-1 = <&soc_slppin_slp>, <&rk809_slppin_slp>;
>> + pinctrl-2 = <&soc_slppin_gpio>, <&rk809_slppin_pwrdn>;
>> + pinctrl-3 = <&soc_slppin_gpio>,<&rk809_slppin_null>;
>> + rockchip,system-power-controller;
>> + pmic-reset-func = <1>;
>> + wakeup-source;
>> + #clock-cells = <1>;
>> + clock-output-names = "rk808-clkout1", "rk808-clkout2";
>> +
>> + vcc1-supply = <&vcc5v0_sys>;
>> + vcc2-supply = <&vcc5v0_sys>;
>> + vcc3-supply = <&vcc5v0_sys>;
>> + vcc4-supply = <&vcc5v0_sys>;
>> + vcc5-supply = <&vcc_buck5>;
>> + vcc6-supply = <&vcc_buck5>;
>> + vcc7-supply = <&vcc3v3_sys>;
>> + vcc8-supply = <&vcc3v3_sys>;
>> + vcc9-supply = <&vcc5v0_sys>;
>> +
>> + pwrkey {
>> + status = "okay";
> No compatible needed?
No compatible needed. It is RK809 internel implement.
>
>> + };
>> +
>> + rtc {
>> + status = "okay";
> No compatible needed?
ditto.
>
>> + };
>> +
>> + pinctrl_rk8xx: pinctrl_rk8xx {
> Mainline MFD driver has no pinctrl support for RK809.
Yes. This node will be removed.
Thank,
Elon
>
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> +
>> + rk809_slppin_null: rk809_slppin_null {
>> + pins = "gpio_slp";
>> + function = "pin_fun0";
>> + };
>> +
>> + rk809_slppin_slp: rk809_slppin_slp {
>> + pins = "gpio_slp";
>> + function = "pin_fun1";
>> + };
>> +
>> + rk809_slppin_pwrdn: rk809_slppin_pwrdn {
>> + pins = "gpio_slp";
>> + function = "pin_fun2";
>> + };
>> +
>> + rk809_slppin_rst: rk809_slppin_rst {
>> + pins = "gpio_slp";
>> + function = "pin_fun3";
>> + };
>> + };
>> +
>> + regulators {
>> + vdd_center: DCDC_REG1 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <750000>;
>> + regulator-max-microvolt = <1350000>;
>> + regulator-initial-mode = <0x2>;
>> + regulator-name = "vdd_center";
> Please match the regulator names with schematic.
>
>> + regulator-state-mem {
>> + regulator-on-in-suspend;
>> + regulator-suspend-microvolt = <900000>;
>> + };
>> + };
>> +
>> + vdd_cpu_l: DCDC_REG2 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <750000>;
>> + regulator-max-microvolt = <1350000>;
>> + regulator-ramp-delay = <6001>;
>> + regulator-initial-mode = <0x2>;
>> + regulator-name = "vdd_cpu_l";
>> + regulator-state-mem {
>> + regulator-off-in-suspend;
>> + };
>> + };
>> +
>> + vcc_ddr: DCDC_REG3 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-name = "vcc_ddr";
>> + regulator-initial-mode = <0x2>;
>> + regulator-state-mem {
>> + regulator-on-in-suspend;
>> + };
>> + };
>> +
>> + vcc3v3_sys: DCDC_REG4 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-initial-mode = <0x2>;
>> + regulator-name = "vcc3v3_sys";
>> + regulator-state-mem {
>> + regulator-on-in-suspend;
>> + regulator-suspend-microvolt = <3300000>;
>> + };
>> + };
>> +
>> + vcc_buck5: DCDC_REG5 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <2200000>;
>> + regulator-max-microvolt = <2200000>;
>> + regulator-name = "vcc_buck5";
>> + regulator-state-mem {
>> + regulator-on-in-suspend;
>> + regulator-suspend-microvolt = <2200000>;
>> + };
>> + };
>> +
>> + vcca_0v9: LDO_REG1 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <900000>;
>> + regulator-max-microvolt = <900000>;
>> + regulator-name = "vcca_0v9";
>> + regulator-state-mem {
>> + regulator-off-in-suspend;
>> + };
>> + };
>> +
>> + vcc_1v8: LDO_REG2 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> +
>> + regulator-name = "vcc_1v8";
>> + regulator-state-mem {
>> + regulator-on-in-suspend;
>> + regulator-suspend-microvolt = <1800000>;
>> + };
>> + };
>> +
>> + vcc0v9_soc: LDO_REG3 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <900000>;
>> + regulator-max-microvolt = <900000>;
>> +
>> + regulator-name = "vcc0v9_soc";
>> + regulator-state-mem {
>> + regulator-on-in-suspend;
>> + regulator-suspend-microvolt = <900000>;
>> + };
>> + };
>> +
>> + vcca_1v8: LDO_REG4 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> +
>> + regulator-name = "vcca_1v8";
>> + regulator-state-mem {
>> + regulator-off-in-suspend;
>> + };
>> + };
>> +
>> + vdd1v5_dvp: LDO_REG5 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <1500000>;
>> + regulator-max-microvolt = <1500000>;
>> +
>> + regulator-name = "vdd1v5_dvp";
>> + regulator-state-mem {
>> + regulator-off-in-suspend;
>> + };
>> + };
>> +
>> + vcc_1v5: LDO_REG6 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <1500000>;
>> + regulator-max-microvolt = <1500000>;
>> +
>> + regulator-name = "vcc_1v5";
>> + regulator-state-mem {
>> + regulator-off-in-suspend;
>> + };
>> + };
>> +
>> + vcc_3v0: LDO_REG7 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <3000000>;
>> + regulator-max-microvolt = <3000000>;
>> +
>> + regulator-name = "vcc_3v0";
>> + regulator-state-mem {
>> + regulator-off-in-suspend;
>> + };
>> + };
>> +
>> + vccio_sd: LDO_REG8 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <3300000>;
>> +
>> + regulator-name = "vccio_sd";
>> + regulator-state-mem {
>> + regulator-on-in-suspend;
>> + regulator-suspend-microvolt = <3300000>;
>> + };
>> + };
>> +
>> + vcc_sd: LDO_REG9 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> +
>> + regulator-name = "vcc_sd";
>> + regulator-state-mem {
>> + regulator-on-in-suspend;
>> + regulator-suspend-microvolt = <3300000>;
>> + };
>> + };
>> +
>> + vcc5v0_usb: SWITCH_REG1 {
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> +
>> + regulator-name = "vcc5v0_usb";
>> + regulator-state-mem {
>> + regulator-off-in-suspend;
>> + };
>> + };
>> +
>> + vccio_3v3: SWITCH_REG2 {
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> +
>> + regulator-name = "vccio_3v3";
>> + regulator-state-mem {
>> + regulator-off-in-suspend;
>> + };
>> + };
>> + };
>> + };
>> +
>> + vdd_cpu_b: regulator@1c {
>> + compatible = "fcs,fan53555";
>> + reg = <0x1c>;
>> + vin-supply = <&vcc5v0_sys>;
>> + pinctrl-0 = <&vsel1_gpio>;
>> + vsel-gpios = <&gpio1 RK_PC1 GPIO_ACTIVE_HIGH>;
>> + regulator-name = "vdd_cpu_b";
>> + regulator-min-microvolt = <712500>;
>> + regulator-max-microvolt = <1500000>;
>> + regulator-ramp-delay = <2300>;
>> + fcs,suspend-voltage-selector = <1>;
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-initial-state = <3>;
>> + regulator-state-mem {
>> + regulator-off-in-suspend;
>> + };
>> + };
>> +
>> + vdd_gpu: regulator@10 {
>> + compatible = "fcs,fan53555";
>> + status = "okay";
>> + reg = <0x10>;
>> + vin-supply = <&vcc5v0_sys>;
>> + pinctrl-0 = <&vsel2_gpio>;
>> + vsel-gpios = <&gpio1 RK_PB6 GPIO_ACTIVE_HIGH>;
>> + regulator-name = "vdd_gpu";
>> + regulator-min-microvolt = <735000>;
>> + regulator-max-microvolt = <1400000>;
>> + regulator-ramp-delay = <2300>;
>> + fcs,suspend-voltage-selector = <1>;
>> + regulator-always-on;
>> + regulator-boot-on;
>> + regulator-state-mem {
>> + regulator-off-in-suspend;
>> + };
>> + };
>> +};
>> +
>> +&i2c8 {
>> + status = "okay";
>> + i2c-scl-rising-time-ns = <345>;
>> + i2c-scl-falling-time-ns = <11>;
>> + clock-frequency = <100000>;
>> +};
>> +
>> +&io_domains {
>> + status = "okay";
>> + bt656-supply = <&vcca_1v8>; /* APIO2_VDD */
>> + audio-supply = <&vcca_1v8>; /* APIO5_VDD */
>> + sdmmc-supply = <&vccio_sd>; /* SDMMC0_VDD */
>> + gpio1830-supply = <&vcc_1v8>; /* APIO4_VDD */
>> +};
>> +
>> +&pinctrl {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&npu_ref_clk>;
>> +
>> + leds {
>> + work_led1: work_led1 {
>> + rockchip,pins =
>> + <2 5 RK_FUNC_GPIO &pcfg_pull_none>;
>> + };
>> +
>> + work_led2: work_led2 {
>> + rockchip,pins =
>> + <2 4 RK_FUNC_GPIO &pcfg_pull_none>;
>> + };
>> +
>> + work_led3: work_led3 {
>> + rockchip,pins =
>> + <2 3 RK_FUNC_GPIO &pcfg_pull_none>;
>> + };
>> + };
>> +
>> + npu_clk {
>> + npu_ref_clk: npu-ref-clk {
>> + rockchip,pins =
>> + <0 RK_PA2 1 &pcfg_pull_none>;
>> + };
>> + };
>> +
>> + pmic {
>> + pmic_int_l: pmic-int-l {
>> + rockchip,pins =
>> + <1 RK_PC2 0 &pcfg_pull_up>;
>> + };
>> +
>> + soc_slppin_gpio: soc-slppin-gpio {
>> + rockchip,pins =
>> + <1 RK_PA5 0 &pcfg_output_low>;
>> + };
>> +
>> + soc_slppin_slp: soc-slppin-slp {
>> + rockchip,pins =
>> + <1 RK_PA5 1 &pcfg_pull_down>;
>> + };
>> +
>> + vsel1_gpio: vsel1-gpio {
>> + rockchip,pins =
>> + <1 RK_PC1 0 &pcfg_pull_down>;
>> + };
>> +
>> + vsel2_gpio: vsel2-gpio {
>> + rockchip,pins =
>> + <1 RK_PB6 0 &pcfg_pull_down>;
>> + };
>> + };
>> +
>> + usb3 {
>> + usb3_host_en: usb3-host-en {
>> + rockchip,pins =
>> + <2 RK_PA2 RK_FUNC_GPIO &pcfg_output_high>;
>> + };
>> + };
>> +};
>> +
>> +&pmu_io_domains {
>> + status = "okay";
>> + pmu1830-supply = <&vcc_1v8>;
>> +};
>> +
>> +&pwm0 {
>> + status = "okay";
>> +};
>> +
>> +&pwm2 {
>> + status = "okay";
>> +};
>> +
>> +&saradc {
>> + status = "okay";
>> + vref-supply = <&vcc_1v8>;
>> +};
>> +
>> +&sdhci {
>> + bus-width = <8>;
>> + mmc-hs400-1_8v;
>> + non-removable;
>> + keep-power-in-suspend;
>> + mmc-hs400-enhanced-strobe;
>> + status = "okay";
>> +};
>> +
>> +&tcphy1 {
> No tcphy0? I can see this used in schematics.
>
>> + status = "okay";
>> +};
>> +
>> +&tsadc {
>> + rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
>> + rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
>> + status = "okay";
>> +};
>> +
>> +&u2phy1 {
> No u2phy0?
>
>> + status = "okay";
>> +
>> + u2phy1_otg: otg-port {
>> + status = "okay";
>> + };
>> +
>> + u2phy1_host: host-port {
>> + phy-supply = <&vcc5v0_usb>;
>> + status = "okay";
>> + };
>> +};
>> +
>> +&uart0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart0_xfer &uart0_cts>;
>> + status = "okay";
>> +};
>> +
>> +&uart2 {
>> + status = "okay";
>> +};
>> +
>> +&uart4 {
>> + status = "okay";
>> +};
>> +
>> +&usb_host0_ehci {
>> + status = "okay";
>> +};
>> +
>> +&usb_host1_ehci {
>> + status = "okay";
>> +};
>> +
>> +&usb_host0_ohci {
>> + status = "okay";
>> +};
>> +
>> +&usb_host1_ohci {
>> + status = "okay";
>> +};
>> +
>> +&usbdrd3_1 {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&usb3_host_en>;
>> +};
>> +
>> +&usbdrd_dwc3_0 {
> No usbdrd3_0?
>
> Thanks,
> Mani
>
>> + status = "okay";
>> +};
>> +
>> +&usbdrd_dwc3_1 {
>> + snps,dis-u3-autosuspend-quirk;
>> + status = "okay";
>> +};
>> +
>> --
>> 2.17.1
>>
>>
>>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] clk: imx: pll14xx: avoid glitch when set rate
From: Peng Fan @ 2019-08-20 2:17 UTC (permalink / raw)
To: mturquette@baylibre.com, sboyd@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, festevam@gmail.com
Cc: Peng Fan, Abel Vesa, Anson Huang, linux-kernel@vger.kernel.org,
dl-linux-imx, kernel@pengutronix.de, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jacky Bai
From: Peng Fan <peng.fan@nxp.com>
According to PLL1443XA and PLL1416X spec,
"When BYPASS is 0 and RESETB is changed from 0 to 1, FOUT starts to
output unstable clock until lock time passes. PLL1416X/PLL1443XA may
generate a glitch at FOUT."
So set BYPASS when RESETB is changed from 0 to 1 to avoid glitch.
In the end of set rate, BYPASS will be cleared.
Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/clk/imx/clk-pll14xx.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index b7213023b238..bd072556bc44 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -191,6 +191,10 @@ static int clk_pll1416x_set_rate(struct clk_hw *hw, unsigned long drate,
tmp &= ~RST_MASK;
writel_relaxed(tmp, pll->base);
+ /* Enable BYPASS */
+ tmp |= BYPASS_MASK;
+ writel(tmp, pll->base);
+
div_val = (rate->mdiv << MDIV_SHIFT) | (rate->pdiv << PDIV_SHIFT) |
(rate->sdiv << SDIV_SHIFT);
writel_relaxed(div_val, pll->base + 0x4);
@@ -250,6 +254,10 @@ static int clk_pll1443x_set_rate(struct clk_hw *hw, unsigned long drate,
tmp &= ~RST_MASK;
writel_relaxed(tmp, pll->base);
+ /* Enable BYPASS */
+ tmp |= BYPASS_MASK;
+ writel_relaxed(tmp, pll->base);
+
div_val = (rate->mdiv << MDIV_SHIFT) | (rate->pdiv << PDIV_SHIFT) |
(rate->sdiv << SDIV_SHIFT);
writel_relaxed(div_val, pll->base + 0x4);
--
2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 4/4] arm64: implement KPROBES_ON_FTRACE
From: Jisheng Zhang @ 2019-08-20 2:16 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Masami Hiramatsu, H. Peter Anvin, Steven Rostedt, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1566232996.v8nlwmnjqa.naveen@linux.ibm.com>
On Mon, 19 Aug 2019 22:22:12 +0530 "Naveen N. Rao" wrote:
>
>
> Jisheng Zhang wrote:
> > This patch implements KPROBES_ON_FTRACE for arm64.
> >
> > ~ # mount -t debugfs debugfs /sys/kernel/debug/
> > ~ # cd /sys/kernel/debug/
> > /sys/kernel/debug # echo 'p _do_fork' > tracing/kprobe_events
> >
> > before the patch:
> >
> > /sys/kernel/debug # cat kprobes/list
> > ffffff801009ff7c k _do_fork+0x4 [DISABLED]
>
> This looks wrong -- we should not be allowing kprobe to be registered on
Yes. I made a mistake when dumping this log. The kernel isn't as clean
as "before the patch".
> ftrace address without KPROBES_ON_FTRACE. Is _do_fork+0x4 the location
> of ftrace entry on arm64?
Indeed, w/o KPROBES_ON_FTRACE, it should be _do_fork+0x0
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] kprobes: adjust kprobe addr for KPROBES_ON_FTRACE
From: Jisheng Zhang @ 2019-08-20 2:05 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Steven Rostedt, H. Peter Anvin, Naveen N. Rao, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190820090130.844fc064030db67efb05ceb1@kernel.org>
On Tue, 20 Aug 2019 09:01:30 +0900 Masami Hiramatsu wrote:
>
> Hi Jisheng,
Hi,
>
> On Mon, 19 Aug 2019 11:36:09 +0000
> Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
>
> > For KPROBES_ON_FTRACE case, we need to adjust the kprobe's addr
> > correspondingly.
>
> No, I think you have misunderstood what the ftrace_call_adjust() does.
> Ftrace's rec->ip is already adjusted when initializing it. Kprobes
> checks the list after initialized (adjusted). So you don't need to
> adjust it again.
This is not to adjust the ftarce's rec->ip, but to adjust the struct kprobe
addr member. Because check_kprobe_address_safe()=>arch_check_ftrace_location
will check the kprobe's addr with ftrace's rec->ip. Since ftrace's rec->ip
is already adjusted, there will be mismatch if we don't adjust kprobe's addr
correspondingly.
However, this patch is wrong. I should not update the kprobe's addr
for non-ftrace-entry. Will fix this in next version.
Thanks
>
> BTW, this type of hidden adjustment should be avoided by design.
> If you find user specifies wrong address, return error instead of
> adjust it silently.
>
> Thank you,
>
> >
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> > kernel/kprobes.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index 9873fc627d61..f8400753a8a9 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -1560,6 +1560,9 @@ int register_kprobe(struct kprobe *p)
> > addr = kprobe_addr(p);
> > if (IS_ERR(addr))
> > return PTR_ERR(addr);
> > +#ifdef CONFIG_KPROBES_ON_FTRACE
> > + addr = (kprobe_opcode_t *)ftrace_call_adjust((unsigned long)addr);
> > +#endif
> > p->addr = addr;
> >
> > ret = check_kprobe_rereg(p);
> > --
> > 2.23.0.rc1
> >
>
>
> --
> Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] kprobes: move kprobe_ftrace_handler() from x86 and make it weak
From: Jisheng Zhang @ 2019-08-20 1:56 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Steven Rostedt, H. Peter Anvin, Naveen N. Rao, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190820090735.a55e7d0b685adecf68fdb55b@kernel.org>
On Tue, 20 Aug 2019 09:07:35 +0900 Masami Hiramatsu wrote:
>
>
> Hi Jisheng,
Hi,
>
> On Mon, 19 Aug 2019 11:37:32 +0000
> Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
>
> > This code could be reused. So move it from x86 to common code.
>
> Yes, it can be among some arch, but at first, please make your
> architecture implementation. After making sure that is enough
> stable, we will optimize (consolidate) the code.
Got it. I will duplicate the function firstly then make the consolidation
as a TODO.
>
> For example,
> > - /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> > - instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
>
> This may depend on arch implementation of kprobes.
Indeed, for arm64, would be as simple as s/ip/pc.
Thanks
>
> Could you make a copy and update comments on arm64?
>
> Thank you,
>
> >
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> > arch/x86/kernel/kprobes/ftrace.c | 44 --------------------------------
> > kernel/kprobes.c | 44 ++++++++++++++++++++++++++++++++
> > 2 files changed, 44 insertions(+), 44 deletions(-)
> >
> > diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
> > index c2ad0b9259ca..91ae1e3e65f7 100644
> > --- a/arch/x86/kernel/kprobes/ftrace.c
> > +++ b/arch/x86/kernel/kprobes/ftrace.c
> > @@ -12,50 +12,6 @@
> >
> > #include "common.h"
> >
> > -/* Ftrace callback handler for kprobes -- called under preepmt disabed */
> > -void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> > - struct ftrace_ops *ops, struct pt_regs *regs)
> > -{
> > - struct kprobe *p;
> > - struct kprobe_ctlblk *kcb;
> > -
> > - /* Preempt is disabled by ftrace */
> > - p = get_kprobe((kprobe_opcode_t *)ip);
> > - if (unlikely(!p) || kprobe_disabled(p))
> > - return;
> > -
> > - kcb = get_kprobe_ctlblk();
> > - if (kprobe_running()) {
> > - kprobes_inc_nmissed_count(p);
> > - } else {
> > - unsigned long orig_ip = instruction_pointer(regs);
> > - /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> > - instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
> > -
> > - __this_cpu_write(current_kprobe, p);
> > - kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> > - if (!p->pre_handler || !p->pre_handler(p, regs)) {
> > - /*
> > - * Emulate singlestep (and also recover regs->ip)
> > - * as if there is a 5byte nop
> > - */
> > - instruction_pointer_set(regs,
> > - (unsigned long)p->addr + MCOUNT_INSN_SIZE);
> > - if (unlikely(p->post_handler)) {
> > - kcb->kprobe_status = KPROBE_HIT_SSDONE;
> > - p->post_handler(p, regs, 0);
> > - }
> > - instruction_pointer_set(regs, orig_ip);
> > - }
> > - /*
> > - * If pre_handler returns !0, it changes regs->ip. We have to
> > - * skip emulating post_handler.
> > - */
> > - __this_cpu_write(current_kprobe, NULL);
> > - }
> > -}
> > -NOKPROBE_SYMBOL(kprobe_ftrace_handler);
> > -
> > int arch_prepare_kprobe_ftrace(struct kprobe *p)
> > {
> > p->ainsn.insn = NULL;
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index f8400753a8a9..479148ee1822 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -960,6 +960,50 @@ static struct kprobe *alloc_aggr_kprobe(struct kprobe *p)
> > #endif /* CONFIG_OPTPROBES */
> >
> > #ifdef CONFIG_KPROBES_ON_FTRACE
> > +/* Ftrace callback handler for kprobes -- called under preepmt disabed */
> > +void __weak kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> > + struct ftrace_ops *ops, struct pt_regs *regs)
> > +{
> > + struct kprobe *p;
> > + struct kprobe_ctlblk *kcb;
> > +
> > + /* Preempt is disabled by ftrace */
> > + p = get_kprobe((kprobe_opcode_t *)ip);
> > + if (unlikely(!p) || kprobe_disabled(p))
> > + return;
> > +
> > + kcb = get_kprobe_ctlblk();
> > + if (kprobe_running()) {
> > + kprobes_inc_nmissed_count(p);
> > + } else {
> > + unsigned long orig_ip = instruction_pointer(regs);
> > + /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> > + instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
> > +
> > + __this_cpu_write(current_kprobe, p);
> > + kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> > + if (!p->pre_handler || !p->pre_handler(p, regs)) {
> > + /*
> > + * Emulate singlestep (and also recover regs->ip)
> > + * as if there is a 5byte nop
> > + */
> > + instruction_pointer_set(regs,
> > + (unsigned long)p->addr + MCOUNT_INSN_SIZE);
> > + if (unlikely(p->post_handler)) {
> > + kcb->kprobe_status = KPROBE_HIT_SSDONE;
> > + p->post_handler(p, regs, 0);
> > + }
> > + instruction_pointer_set(regs, orig_ip);
> > + }
> > + /*
> > + * If pre_handler returns !0, it changes regs->ip. We have to
> > + * skip emulating post_handler.
> > + */
> > + __this_cpu_write(current_kprobe, NULL);
> > + }
> > +}
> > +NOKPROBE_SYMBOL(kprobe_ftrace_handler);
> > +
> > static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
> > .func = kprobe_ftrace_handler,
> > .flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
> > --
> > 2.23.0.rc1
> >
>
>
> --
> Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] clk: imx: imx8mn: fix audio pll setting
From: Peng Fan @ 2019-08-20 1:55 UTC (permalink / raw)
To: mturquette@baylibre.com, sboyd@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, festevam@gmail.com
Cc: Peng Fan, Jacky Bai, Anson Huang, linux-kernel@vger.kernel.org,
dl-linux-imx, kernel@pengutronix.de, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
From: Peng Fan <peng.fan@nxp.com>
The AUDIO PLL max support 650M, so the original clk settings violate
spec. This patch makes the output 786432000 -> 393216000,
and 722534400 -> 361267200 to aligned with NXP vendor kernel without any
impact on audio functionality and go within 650MHz PLL limit.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
drivers/clk/imx/clk-imx8mn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index c5838710e1d8..0e7fb39bcb44 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -51,8 +51,8 @@ static const struct imx_pll14xx_rate_table imx8mn_pll1416x_tbl[] = {
};
static const struct imx_pll14xx_rate_table imx8mn_audiopll_tbl[] = {
- PLL_1443X_RATE(786432000U, 655, 5, 2, 23593),
- PLL_1443X_RATE(722534400U, 301, 5, 1, 3670),
+ PLL_1443X_RATE(393216000U, 262, 2, 3, 9437),
+ PLL_1443X_RATE(361267200U, 361, 3, 3, 17511),
};
static const struct imx_pll14xx_rate_table imx8mn_videopll_tbl[] = {
--
2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/4] kprobes: adjust kprobe addr for KPROBES_ON_FTRACE
From: Jisheng Zhang @ 2019-08-20 1:51 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Masami Hiramatsu, H. Peter Anvin, Steven Rostedt, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1566232801.derqq08wxh.naveen@linux.ibm.com>
On Mon, 19 Aug 2019 22:13:02 +0530 "Naveen N. Rao" wrote:
> CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> Jisheng Zhang wrote:
> > For KPROBES_ON_FTRACE case, we need to adjust the kprobe's addr
> > correspondingly.
> >
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> > kernel/kprobes.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index 9873fc627d61..f8400753a8a9 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -1560,6 +1560,9 @@ int register_kprobe(struct kprobe *p)
> > addr = kprobe_addr(p);
> > if (IS_ERR(addr))
> > return PTR_ERR(addr);
> > +#ifdef CONFIG_KPROBES_ON_FTRACE
> > + addr = (kprobe_opcode_t *)ftrace_call_adjust((unsigned long)addr);
> > +#endif
> > p->addr = addr;
>
> I'm not sure what this is achieving, but looks wrong to me.
Indeed, I didn't take care of non-ftrace addr when KPROBES_ON_FTRACE, will
update in next version.
thanks
>
> If you intend to have kprobes default to using ftrace entry for probing
> functions, consider over-riding kprobe_lookup_name() -- see powerpc
> variant for example.
>
>
> - Naveen
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Build regression in Linux 5.3-rc5 with CONFIG_XEN=y
From: Christoph Hellwig @ 2019-08-20 1:24 UTC (permalink / raw)
To: Stefan Wahren
Cc: iommu, Robin Murphy, Christoph Hellwig, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <0b019cdc-6f0e-c37f-2be7-c24293acb8cd@gmx.net>
Hi Stefan,
please try the patch below.
---
From e0570628d96faa50ebfc94ce8e545968336db225 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch@lst.de>
Date: Tue, 20 Aug 2019 10:08:38 +0900
Subject: arm: select the dma-noncoherent symbols for all swiotlb builds
We need to provide the arch hooks for non-coherent dma-direct
and swiotlb for all swiotlb builds, not just when LPAS is enabled.
Without that the Xen build that selects SWIOTLB indirectly through
SWIOTLB_XEN fails to build.
Fixes: ad3c7b18c5b3 ("arm: use swiotlb for bounce buffering on LPAE configs")
Reported-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/Kconfig | 4 ++++
arch/arm/mm/Kconfig | 4 ----
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 33b00579beff..24360211534a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,6 +7,8 @@ config ARM
select ARCH_HAS_BINFMT_FLAT
select ARCH_HAS_DEBUG_VIRTUAL if MMU
select ARCH_HAS_DEVMEM_IS_ALLOWED
+ select ARCH_HAS_DMA_COHERENT_TO_PFN if SWIOTLB
+ select ARCH_HAS_DMA_MMAP_PGPROT if SWIOTLB
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KEEPINITRD
@@ -18,6 +20,8 @@ config ARM
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
select ARCH_HAS_STRICT_MODULE_RWX if MMU
+ select ARCH_HAS_SYNC_DMA_FOR_DEVICE if SWIOTLB
+ select ARCH_HAS_SYNC_DMA_FOR_CPU if SWIOTLB
select ARCH_HAS_TEARDOWN_DMA_OPS if MMU
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index c54cd7ed90ba..c1222c0e9fd3 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -664,10 +664,6 @@ config ARM_LPAE
!CPU_32v4 && !CPU_32v3
select PHYS_ADDR_T_64BIT
select SWIOTLB
- select ARCH_HAS_DMA_COHERENT_TO_PFN
- select ARCH_HAS_DMA_MMAP_PGPROT
- select ARCH_HAS_SYNC_DMA_FOR_DEVICE
- select ARCH_HAS_SYNC_DMA_FOR_CPU
help
Say Y if you have an ARMv7 processor supporting the LPAE page
table format and you would like to access memory beyond the
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/2] perf cs-etm: Support sample flags 'insn' and 'insnlen'
From: Leo Yan @ 2019-08-20 1:12 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Mathieu Poirier, Suzuki K Poulose, Alexander Shishkin,
Coresight ML, Linux Kernel Mailing List, Namhyung Kim,
Robert Walker, Jiri Olsa, linux-arm-kernel, Mike Leach
In-Reply-To: <20190819185054.GB3929@kernel.org>
On Mon, Aug 19, 2019 at 03:50:54PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Aug 19, 2019 at 12:08:26PM -0600, Mathieu Poirier escreveu:
> > On Thu, 15 Aug 2019 at 02:30, Leo Yan <leo.yan@linaro.org> wrote:
> > >
> > > The synthetic branch and instruction samples are missed to set
> > > instruction related info, thus perf tool fails to display samples with
> > > flags '-F,+insn,+insnlen'.
> > >
> > > CoreSight trace decoder has provided sufficient information to decide
> > > the instruction size based on the isa type: A64/A32 instruction are
> > > 32-bit size, but one exception is the T32 instruction size, which might
> > > be 32-bit or 16-bit.
> > >
> > > This patch handles for these cases and it reads the instruction values
> > > from DSO file; thus can support flags '-F,+insn,+insnlen'.
>
> > The code seems to be correct. I have also tested this patch.
>
> > Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> Thanks, applied.
Thanks a lot, Mathieu & Arnaldo.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] kprobes/x86: use instruction_pointer and instruction_pointer_set
From: Masami Hiramatsu @ 2019-08-20 0:09 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Steven Rostedt, H. Peter Anvin, Naveen N. Rao, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819192543.32cec143@xhacker.debian>
On Mon, 19 Aug 2019 11:36:48 +0000
Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
> This is to make the kprobe_ftrace_handler() common, so we can move it
> to common code in next patch.
>
BTW, this patch looks good, without next patch. Could you update the
patch description and resend it with my Ack?
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thank you,
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> ---
> arch/x86/kernel/kprobes/ftrace.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
> index 681a4b36e9bb..c2ad0b9259ca 100644
> --- a/arch/x86/kernel/kprobes/ftrace.c
> +++ b/arch/x86/kernel/kprobes/ftrace.c
> @@ -28,9 +28,9 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> if (kprobe_running()) {
> kprobes_inc_nmissed_count(p);
> } else {
> - unsigned long orig_ip = regs->ip;
> + unsigned long orig_ip = instruction_pointer(regs);
> /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> - regs->ip = ip + sizeof(kprobe_opcode_t);
> + instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
>
> __this_cpu_write(current_kprobe, p);
> kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> @@ -39,12 +39,13 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> * Emulate singlestep (and also recover regs->ip)
> * as if there is a 5byte nop
> */
> - regs->ip = (unsigned long)p->addr + MCOUNT_INSN_SIZE;
> + instruction_pointer_set(regs,
> + (unsigned long)p->addr + MCOUNT_INSN_SIZE);
> if (unlikely(p->post_handler)) {
> kcb->kprobe_status = KPROBE_HIT_SSDONE;
> p->post_handler(p, regs, 0);
> }
> - regs->ip = orig_ip;
> + instruction_pointer_set(regs, orig_ip);
> }
> /*
> * If pre_handler returns !0, it changes regs->ip. We have to
> --
> 2.23.0.rc1
>
--
Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] kprobes: move kprobe_ftrace_handler() from x86 and make it weak
From: Masami Hiramatsu @ 2019-08-20 0:07 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Steven Rostedt, H. Peter Anvin, Naveen N. Rao, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819192628.5f550074@xhacker.debian>
Hi Jisheng,
On Mon, 19 Aug 2019 11:37:32 +0000
Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
> This code could be reused. So move it from x86 to common code.
Yes, it can be among some arch, but at first, please make your
architecture implementation. After making sure that is enough
stable, we will optimize (consolidate) the code.
For example,
> - /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> - instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
This may depend on arch implementation of kprobes.
Could you make a copy and update comments on arm64?
Thank you,
>
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> ---
> arch/x86/kernel/kprobes/ftrace.c | 44 --------------------------------
> kernel/kprobes.c | 44 ++++++++++++++++++++++++++++++++
> 2 files changed, 44 insertions(+), 44 deletions(-)
>
> diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
> index c2ad0b9259ca..91ae1e3e65f7 100644
> --- a/arch/x86/kernel/kprobes/ftrace.c
> +++ b/arch/x86/kernel/kprobes/ftrace.c
> @@ -12,50 +12,6 @@
>
> #include "common.h"
>
> -/* Ftrace callback handler for kprobes -- called under preepmt disabed */
> -void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> - struct ftrace_ops *ops, struct pt_regs *regs)
> -{
> - struct kprobe *p;
> - struct kprobe_ctlblk *kcb;
> -
> - /* Preempt is disabled by ftrace */
> - p = get_kprobe((kprobe_opcode_t *)ip);
> - if (unlikely(!p) || kprobe_disabled(p))
> - return;
> -
> - kcb = get_kprobe_ctlblk();
> - if (kprobe_running()) {
> - kprobes_inc_nmissed_count(p);
> - } else {
> - unsigned long orig_ip = instruction_pointer(regs);
> - /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> - instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
> -
> - __this_cpu_write(current_kprobe, p);
> - kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> - if (!p->pre_handler || !p->pre_handler(p, regs)) {
> - /*
> - * Emulate singlestep (and also recover regs->ip)
> - * as if there is a 5byte nop
> - */
> - instruction_pointer_set(regs,
> - (unsigned long)p->addr + MCOUNT_INSN_SIZE);
> - if (unlikely(p->post_handler)) {
> - kcb->kprobe_status = KPROBE_HIT_SSDONE;
> - p->post_handler(p, regs, 0);
> - }
> - instruction_pointer_set(regs, orig_ip);
> - }
> - /*
> - * If pre_handler returns !0, it changes regs->ip. We have to
> - * skip emulating post_handler.
> - */
> - __this_cpu_write(current_kprobe, NULL);
> - }
> -}
> -NOKPROBE_SYMBOL(kprobe_ftrace_handler);
> -
> int arch_prepare_kprobe_ftrace(struct kprobe *p)
> {
> p->ainsn.insn = NULL;
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index f8400753a8a9..479148ee1822 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -960,6 +960,50 @@ static struct kprobe *alloc_aggr_kprobe(struct kprobe *p)
> #endif /* CONFIG_OPTPROBES */
>
> #ifdef CONFIG_KPROBES_ON_FTRACE
> +/* Ftrace callback handler for kprobes -- called under preepmt disabed */
> +void __weak kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> + struct ftrace_ops *ops, struct pt_regs *regs)
> +{
> + struct kprobe *p;
> + struct kprobe_ctlblk *kcb;
> +
> + /* Preempt is disabled by ftrace */
> + p = get_kprobe((kprobe_opcode_t *)ip);
> + if (unlikely(!p) || kprobe_disabled(p))
> + return;
> +
> + kcb = get_kprobe_ctlblk();
> + if (kprobe_running()) {
> + kprobes_inc_nmissed_count(p);
> + } else {
> + unsigned long orig_ip = instruction_pointer(regs);
> + /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> + instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
> +
> + __this_cpu_write(current_kprobe, p);
> + kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> + if (!p->pre_handler || !p->pre_handler(p, regs)) {
> + /*
> + * Emulate singlestep (and also recover regs->ip)
> + * as if there is a 5byte nop
> + */
> + instruction_pointer_set(regs,
> + (unsigned long)p->addr + MCOUNT_INSN_SIZE);
> + if (unlikely(p->post_handler)) {
> + kcb->kprobe_status = KPROBE_HIT_SSDONE;
> + p->post_handler(p, regs, 0);
> + }
> + instruction_pointer_set(regs, orig_ip);
> + }
> + /*
> + * If pre_handler returns !0, it changes regs->ip. We have to
> + * skip emulating post_handler.
> + */
> + __this_cpu_write(current_kprobe, NULL);
> + }
> +}
> +NOKPROBE_SYMBOL(kprobe_ftrace_handler);
> +
> static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
> .func = kprobe_ftrace_handler,
> .flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
> --
> 2.23.0.rc1
>
--
Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC 02/11] dt-bindings: power: amlogic, meson-gx-pwrc: Add SM1 bindings
From: Kevin Hilman @ 2019-08-20 0:05 UTC (permalink / raw)
To: Martin Blumenstingl, Neil Armstrong
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
jbrunet
In-Reply-To: <CAFBinCAT1JaK6ksD9OzCK_wEEWJdaZL2vLzGeCzVVbz9V67btQ@mail.gmail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> Hi Neil,
>
> On Mon, Jul 1, 2019 at 12:48 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
> [...]
>> +General Purpose Power Controller
>> +--------------------------------
>>
>> +The Amlogic SM1 SoCs embeds a General Purpose Power Controller used
>> +to control the power domain for, at least, the USB PHYs and PCIe
>> +peripherals.
> AFAIK each binding document should only describe one IP block.
> this one seems to be new / different
>
> should it get it's own file?
> also should it be a .yaml binding?
I don't think this is a new IP block. Comparing across the various
(64-bit) SoCs, it seems to be very similar across all SoCs.
>> +
>> +Device Tree Bindings:
>> +---------------------
>> +
>> +Required properties:
>> +- compatible: should be one of the following :
>> + - "amlogic,meson-sm1-pwrc" for the Meson SM1 SoCs
>> +- #power-domain-cells: should be 0
>> +- amlogic,hhi-sysctrl: phandle to the HHI sysctrl node
>> +
>> +Parent node should have the following properties :
>> +- compatible: "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd"
>> +- reg: base address and size of the AO system control register space.
>> +
>> +
>> +Example:
>> +-------
>> +
>> +ao_sysctrl: sys-ctrl@0 {
>> + compatible = "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd";
>> + reg = <0x0 0x0 0x0 0x100>;
>> +
>> + pwrc: power-controller {
>> + compatible = "amlogic,meson-sm1-pwrc";
>> + #power-domain-cells = <1>;
>> + amlogic,hhi-sysctrl = <&hhi>;
>> + };
>> +};
>
> I'm not sure that we want to mix HHI and AO power domains in one driver again
We're not mixing here. These are all EE domains. They just have some
control registers in the AO memory region.
> back in March I asked a few questions about modelling the power
> domains and Kevin explained that we can implement them hierarchical:
> [0]
> unfortunately I didn't have the time to work on this - however, now
> that we implement a new driver: should we follow this hierarchical
> approach?
The more I look at this, I don't think we have a commpelling need to
model them hierarchically. The main reason being is that of the 3
top-level domains I listed[0], we can only managing the EE domains in the
kernel. It doesn't make sense to model/manage AO domains because, well,
they are always-on (AO). The CPU domains are managed my the PSCI
firmware, and we don't/won't have any control over that.
For that reason, I think it makes the most sense to have a generic
driver that handles all the EE domains.
IMO, the SM1 driver that Neil wrote in patch 4 of this series is 80%
there. If we generalize that little more, it can be quite easily used
for all the EE domains.
Kevin
[0] http://lists.infradead.org/pipermail/linux-amlogic/2019-March/010512.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] kprobes: adjust kprobe addr for KPROBES_ON_FTRACE
From: Masami Hiramatsu @ 2019-08-20 0:01 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Steven Rostedt, H. Peter Anvin, Naveen N. Rao, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819192505.483c0bf0@xhacker.debian>
Hi Jisheng,
On Mon, 19 Aug 2019 11:36:09 +0000
Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
> For KPROBES_ON_FTRACE case, we need to adjust the kprobe's addr
> correspondingly.
No, I think you have misunderstood what the ftrace_call_adjust() does.
Ftrace's rec->ip is already adjusted when initializing it. Kprobes
checks the list after initialized (adjusted). So you don't need to
adjust it again.
BTW, this type of hidden adjustment should be avoided by design.
If you find user specifies wrong address, return error instead of
adjust it silently.
Thank you,
>
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> ---
> kernel/kprobes.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 9873fc627d61..f8400753a8a9 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1560,6 +1560,9 @@ int register_kprobe(struct kprobe *p)
> addr = kprobe_addr(p);
> if (IS_ERR(addr))
> return PTR_ERR(addr);
> +#ifdef CONFIG_KPROBES_ON_FTRACE
> + addr = (kprobe_opcode_t *)ftrace_call_adjust((unsigned long)addr);
> +#endif
> p->addr = addr;
>
> ret = check_kprobe_rereg(p);
> --
> 2.23.0.rc1
>
--
Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC 04/11] soc: amlogic: Add support for SM1 power controller
From: Kevin Hilman @ 2019-08-19 23:56 UTC (permalink / raw)
To: Neil Armstrong, jbrunet
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190701104705.18271-5-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Add support for the General Purpose Amlogic SM1 Power controller,
> dedicated to the PCIe, USB, NNA and GE2D Power Domains.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
I like this driver in general, but as I look at all the EE power domains
for GX, G12 and SM1 they are really very similar. I had started to
generalize the gx-pwrc-vpu driver and it ends up looking just like this.
I think this driver could be generalized just a little bit more and then
replace the the GX-specific VPU one, and AFAICT, then be used across all
the 64-bit SoCs, and be called "meson-pwrc-ee" or something like that...
> ---
> drivers/soc/amlogic/Kconfig | 11 ++
> drivers/soc/amlogic/Makefile | 1 +
> drivers/soc/amlogic/meson-sm1-pwrc.c | 245 +++++++++++++++++++++++++++
> 3 files changed, 257 insertions(+)
> create mode 100644 drivers/soc/amlogic/meson-sm1-pwrc.c
>
> diff --git a/drivers/soc/amlogic/Kconfig b/drivers/soc/amlogic/Kconfig
> index 5501ad5650b2..596f1afef1a7 100644
> --- a/drivers/soc/amlogic/Kconfig
> +++ b/drivers/soc/amlogic/Kconfig
> @@ -36,6 +36,17 @@ config MESON_GX_PM_DOMAINS
> Say yes to expose Amlogic Meson GX Power Domains as
> Generic Power Domains.
>
> +config MESON_SM1_PM_DOMAINS
> + bool "Amlogic Meson SM1 Power Domains driver"
> + depends on ARCH_MESON || COMPILE_TEST
> + depends on PM && OF
> + default ARCH_MESON
> + select PM_GENERIC_DOMAINS
> + select PM_GENERIC_DOMAINS_OF
> + help
> + Say yes to expose Amlogic Meson SM1 Power Domains as
> + Generic Power Domains.
> +
> config MESON_MX_SOCINFO
> bool "Amlogic Meson MX SoC Information driver"
> depends on ARCH_MESON || COMPILE_TEST
> diff --git a/drivers/soc/amlogic/Makefile b/drivers/soc/amlogic/Makefile
> index bf2d109f61e9..f99935499ee6 100644
> --- a/drivers/soc/amlogic/Makefile
> +++ b/drivers/soc/amlogic/Makefile
> @@ -3,3 +3,4 @@ obj-$(CONFIG_MESON_CLK_MEASURE) += meson-clk-measure.o
> obj-$(CONFIG_MESON_GX_SOCINFO) += meson-gx-socinfo.o
> obj-$(CONFIG_MESON_GX_PM_DOMAINS) += meson-gx-pwrc-vpu.o
> obj-$(CONFIG_MESON_MX_SOCINFO) += meson-mx-socinfo.o
> +obj-$(CONFIG_MESON_SM1_PM_DOMAINS) += meson-sm1-pwrc.o
> diff --git a/drivers/soc/amlogic/meson-sm1-pwrc.c b/drivers/soc/amlogic/meson-sm1-pwrc.c
> new file mode 100644
> index 000000000000..9ece1d06f417
> --- /dev/null
> +++ b/drivers/soc/amlogic/meson-sm1-pwrc.c
> @@ -0,0 +1,245 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2017 BayLibre, SAS
> + * Author: Neil Armstrong <narmstrong@baylibre.com>
> + */
> +
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +#include <linux/bitfield.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/of_device.h>
> +#include <dt-bindings/power/meson-sm1-power.h>
> +
> +/* AO Offsets */
> +
> +#define AO_RTI_GEN_PWR_SLEEP0 (0x3a << 2)
> +#define AO_RTI_GEN_PWR_ISO0 (0x3b << 2)
> +
> +/* HHI Offsets */
> +
> +#define HHI_MEM_PD_REG0 (0x40 << 2)
> +#define HHI_NANOQ_MEM_PD_REG0 (0x46 << 2)
> +#define HHI_NANOQ_MEM_PD_REG1 (0x47 << 2)
> +
> +struct meson_sm1_pwrc;
> +
> +struct meson_sm1_pwrc_mem_domain {
> + unsigned int reg;
> + unsigned int mask;
> +};
> +
> +struct meson_sm1_pwrc_domain_desc {
> + char *name;
> + unsigned int sleep_reg;
> + unsigned int sleep_bit;
> + unsigned int iso_reg;
> + unsigned int iso_bit;
> + unsigned int mem_pd_count;
> + struct meson_sm1_pwrc_mem_domain *mem_pd;
> +};
If you add resets and clocks (using clk bulk like my other proposed
patch to gx-pwrc-vpu) then this could be used for VPU also. We could
ignore my clk bulk patch and then just deprecate the old driver and use
this one for everything.
We would just need SoC-specific tables selected by compatible-string to
select the memory pds, and the clocks and resets could (optionaly) come
from the DT.
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Extend patterns for Samsung SoC, Security Subsystem and clock drivers
From: Chanwoo Choi @ 2019-08-19 23:48 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kukjin Kim, Vladimir Zapolskiy,
Kamil Konieczny, Herbert Xu, David S. Miller, Sylwester Nawrocki,
Tomasz Figa, Michael Turquette, Stephen Boyd, linux-arm-kernel,
linux-samsung-soc, linux-kernel, linux-crypto, linux-clk,
cpgs (cpgs@samsung.com)
In-Reply-To: <20190818172750.20921-1-krzk@kernel.org>
Hi Krzysztof,
On 19. 8. 19. 오전 2:27, Krzysztof Kozlowski wrote:
> Extend the patterns to cover all related files in respective
> categories:
> 1. Samsung Exynos ARM architecture: add soc drivers headers and make
> directory matches consistent,
> 2. Samsung Security SubSystem driver (crypto): add bindings,
> 3. Samsung SoC clock drivers: add S3C24xx, S3C64xx and S5Pv210 bindings.
>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Vladimir Zapolskiy <vz@mleia.com>
> Cc: Kamil Konieczny <k.konieczny@partner.samsung.com>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> ---
> MAINTAINERS | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 420567d1519a..35a4002ac58b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2199,8 +2199,9 @@ F: drivers/*/*s3c24*
> F: drivers/*/*/*s3c24*
> F: drivers/*/*s3c64xx*
> F: drivers/*/*s5pv210*
> -F: drivers/memory/samsung/*
> -F: drivers/soc/samsung/*
> +F: drivers/memory/samsung/
> +F: drivers/soc/samsung/
> +F: include/linux/soc/samsung/
> F: Documentation/arm/samsung/
> F: Documentation/devicetree/bindings/arm/samsung/
> F: Documentation/devicetree/bindings/sram/samsung-sram.txt
> @@ -14174,6 +14175,8 @@ M: Kamil Konieczny <k.konieczny@partner.samsung.com>
> L: linux-crypto@vger.kernel.org
> L: linux-samsung-soc@vger.kernel.org
> S: Maintained
> +F: Documentation/devicetree/bindings/crypto/samsung-slimsss.txt
> +F: Documentation/devicetree/bindings/crypto/samsung-sss.txt
> F: drivers/crypto/s5p-sss.c
>
> SAMSUNG S5P/EXYNOS4 SOC SERIES CAMERA SUBSYSTEM DRIVERS
> @@ -14194,6 +14197,8 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/snawrocki/clk.git
> F: drivers/clk/samsung/
> F: include/dt-bindings/clock/exynos*.h
> F: Documentation/devicetree/bindings/clock/exynos*.txt
> +F: Documentation/devicetree/bindings/clock/samsung,s3c*
> +F: Documentation/devicetree/bindings/clock/samsung,s5p*
>
> SAMSUNG SPI DRIVERS
> M: Kukjin Kim <kgene@kernel.org>
>
For clock part,
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
From: Chanwoo Choi @ 2019-08-19 23:44 UTC (permalink / raw)
To: Leonard Crestez, Artur Świgoń, georgi.djakov@linaro.org,
Viresh Kumar
Cc: devicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
Saravana Kannan, linux-pm@vger.kernel.org, Rafael J. Wysocki,
sw0312.kim@samsung.com, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, Lukasz Luba,
inki.dae@samsung.com, myungjoo.ham@samsung.com, krzk@kernel.org,
cpgs (cpgs@samsung.com), linux-arm-kernel@lists.infradead.org,
m.szyprowski@samsung.com
In-Reply-To: <VI1PR04MB7023B5095F706635354C4C50EED70@VI1PR04MB7023.eurprd04.prod.outlook.com>
Hi Artur and Leonard,
On 19. 8. 9. 오전 12:00, Leonard Crestez wrote:
> On 29.07.2019 04:49, Chanwoo Choi wrote:
>> On 19. 7. 23. 오후 9:20, Artur Świgoń wrote:
>>> This patch adds interconnect functionality to the exynos-bus devfreq
>>> driver.
>>>
>>> The devfreq target() callback provided by exynos-bus now selects either the
>>> frequency calculated by the devfreq governor or the frequency requested via
>>> the interconnect API for the given node, whichever is higher.
>>
>> Basically, I agree to support the QoS requirement between devices.
>> But, I think that need to consider the multiple cases.
>>
>> 1. When changing the devfreq governor by user,
>> For example of the connection between bus_dmc/leftbus/display on patch8,
>> there are possible multiple cases with various devfreq governor
>> which is changed on the runtime by user through sysfs interface.
>>
>> If users changes the devfreq governor as following:
>> Before,
>> - bus_dmc (simple_ondemand, available frequency 100/200/300/400 MHz)
>> --> bus_leftbus(simple_ondemand, available frequency 100/200/300/400 MHz)
>> ----> bus_display(passive)
>>
>> After changed governor of bus_dmc,
>> if the min_freq by interconnect requirement is 400Mhz,
>> - bus_dmc (powersave) : min_freq and max_freq and cur_freq is 100MHz
>> --> bus_leftbus(simple_ondemand) : cur_freq is 400Mhz
>> ----> bus_display(passive)
>>
>> The final frequency is 400MHz of bus_dmc
>> even if the min_freq/max_freq/cur_freq is 100MHz.
>> It cannot show the correct min_freq/max_freq through
>> devfreq sysfs interface.
>>
>>
>> 2. When disabling the some frequency by devfreq-thermal throttling,
>> This patch checks the min_freq of interconnect requirement
>> in the exynos_bus_target() and exynos_bus_passive_target().
>> Also, it cannot show the correct min_freq/max_freq through
>> devfreq sysfs interface.
>>
>> For example of bus_dmc bus,
>> - The available frequencies are 100MHz, 200MHz, 300MHz, 400MHz
>> - Disable 400MHz by devfreq-thermal throttling
>> - min_freq is 100MHz
>> - max_freq is 300MHz
>> - min_freq of interconnect is 400MHz
>>
>> In result, the final frequency is 400MHz by exynos_bus_target()
>> There are no problem for working. But, the user cannot know
>> reason why cur_freq is 400MHz even if max_freq is 300MHz.
>>
>> Basically, update_devfreq() considers the all constraints
>> of min_freq/max_freq to decide the proper target frequency.
>
> I think that applying the interconnect min_freq via dev_pm_qos can help
> with many of these concerns: update_devfreq controls all the min/max
> handling, sysfs is accurate and better decisions can be made regarding
> thermal. Enforcing constraints in the core is definitely better.
>
> This wouldn't even be a very big change, you don't need to actually move
> the interconnect code outside of devfreq. Just make every devfreq/icc
> node register a dev_pm_qos_request for itself during registration and
> call dev_pm_qos_update_request inside exynos_bus_icc_set.
>
> See: https://patchwork.kernel.org/patch/11084279/
I agree this approach of Leonard. If we use the dev_pm_qos[1] feature,
it resolve the issue of my comment1/2.
In summary, when receive the minimum frequency requirement
from interconnect path, the each bus uses the dev_pm_qos interface
in order to inform the minimum frequency from interconnect to devfreq.
And then the devfreq core will execute the update_devfreq()
with all frequency requirements as following:
- the user input (min/max frequency though devfreq sysfs
- the target frequency provided by devfreq governor
- the minimum frequency from interconnect path
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/8] soc: ti: Add OMAP PRM driver
From: Suman Anna @ 2019-08-19 23:20 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1565164139-21886-1-git-send-email-t-kristo@ti.com>
Hi Tero,
On 8/7/19 2:48 AM, Tero Kristo wrote:
> Hi,
>
> This series adds OMAP PRM driver which initially supports only reset
> handling. Later on, power domain support can be added to this to get
> rid of the current OMAP power domain handling code which resides
> under the mach-omap2 platform directory. Initially, reset data is
> added for AM3, OMAP4 and DRA7 SoCs.
Wakeup M3 remoteproc driver is fully upstream, so we should be able to
test that driver as well if you can add the AM4 data. That will also
unblock my PRUSS.
If you can add the data to others as well, it will help in easier
migration of the individual drivers, otherwise the ti-sysc interconnect,
hwmod, and hwmod reset data combinations will all have to be supported
in code.
regards
Suman
>
> I've been testing the reset handling logic with OMAP remoteproc
> driver which has been converted to use generic reset framework. This
> part is a work in progress, so will be posting patches from that part
> later on.
>
> -Tero
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/8] soc: ti: omap-prm: add support for denying idle for reset clockdomain
From: Suman Anna @ 2019-08-19 23:16 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1565164139-21886-5-git-send-email-t-kristo@ti.com>
Hi Tero,
On 8/7/19 2:48 AM, Tero Kristo wrote:
> TI SoCs hardware reset signals require the parent clockdomain to be
> in force wakeup mode while de-asserting the reset, otherwise it may
> never complete. To support this, add pdata hooks to control the
> clockdomain directly.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> drivers/soc/ti/omap_prm.c | 32 ++++++++++++++++++++++++++++----
> include/linux/platform_data/ti-prm.h | 21 +++++++++++++++++++++
> 2 files changed, 49 insertions(+), 4 deletions(-)
> create mode 100644 include/linux/platform_data/ti-prm.h
>
> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
> index d412af3..870515e3 100644
> --- a/drivers/soc/ti/omap_prm.c
> +++ b/drivers/soc/ti/omap_prm.c
> @@ -16,6 +16,8 @@
> #include <linux/reset-controller.h>
> #include <linux/delay.h>
>
> +#include <linux/platform_data/ti-prm.h>
> +
> struct omap_rst_map {
> s8 rst;
> s8 st;
> @@ -24,6 +26,7 @@ struct omap_rst_map {
> struct omap_prm_data {
> u32 base;
> const char *name;
> + const char *clkdm_name;
> u16 pwstctrl;
> u16 pwstst;
> u16 rstctl;
> @@ -40,6 +43,8 @@ struct omap_prm {
> struct omap_reset_data {
> struct reset_controller_dev rcdev;
> struct omap_prm *prm;
> + struct clockdomain *clkdm;
> + struct device *dev;
> };
>
> #define to_omap_reset_data(p) container_of((p), struct omap_reset_data, rcdev)
> @@ -108,6 +113,8 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
> int st_bit = id;
> bool has_rstst;
> int timeout = 0;
> + struct ti_prm_platform_data *pdata = dev_get_platdata(reset->dev);
> + int ret = 0;
>
> /* check the current status to avoid de-asserting the line twice */
> v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
> @@ -125,13 +132,16 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
> writel_relaxed(v, reset->prm->base + reset->prm->data->rstst);
> }
>
> + if (pdata->clkdm_deny_idle && reset->clkdm)
> + pdata->clkdm_deny_idle(reset->clkdm);
> +
> /* de-assert the reset control line */
> v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
> v &= ~(1 << id);
> writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
>
> if (!has_rstst)
> - return 0;
> + goto exit;
>
> /* wait for the status to be set */
> while (1) {
> @@ -140,13 +150,19 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
> if (v)
> break;
> timeout++;
> - if (timeout > OMAP_RESET_MAX_WAIT)
> - return -EBUSY;
> + if (timeout > OMAP_RESET_MAX_WAIT) {
> + ret = -EBUSY;
> + goto exit;
> + }
>
> udelay(1);
> }
>
> - return 0;
> +exit:
> + if (pdata->clkdm_allow_idle && reset->clkdm)
> + pdata->clkdm_allow_idle(reset->clkdm);
> +
> + return ret;
> }
>
> static const struct reset_control_ops omap_reset_ops = {
> @@ -159,6 +175,8 @@ static int omap_prm_reset_probe(struct platform_device *pdev,
> struct omap_prm *prm)
> {
> struct omap_reset_data *reset;
> + struct ti_prm_platform_data *pdata = dev_get_platdata(&pdev->dev);
Please add checks for NULL callbacks. I don't think these are optional
right, so better to check in init rather than during runtime. Granted
you will probably not run into this after patch 8, but would be good to
check and print an error in case pdata quirks is missed out.
> + char buf[32];
>
> /*
> * Check if we have resets. If either rstctl or rstst is
> @@ -177,9 +195,15 @@ static int omap_prm_reset_probe(struct platform_device *pdev,
> reset->rcdev.ops = &omap_reset_ops;
> reset->rcdev.of_node = pdev->dev.of_node;
> reset->rcdev.nr_resets = OMAP_MAX_RESETS;
> + reset->dev = &pdev->dev;
>
> reset->prm = prm;
>
> + sprintf(buf, "%s_clkdm", prm->data->clkdm_name ? prm->data->clkdm_name :
> + prm->data->name);
> +
> + reset->clkdm = pdata->clkdm_lookup(buf);
Not checking return status?
regards
Suman
> +
> return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
> }
>
> diff --git a/include/linux/platform_data/ti-prm.h b/include/linux/platform_data/ti-prm.h
> new file mode 100644
> index 0000000..28154c3
> --- /dev/null
> +++ b/include/linux/platform_data/ti-prm.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * TI PRM (Power & Reset Manager) platform data
> + *
> + * Copyright (C) 2019 Texas Instruments, Inc.
> + *
> + * Tero Kristo <t-kristo@ti.com>
> + */
> +
> +#ifndef _LINUX_PLATFORM_DATA_TI_PRM_H
> +#define _LINUX_PLATFORM_DATA_TI_PRM_H
> +
> +struct clockdomain;
> +
> +struct ti_prm_platform_data {
> + void (*clkdm_deny_idle)(struct clockdomain *clkdm);
> + void (*clkdm_allow_idle)(struct clockdomain *clkdm);
> + struct clockdomain * (*clkdm_lookup)(const char *name);
> +};
> +
> +#endif /* _LINUX_PLATFORM_DATA_TI_PRM_H */
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 7/8] soc: ti: omap-prm: add dra7 PRM data
From: Suman Anna @ 2019-08-19 23:12 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1565164139-21886-8-git-send-email-t-kristo@ti.com>
On 8/7/19 2:48 AM, Tero Kristo wrote:
> Add PRM data for dra7 family of SoCs.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> drivers/soc/ti/omap_prm.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
> index fadfc7f..05b7749 100644
> --- a/drivers/soc/ti/omap_prm.c
> +++ b/drivers/soc/ti/omap_prm.c
> @@ -73,6 +73,31 @@ struct omap_prm_data omap4_prm_data[] = {
> { },
> };
>
> +static struct omap_prm_data dra7_prm_data[] = {
Same comment as on other data, static const.
regards
Suman
> + { .name = "mpu", .base = 0x4ae06300, .pwstst = 0x4 },
> + { .name = "dsp1", .base = 0x4ae06400, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
> + { .name = "ipu", .base = 0x4ae06500, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14, .clkdm_name = "ipu1" },
> + { .name = "coreaon", .base = 0x4ae06628, .pwstst = 0x4 },
> + { .name = "core", .base = 0x4ae06700, .pwstst = 0x4, .rstctl = 0x210, .rstst = 0x214, .clkdm_name = "ipu2" },
> + { .name = "iva", .base = 0x4ae06f00, .pwstst = 0x4 },
> + { .name = "cam", .base = 0x4ae07000, .pwstst = 0x4 },
> + { .name = "dss", .base = 0x4ae07100, .pwstst = 0x4 },
> + { .name = "gpu", .base = 0x4ae07200, .pwstst = 0x4 },
> + { .name = "l3init", .base = 0x4ae07300, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
> + { .name = "l4per", .base = 0x4ae07400, .pwstst = 0x4 },
> + { .name = "custefuse", .base = 0x4ae07600, .pwstst = 0x4 },
> + { .name = "wkupaon", .base = 0x4ae07724, .pwstst = 0x4 },
> + { .name = "emu", .base = 0x4ae07900, .pwstst = 0x4 },
> + { .name = "dsp2", .base = 0x4ae07b00, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
> + { .name = "eve1", .base = 0x4ae07b40, .pwstst = 0x4 },
> + { .name = "eve2", .base = 0x4ae07b80, .pwstst = 0x4 },
> + { .name = "eve3", .base = 0x4ae07bc0, .pwstst = 0x4 },
> + { .name = "eve4", .base = 0x4ae07c00, .pwstst = 0x4 },
> + { .name = "rtc", .base = 0x4ae07c60, .pwstst = 0x4 },
> + { .name = "vpe", .base = 0x4ae07c80, .pwstst = 0x4 },
> + { },
> +};
> +
> struct omap_rst_map am3_wkup_rst_map[] = {
> { .rst = 3, .st = 5 },
> { .rst = -1 },
> @@ -91,6 +116,7 @@ struct omap_prm_data am3_prm_data[] = {
>
> static const struct of_device_id omap_prm_id_table[] = {
> { .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
> + { .compatible = "ti,dra7-prm-inst", .data = dra7_prm_data },
> { .compatible = "ti,am3-prm-inst", .data = am3_prm_data },
> { },
> };
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/8] soc: ti: omap_prm: add data for am33xx
From: Suman Anna @ 2019-08-19 23:11 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1565164139-21886-7-git-send-email-t-kristo@ti.com>
On 8/7/19 2:48 AM, Tero Kristo wrote:
> Add PRM instance data for AM33xx SoC. Includes some basic register
> definitions and reset data for now.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> drivers/soc/ti/omap_prm.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
> index 9b8d5945..fadfc7f 100644
> --- a/drivers/soc/ti/omap_prm.c
> +++ b/drivers/soc/ti/omap_prm.c
> @@ -73,8 +73,25 @@ struct omap_prm_data omap4_prm_data[] = {
> { },
> };
>
> +struct omap_rst_map am3_wkup_rst_map[] = {
static const here and below.
regards
Suman
> + { .rst = 3, .st = 5 },
> + { .rst = -1 },
> +};
> +
> +struct omap_prm_data am3_prm_data[] = {
> + { .name = "per", .base = 0x44e00c00, .pwstctrl = 0xc, .pwstst = 0x8, .flags = OMAP_PRM_NO_RSTST },
> + { .name = "wkup", .base = 0x44e00d00, .pwstctrl = 0x4, .pwstst = 0x8, .rstst = 0xc, .rstmap = am3_wkup_rst_map },
> + { .name = "mpu", .base = 0x44e00e00, .pwstst = 0x4 },
> + { .name = "device", .base = 0x44e00f00, .rstctl = 0x0, .rstst = 0x8 },
> + { .name = "rtc", .base = 0x44e01000, .pwstst = 0x4 },
> + { .name = "gfx", .base = 0x44e01100, .pwstst = 0x10, .rstctl = 0x4, .rstst = 0x14 },
> + { .name = "cefuse", .base = 0x44e01200, .pwstst = 0x4 },
> + { },
> +};
> +
> static const struct of_device_id omap_prm_id_table[] = {
> { .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
> + { .compatible = "ti,am3-prm-inst", .data = am3_prm_data },
> { },
> };
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/8] soc: ti: omap-prm: add omap4 PRM data
From: Suman Anna @ 2019-08-19 23:08 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1565164139-21886-6-git-send-email-t-kristo@ti.com>
On 8/7/19 2:48 AM, Tero Kristo wrote:
> Add PRM data for omap4 family of SoCs.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> drivers/soc/ti/omap_prm.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
> index 870515e3..9b8d5945 100644
> --- a/drivers/soc/ti/omap_prm.c
> +++ b/drivers/soc/ti/omap_prm.c
> @@ -54,7 +54,27 @@ struct omap_reset_data {
>
> #define OMAP_PRM_NO_RSTST BIT(0)
>
> +struct omap_prm_data omap4_prm_data[] = {
static const
regards
Suman
> + { .name = "mpu", .base = 0x4a306300, .pwstst = 0x4 },
> + { .name = "tesla", .base = 0x4a306400, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
> + { .name = "abe", .base = 0x4a306500, .pwstst = 0x4 },
> + { .name = "always_on_core", .base = 0x4a306600, .pwstst = 0x4 },
> + { .name = "core", .base = 0x4a306700, .pwstst = 0x4, .rstctl = 0x210, .rstst = 0x214 },
> + { .name = "ivahd", .base = 0x4a306f00, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
> + { .name = "cam", .base = 0x4a307000, .pwstst = 0x4 },
> + { .name = "dss", .base = 0x4a307100, .pwstst = 0x4 },
> + { .name = "gfx", .base = 0x4a307200, .pwstst = 0x4 },
> + { .name = "l3init", .base = 0x4a307300, .pwstst = 0x4 },
> + { .name = "l4per", .base = 0x4a307400, .pwstst = 0x4 },
> + { .name = "cefuse", .base = 0x4a307600, .pwstst = 0x4 },
> + { .name = "wkup", .base = 0x4a307700, .pwstst = 0x4 },
> + { .name = "emu", .base = 0x4a307900, .pwstst = 0x4 },
> + { .name = "device", .base = 0x4a307b00, .rstctl = 0x0, .rstst = 0x4 },
> + { },
> +};
> +
> static const struct of_device_id omap_prm_id_table[] = {
> + { .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
> { },
> };
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/8] soc: ti: add initial PRM driver with reset control support
From: Suman Anna @ 2019-08-19 23:01 UTC (permalink / raw)
To: Tero Kristo, Keerthy, ssantosh, linux-arm-kernel, linux-omap,
robh+dt
Cc: tony, devicetree
In-Reply-To: <59709a2d-f13a-bd55-8aba-864c1cf2f19e@ti.com>
Hi Tero,
On 8/19/19 4:32 AM, Tero Kristo wrote:
> On 08/08/2019 08:26, Keerthy wrote:
>>
>>
>> On 07/08/19 1:18 PM, Tero Kristo wrote:
>>> Add initial PRM (Power and Reset Management) driver for TI OMAP class
>>> SoCs. Initially this driver only supports reset control, but can be
>>> extended to support rest of the functionality, like powerdomain
>>> control, PRCM irq support etc.
>>>
>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>> ---
>>> arch/arm/mach-omap2/Kconfig | 1 +
>>> drivers/soc/ti/Makefile | 1 +
>>> drivers/soc/ti/omap_prm.c | 216
>>> ++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 218 insertions(+)
>>> create mode 100644 drivers/soc/ti/omap_prm.c
>>>
>>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>>> index fdb6743..42ad063 100644
>>> --- a/arch/arm/mach-omap2/Kconfig
>>> +++ b/arch/arm/mach-omap2/Kconfig
>>> @@ -109,6 +109,7 @@ config ARCH_OMAP2PLUS
>>> select TI_SYSC
>>> select OMAP_IRQCHIP
>>> select CLKSRC_TI_32K
>>> + select RESET_CONTROLLER
Use ARCH_HAS_RESET_CONTROLLER instead.
>>> help
>>> Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
>>> diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
>>> index b3868d3..788b5cd 100644
>>> --- a/drivers/soc/ti/Makefile
>>> +++ b/drivers/soc/ti/Makefile
>>> @@ -6,6 +6,7 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) += knav_qmss.o
>>> knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
>>> obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
>>> obj-$(CONFIG_AMX3_PM) += pm33xx.o
>>> +obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_prm.o
>>> obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
>>> obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
>>> obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
>>> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
>>> new file mode 100644
>>> index 0000000..7c89eb8
>>> --- /dev/null
>>> +++ b/drivers/soc/ti/omap_prm.c
>>> @@ -0,0 +1,216 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * OMAP2+ PRM driver
>>> + *
>>> + * Copyright (C) 2019 Texas Instruments Incorporated -
>>> http://www.ti.com/
>>> + * Tero Kristo <t-kristo@ti.com>
>>> + */
>>> +
>>> +#include <linux/kernel.h>
>>> +#include <linux/module.h>
>>> +#include <linux/device.h>
>>> +#include <linux/io.h>
>>> +#include <linux/of.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/reset-controller.h>
>>> +#include <linux/delay.h>
>>> +
>>> +struct omap_rst_map {
>>> + s8 rst;
>>> + s8 st;
>>> +};
>>> +
>>> +struct omap_prm_data {
>>> + u32 base;
>>> + const char *name;
>>> + u16 pwstctrl;
>>> + u16 pwstst;
>>> + u16 rstctl;
Minor nit, can you use rstctrl instead here so that it is in sync with
the other variables and with the register names used in TRM.
>>> + u16 rstst;
>>> + struct omap_rst_map *rstmap;
>>> + u8 flags;
>>> +};
>>> +
>>> +struct omap_prm {
>>> + const struct omap_prm_data *data;
>>> + void __iomem *base;
>>> +};
>>> +
>>> +struct omap_reset_data {
>>> + struct reset_controller_dev rcdev;
>>> + struct omap_prm *prm;
>>> +};
>>> +
>>> +#define to_omap_reset_data(p) container_of((p), struct
>>> omap_reset_data, rcdev)
>>> +
>>> +#define OMAP_MAX_RESETS 8
>>> +#define OMAP_RESET_MAX_WAIT 10000
>>> +
>>> +#define OMAP_PRM_NO_RSTST BIT(0)
>>> +
>>> +static const struct of_device_id omap_prm_id_table[] = {
>>> + { },
>>> +};
>>
>> This table is blank and we are doing of_match_device against it.
>
> Yes, it gets populated with other patches in series, one entry per soc.
>
>>
>>> +
>>> +static int omap_reset_status(struct reset_controller_dev *rcdev,
>>> + unsigned long id)
>>> +{
>>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>>> + u32 v;
>>> +
>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
>>> + v &= 1 << id;
>>> + v >>= id;
>>> +
>>> + return v;
>>> +}
>>> +
>>> +static int omap_reset_assert(struct reset_controller_dev *rcdev,
>>> + unsigned long id)
>>> +{
>>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>>> + u32 v;
>>> +
>>> + /* assert the reset control line */
>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>>> + v |= 1 << id;
>>> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int omap_reset_get_st_bit(struct omap_reset_data *reset,
>>> + unsigned long id)
>>> +{
>>> + struct omap_rst_map *map = reset->prm->data->rstmap;
>>> +
>>> + while (map && map->rst >= 0) {
>>> + if (map->rst == id)
>>> + return map->st;
>>> +
>>> + map++;
>>> + }
>>> +
>>> + return id;
>>> +}
>>> +
>>> +/*
>>> + * Note that status will not change until clocks are on, and clocks
>>> cannot be
>>> + * enabled until reset is deasserted. Consumer drivers must check
>>> status
>>> + * separately after enabling clocks.
>>> + */
>>> +static int omap_reset_deassert(struct reset_controller_dev *rcdev,
>>> + unsigned long id)
>>> +{
>>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>>> + u32 v;
>>> + int st_bit = id;
No need to initialize this, will always get overwritten below.
>>> + bool has_rstst;
>>> +
>>> + /* check the current status to avoid de-asserting the line twice */
>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>>> + if (!(v & BIT(id)))
>>> + return -EEXIST;
>>> +
>>> + has_rstst = !(reset->prm->data->flags & OMAP_PRM_NO_RSTST);
>>> +
>>> + if (has_rstst) {
>>> + st_bit = omap_reset_get_st_bit(reset, id);
>>> +
>>> + /* Clear the reset status by writing 1 to the status bit */
>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
>>> + v |= 1 << st_bit;
>>> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstst);
>>> + }
>>> +
>>> + /* de-assert the reset control line */
>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>>> + v &= ~(1 << id);
>>> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static const struct reset_control_ops omap_reset_ops = {
>>> + .assert = omap_reset_assert,
>>> + .deassert = omap_reset_deassert,
>>> + .status = omap_reset_status,
>>> +};
>>> +
>>> +static int omap_prm_reset_probe(struct platform_device *pdev,
>>> + struct omap_prm *prm)
Call this omap_prm_reset_init or something similar to avoid confusion.
>>> +{
>>> + struct omap_reset_data *reset;
>>> +
>>> + /*
>>> + * Check if we have resets. If either rstctl or rstst is
>>> + * non-zero, we have reset registers in place. Additionally
>>> + * the flag OMAP_PRM_NO_RSTST implies that we have resets.
>>> + */
>>> + if (!prm->data->rstctl && !prm->data->rstst &&
>>> + !(prm->data->flags & OMAP_PRM_NO_RSTST))
>>> + return 0;
>>> +
>>> + reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
>>> + if (!reset)
>>> + return -ENOMEM;
>>> +
>>> + reset->rcdev.owner = THIS_MODULE;
>>> + reset->rcdev.ops = &omap_reset_ops;
>>> + reset->rcdev.of_node = pdev->dev.of_node;
>>> + reset->rcdev.nr_resets = OMAP_MAX_RESETS;
Suggest adding a number of resets to prm->data, and using it so that we
don't even entertain any resets beyond the actual number of resets.
You actually seem to be using the bit-position directly in client data
instead of a reset number. I am not sure if this is accepted practice
with reset controllers, do you incur any memory wastage?
>>> +
>>> + reset->prm = prm;
>>> +
>>> + return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
>>> +}
>>> +
>>> +static int omap_prm_probe(struct platform_device *pdev)
>>> +{
>>> + struct resource *res;
>>> + const struct omap_prm_data *data;
>>> + struct omap_prm *prm;
>>> + const struct of_device_id *match;
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + if (!res)
>>> + return -ENODEV;
>>> +
>>> + match = of_match_device(omap_prm_id_table, &pdev->dev);
>>> + if (!match)
>>> + return -ENOTSUPP;
Use of_device_get_match_data() instead to do both match and get the
data. That can perhaps be the first block.
>>> +
>>> + prm = devm_kzalloc(&pdev->dev, sizeof(*prm), GFP_KERNEL);
>>> + if (!prm)
>>> + return -ENOMEM;
Perhaps move the allocate after the match check to streamline.
>>> +
>>> + data = match->data;
>>> +
>>> + while (data->base != res->start) {
>>> + if (!data->base)
>>> + return -EINVAL;
>>> + data++;
>>> + }
>>> +
>>> + prm->data = data;
>>> +
>>> + prm->base = devm_ioremap_resource(&pdev->dev, res);
>>> + if (!prm->base)
>>> + return -ENOMEM;
>>> +
>>> + return omap_prm_reset_probe(pdev, prm);
>>> +}
>>> +
>>> +static struct platform_driver omap_prm_driver = {
>>> + .probe = omap_prm_probe,
>>> + .driver = {
>>> + .name = KBUILD_MODNAME,
>>> + .of_match_table = omap_prm_id_table,
>>> + },
>>> +};
>>> +builtin_platform_driver(omap_prm_driver);
>>> +
>>> +MODULE_ALIAS("platform:prm");
Drop this and use MODULE_DEVICE_TABLE instead on omap_prm_id_table if
retaining, but I don't think these need to be defined.
regards
Suman
>>> +MODULE_LICENSE("GPL v2");
>>> +MODULE_DESCRIPTION("omap2+ prm driver");
>>
>> It is a builtin_platform_driver so do we need the MODULE*?
>
> Well, thats debatable, however some existing drivers do introduce this
> even if they are builtin.
>
> -Tero
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox