* Re: [PATCH v2 4/6] arm64: dts: meson: sei510: Add minimal thermal zone
From: guillaume La Roque @ 2019-08-05 12:48 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree, linux-pm, khilman, daniel.lezcano, linux-kernel,
linux-amlogic, linux-arm-kernel
In-Reply-To: <CAFBinCD-DUEjPgfUEJmHpPjw1ShZy7nemaFBKANmM5M42XBG4Q@mail.gmail.com>
Hi Martin,
On 8/3/19 8:29 PM, Martin Blumenstingl wrote:
> Hi Guillaume,
>
> On Wed, Jul 31, 2019 at 5:36 PM Guillaume La Roque
> <glaroque@baylibre.com> wrote:
>> Add minimal thermal zone for DDR and CPU sensor
> so high DDR (controller?) temperatures will throttle Mali and high PLL
> temperatures will throttle the CPU?
> to get things started I'm fine with this, but I think it should be
> mentioned here
i will add in commit description
>
>> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
>> ---
>> .../boot/dts/amlogic/meson-g12a-sei510.dts | 56 +++++++++++++++++++
>> 1 file changed, 56 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
>> index 979449968a5f..2c16a2cba0a3 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
>> @@ -10,6 +10,7 @@
>> #include <dt-bindings/input/input.h>
>> #include <dt-bindings/gpio/meson-g12a-gpio.h>
>> #include <dt-bindings/sound/meson-g12a-tohdmitx.h>
>> +#include <dt-bindings/thermal/thermal.h>
>>
>> / {
>> compatible = "seirobotics,sei510", "amlogic,g12a";
>> @@ -33,6 +34,53 @@
>> ethernet0 = ðmac;
>> };
>>
>> + thermal-zones {
>> + cpu-thermal {
>> + polling-delay = <1000>;
>> + polling-delay-passive = <100>;
>> + thermal-sensors = <&cpu_temp>;
>> +
>> + trips {
>> + cpu_critical: cpu-critical {
>> + temperature = <110000>; /* millicelsius */
>> + hysteresis = <2000>; /* millicelsius */
>> + type = "critical";
>> + };
>> + };
>> +
>> + cooling-maps {
>> + map {
>> + trip = <&cpu_critical>;
>> + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
>> + };
>> + };
>> + };
>> +
>> + ddr-thermal {
>> + polling-delay = <1000>;
>> + polling-delay-passive = <100>;
>> + thermal-sensors = <&ddr_temp>;
>> +
>> + trips {
>> + ddr_critical: ddr-critical {
>> + temperature = <110000>; /* millicelsius */
>> + hysteresis = <2000>; /* millicelsius */
>> + type = "critical";
>> + };
>> + };
>> +
>> + cooling-maps {
>> + map {
>> + trip = <&ddr_critical>;
>> + cooling-device = <&mali THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
>> + };
>> + };
>> + };
>> + };
>> +
>> mono_dac: audio-codec-0 {
>> compatible = "maxim,max98357a";
>> #sound-dai-cells = <0>;
>> @@ -321,6 +369,7 @@
>> operating-points-v2 = <&cpu_opp_table>;
>> clocks = <&clkc CLKID_CPU_CLK>;
>> clock-latency = <50000>;
>> + #cooling-cells = <2>;
>> };
>>
>> &cpu1 {
>> @@ -328,6 +377,7 @@
>> operating-points-v2 = <&cpu_opp_table>;
>> clocks = <&clkc CLKID_CPU_CLK>;
>> clock-latency = <50000>;
>> + #cooling-cells = <2>;
>> };
>>
>> &cpu2 {
>> @@ -335,6 +385,7 @@
>> operating-points-v2 = <&cpu_opp_table>;
>> clocks = <&clkc CLKID_CPU_CLK>;
>> clock-latency = <50000>;
>> + #cooling-cells = <2>;
>> };
>>
>> &cpu3 {
>> @@ -342,6 +393,7 @@
>> operating-points-v2 = <&cpu_opp_table>;
>> clocks = <&clkc CLKID_CPU_CLK>;
>> clock-latency = <50000>;
>> + #cooling-cells = <2>;
>> };
>>
>> &cvbs_vdac_port {
>> @@ -368,6 +420,10 @@
>> status = "okay";
>> };
>>
>> +&mali {
>> + #cooling-cells = <2>;
>> +};
> is there something device-specific in this patch? I'm wondering
> whether we can move all of this go g12a.dtsi to simplify maintenance
> in the future
this is depending of each board. actually it's same on all
but if a new one have a fan this value should be different or not.
>
>
> Martin
thanks,
Guillaume
_______________________________________________
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 02/14] usb: udc: lpc32xx: allow compile-testing
From: Sylvain Lemieux @ 2019-08-05 12:47 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Felipe Balbi, LINUXWATCHDOG, Linux Kernel Mailing List,
Jason Cooper, Arnd Bergmann, Andrew Lunn, Networking,
Gregory Clement, USB list, Russell King, Vladimir Zapolskiy,
open list:GPIO SUBSYSTEM, soc, David S. Miller, Alan Stern,
Guenter Roeck, linux-serial, Alexandre Belloni, Linus Walleij,
moderated list:ARM PORT, Sebastian Hesselbarth
In-Reply-To: <20190801055821.GB24607@kroah.com>
Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
On Thu, Aug 1, 2019 at 1:58 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jul 31, 2019 at 09:56:44PM +0200, Arnd Bergmann wrote:
> > The only thing that prevents building this driver on other
> > platforms is the mach/hardware.h include, which is not actually
> > used here at all, so remove the line and allow CONFIG_COMPILE_TEST.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > drivers/usb/gadget/udc/Kconfig | 3 ++-
> > drivers/usb/gadget/udc/lpc32xx_udc.c | 2 --
> > 2 files changed, 2 insertions(+), 3 deletions(-)
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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 04/14] serial: lpc32xx_hs: allow compile-testing
From: Sylvain Lemieux @ 2019-08-05 12:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Andrew Lunn, LINUXWATCHDOG, Linux Kernel Mailing List,
Jason Cooper, Arnd Bergmann, David S. Miller, Networking,
Gregory Clement, USB list, Russell King, Vladimir Zapolskiy,
open list:GPIO SUBSYSTEM, soc, Alan Stern, Guenter Roeck,
linux-serial, Jiri Slaby, Linus Walleij, moderated list:ARM PORT,
Sebastian Hesselbarth
In-Reply-To: <20190801055840.GC24607@kroah.com>
Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
On Thu, Aug 1, 2019 at 1:58 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jul 31, 2019 at 09:56:46PM +0200, Arnd Bergmann wrote:
> > The only thing that prevents building this driver on other
> > platforms is the mach/hardware.h include, which is not actually
> > used here at all, so remove the line and allow CONFIG_COMPILE_TEST.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > drivers/tty/serial/Kconfig | 3 ++-
> > drivers/tty/serial/lpc32xx_hs.c | 2 --
> > 2 files changed, 2 insertions(+), 3 deletions(-)
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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 03/14] watchdog: pnx4008_wdt: allow compile-testing
From: Sylvain Lemieux @ 2019-08-05 12:42 UTC (permalink / raw)
To: Guenter Roeck
Cc: Andrew Lunn, LINUXWATCHDOG, Linux Kernel Mailing List,
Jason Cooper, Arnd Bergmann, David S. Miller, Greg Kroah-Hartman,
Gregory Clement, USB list, Russell King, Vladimir Zapolskiy,
open list:GPIO SUBSYSTEM, soc, Alan Stern, linux-serial,
Networking, Wim Van Sebroeck, Linus Walleij, Linux ARM,
Sebastian Hesselbarth
In-Reply-To: <20190731203646.GB14817@roeck-us.net>
Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
On Wed, Jul 31, 2019 at 4:36 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Wed, Jul 31, 2019 at 10:26:35PM +0200, Arnd Bergmann wrote:
> > On Wed, Jul 31, 2019 at 10:23 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > On Wed, Jul 31, 2019 at 09:56:45PM +0200, Arnd Bergmann wrote:
> > > > The only thing that prevents building this driver on other
> > > > platforms is the mach/hardware.h include, which is not actually
> > > > used here at all, so remove the line and allow CONFIG_COMPILE_TEST.
> > > >
> > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > >
> > > Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> > >
> > > What is the plan for this patch ? Push through watchdog
> > > or through your branch ?
> >
> > I would prefer my branch so I can apply the final patch without waiting
> > for another release. Not in a hurry though, so if some other maintainer
>
> Ok with me.
>
> Guenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] arm64: dts: rockchip: Add dts for Leez RK3399 P710 SBC
From: Andy Yan @ 2019-08-05 12:40 UTC (permalink / raw)
To: heiko
Cc: devicetree, Andy Yan, linux-kernel, linux-rockchip, robh+dt,
linux-arm-kernel
P710 is a RK3399 based SBC, designed by Leez [0].
Specification
- Rockchip RK3399
- 4/2GB LPDDR4
- TF sd scard slot
- eMMC
- M.2 B-Key for 4G LTE
- AP6256 for WiFi + BT
- Gigabit ethernet
- HDMI out
- 40 pin header
- USB 2.0 x 2
- USB 3.0 x 1
- USB 3.0 Type-C x 1
- TYPE-C Power supply
[0]https://leez.lenovo.com
Signed-off-by: Andy Yan <andyshrk@gmail.com>
---
Changes in v2:
- Add vendor entry for Leez
- Rework the regulator tree
- Fix some pinctrl names
.../devicetree/bindings/arm/rockchip.yaml | 5 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-leez-p710.dts | 645 ++++++++++++++++++
4 files changed, 653 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 34865042f4e4..da9cd947abfa 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -329,6 +329,11 @@ properties:
- khadas,edge-v
- const: rockchip,rk3399
+ - description: Leez RK3399 P710
+ items:
+ - const: leez,p710
+ - const: rockchip,rk3399
+
- description: mqmaker MiQi
items:
- const: mqmaker,miqi
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 6992bbbbffab..4be4d9c367b9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -503,6 +503,8 @@ patternProperties:
description: Lantiq Semiconductor
"^lattice,.*":
description: Lattice Semiconductor
+ "^leez,.*":
+ description: Leez
"^lego,.*":
description: LEGO Systems A/S
"^lemaker,.*":
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index daa2c78e22c3..1f18a9392d15 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-hugsun-x99.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-captain.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-v.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
new file mode 100644
index 000000000000..32baa57b9481
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
@@ -0,0 +1,645 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Andy Yan <andy.yan@gmail.com>
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+ model = "Leez RK3399 P710";
+ compatible = "leez,p710", "rockchip,rk3399";
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <125000000>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rk808 1>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_reg_on_h>;
+ reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
+ };
+
+ dc5v_adp: dc5v-adp {
+ compatible = "regulator-fixed";
+ regulator-name = "dc5v_adapter";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ vcc5v0_sys: vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc5v_adp>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc5v0_host0: vcc5v0_host1: vcc5v0-host {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_host";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <5500000>;
+ regulator-max-microvolt = <5500000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc5v0_host3: vcc5v0-host3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_host3";
+ enable-active-high;
+ gpio = <&gpio2 RK_PA2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_host3_en>;
+ regulator-always-on;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc3v3_lan: vcc3v3-lan {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_lan";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vim-supply = <&vcc3v3_sys>;
+ };
+
+ vdd_log: vdd-log {
+ compatible = "pwm-regulator";
+ pwms = <&pwm2 0 25000 1>;
+ regulator-name = "vdd_log";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1400000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+};
+
+&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";
+};
+
+&gmac {
+ assigned-clocks = <&cru SCLK_RMII_SRC>;
+ assigned-clock-parents = <&clkin_gmac>;
+ clock_in_out = "input";
+ phy-supply = <&vcc3v3_lan>;
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 50000>;
+ tx_delay = <0x28>;
+ rx_delay = <0x11>;
+ status = "okay";
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c7>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ status = "okay";
+};
+
+&hdmi_sound {
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <400000>;
+ i2c-scl-rising-time-ns = <168>;
+ i2c-scl-falling-time-ns = <4>;
+ status = "okay";
+
+ rk808: pmic@1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+ #clock-cells = <1>;
+ clock-output-names = "xin32k", "rk808-clkout2";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ rockchip,system-power-controller;
+ wakeup-source;
+
+ vcc1-supply = <&vcc5v0_sys>;
+ vcc2-supply = <&vcc5v0_sys>;
+ vcc3-supply = <&vcc5v0_sys>;
+ vcc4-supply = <&vcc5v0_sys>;
+ vcc6-supply = <&vcc5v0_sys>;
+ vcc7-supply = <&vcc5v0_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc5v0_sys>;
+ vcc10-supply = <&vcc5v0_sys>;
+ vcc11-supply = <&vcc5v0_sys>;
+ vcc12-supply = <&vcc3v3_sys>;
+ vddio-supply = <&vcc_1v8>;
+
+ regulators {
+ vdd_center: DCDC_REG1 {
+ regulator-name = "vdd_center";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_l: DCDC_REG2 {
+ regulator-name = "vdd_cpu_l";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_1v8: DCDC_REG4 {
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc1v8_dvp: LDO_REG1 {
+ regulator-name = "vcc1v8_dvp";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8_hdmi: LDO_REG2 {
+ regulator-name = "vcc1v8_hdmi";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_1v8: LDO_REG3 {
+ regulator-name = "vcca_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vccio_sd: LDO_REG4 {
+ regulator-name = "vccio_sd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ vcca3v0_codec: LDO_REG5 {
+ regulator-name = "vcca3v0_codec";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v5: LDO_REG6 {
+ regulator-name = "vcc_1v5";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1500000>;
+ };
+ };
+
+ vcc0v9_hdmi: LDO_REG7 {
+ regulator-name = "vcc0v9_hdmi";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v0: LDO_REG8 {
+ regulator-name = "vcc_3v0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+ };
+ };
+
+ vdd_cpu_b: regulator@40 {
+ compatible = "silergy,syr827";
+ reg = <0x40>;
+ fcs,suspend-voltage-selector = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vsel1_gpio>;
+ regulator-name = "vdd_cpu_b";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: regulator@41 {
+ compatible = "silergy,syr828";
+ reg = <0x41>;
+ fcs,suspend-voltage-selector = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vsel2_gpio>;
+ regulator-name = "vdd_gpu";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+&i2c1 {
+ i2c-scl-rising-time-ns = <300>;
+ i2c-scl-falling-time-ns = <15>;
+ status = "okay";
+};
+
+&i2c3 {
+ i2c-scl-rising-time-ns = <450>;
+ i2c-scl-falling-time-ns = <15>;
+ status = "okay";
+};
+
+&i2c4 {
+ i2c-scl-rising-time-ns = <600>;
+ i2c-scl-falling-time-ns = <20>;
+ status = "okay";
+};
+
+&i2c7 {
+ status = "okay";
+};
+
+&i2s0 {
+ rockchip,playback-channels = <8>;
+ rockchip,capture-channels = <8>;
+ status = "okay";
+};
+
+&i2s1 {
+ rockchip,playback-channels = <2>;
+ rockchip,capture-channels = <2>;
+ status = "okay";
+};
+
+&i2s2 {
+ status = "okay";
+};
+
+&io_domains {
+ status = "okay";
+
+ bt656-supply = <&vcc1v8_dvp>;
+ audio-supply = <&vcc_1v8>;
+ sdmmc-supply = <&vccio_sd>;
+ gpio1830-supply = <&vcc_3v0>;
+};
+
+&pmu_io_domains {
+ status = "okay";
+ pmu1830-supply = <&vcc_3v0>;
+};
+
+&pinctrl {
+ bt {
+ bt_reg_on_h: bt-reg-on-h {
+ rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_host_wake_l: bt-host-wake-l {
+ rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_l: bt-wake-l {
+ rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ vsel1_gpio: vsel1-gpio {
+ rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ vsel2_gpio: vsel2-gpio {
+ rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ usb2 {
+ vcc5v0_host3_en: vcc5v0-host3-en {
+ rockchip,pins = <2 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wifi {
+ wifi_reg_on_h: wifi-reg-on-h {
+ rockchip,pins =
+ <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ wifi_host_wake_l: wifi-host-wake-l {
+ rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&saradc {
+ status = "okay";
+
+ vref-supply = <&vcc_1v8>;
+};
+
+&sdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ clock-frequency = <50000000>;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
+ sd-uhs-sdr104;
+ status = "okay";
+
+ brcmf: wifi@1 {
+ compatible = "brcm,bcm4329-fmac";
+ reg = <1>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;
+ interrupt-names = "host-wake";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_host_wake_l>;
+ };
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ max-frequency = <150000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_clk &sdmmc_cd &sdmmc_cmd &sdmmc_bus4>;
+ status = "okay";
+};
+
+&sdhci {
+ bus-width = <8>;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ non-removable;
+ status = "okay";
+};
+
+&tcphy0 {
+ status = "okay";
+};
+
+&tcphy1 {
+ status = "okay";
+};
+
+&tsadc {
+ status = "okay";
+
+ /* tshut mode 0:CRU 1:GPIO */
+ rockchip,hw-tshut-mode = <1>;
+ /* tshut polarity 0:LOW 1:HIGH */
+ rockchip,hw-tshut-polarity = <1>;
+};
+
+&u2phy0 {
+ status = "okay";
+
+ u2phy0_otg: otg-port {
+ status = "okay";
+ };
+
+ u2phy0_host: host-port {
+ phy-supply = <&vcc5v0_host0>;
+ status = "okay";
+ };
+};
+
+&u2phy1 {
+ status = "okay";
+
+ u2phy1_otg: otg-port {
+ status = "okay";
+ };
+
+ u2phy1_host: host-port {
+ phy-supply = <&vcc5v0_host1>;
+ status = "okay";
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_cts &uart0_rts>;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ clocks = <&rk808 1>;
+ clock-names = "ext_clock";
+ device-wakeup-gpios = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>;
+ host-wakeup-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>;
+ shutdown-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_host_wake_l &bt_wake_l &bt_reg_on_h>;
+ };
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&usbdrd3_0 {
+ status = "okay";
+};
+
+&usbdrd_dwc3_0 {
+ status = "okay";
+ dr_mode = "otg";
+};
+
+&usbdrd3_1 {
+ status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+ status = "okay";
+ dr_mode = "host";
+};
+
+&vopb {
+ status = "okay";
+};
+
+&vopb_mmu {
+ status = "okay";
+};
+
+&vopl {
+ status = "okay";
+};
+
+&vopl_mmu {
+ 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 related
* Re: [PATCH v2 6/6] firmware: arm_scmi: Check if platform has released shmem before using
From: Etienne Carriere @ 2019-08-05 12:33 UTC (permalink / raw)
To: Sudeep Holla
Cc: Peng Fan, linux-kernel, Bo Zhang, Jim Quinlan, Gaku Inami,
Volodymyr Babchuk, linux-arm-kernel
In-Reply-To: <20190726134531.8928-7-sudeep.holla@arm.com>
Hello Sudeep,
On Fri, 26 Jul 2019 at 15:46, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> Sometimes platfom may take too long to respond to the command and OS
> might timeout before platform transfer the ownership of the shared
> memory region to the OS with the response.
>
> Since the mailbox channel associated with the channel is freed and new
> commands are dispatch on the same channel, OS needs to wait until it
> gets back the ownership. If not, either OS may end up overwriting the
> platform response for the last command(which is fine as OS timed out
> that command) or platform might overwrite the payload for the next
> command with the response for the old.
>
> The latter is problematic as platform may end up interpretting the
> response as the payload. In order to avoid such race, let's wait until
> the OS gets back the ownership before we prepare the shared memory with
> the payload for the next command.
>
> Reported-by: Jim Quinlan <james.quinlan@broadcom.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/firmware/arm_scmi/driver.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index 69bf85fea967..765573756987 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -265,6 +265,14 @@ static void scmi_tx_prepare(struct mbox_client *cl, void *m)
> struct scmi_chan_info *cinfo = client_to_scmi_chan_info(cl);
> struct scmi_shared_mem __iomem *mem = cinfo->payload;
>
> + /*
> + * Ideally channel must be free by now unless OS timeout last
> + * request and platform continued to process the same, wait
> + * until it releases the shared memory, otherwise we may endup
> + * overwriting it's response with new command payload or vice-versa
minor typo: s/it's/its/
maybe also s/command/message/
regards,
etienne
> + */
> + spin_until_cond(ioread32(&mem->channel_status) &
> + SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE);
> /* Mark channel busy + clear error */
> iowrite32(0x0, &mem->channel_status);
> iowrite32(t->hdr.poll_completion ? 0 : SCMI_SHMEM_FLAG_INTR_ENABLED,
> --
> 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] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:25 UTC (permalink / raw)
To: robh+dt
Cc: devicetree, Neil Armstrong, martin.blumenstingl, netdev,
linux-kernel, linux-amlogic, linux-arm-kernel
Now that we have the DT validation in place, let's convert the device tree
bindings for the Synopsys DWMAC Glue for Amlogic SoCs over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Rob,
I keep getting :
.../devicetree/bindings/net/amlogic,meson-dwmac.example.dt.yaml: ethernet@c9410000: reg: [[3376480256, 65536], [3364046144, 8]] is too long
for the example DT
and for the board DT :
../amlogic/meson-gxl-s905x-libretech-cc.dt.yaml: ethernet@c9410000: reg: [[0, 3376480256, 0, 65536, 0, 3364046144, 0, 4]] is too short
../amlogic/meson-gxl-s905x-nexbox-a95x.dt.yaml: soc: ethernet@c9410000:reg:0: [0, 3376480256, 0, 65536, 0, 3364046144, 0, 4] is too long
and I don't know how to get rid of it.
What should I do for reg ?
Neil
.../bindings/net/amlogic,meson-dwmac.yaml | 113 ++++++++++++++++++
.../devicetree/bindings/net/meson-dwmac.txt | 71 -----------
.../devicetree/bindings/net/snps,dwmac.yaml | 5 +
3 files changed, 118 insertions(+), 71 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
new file mode 100644
index 000000000000..ae91aa9d8616
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson DWMAC Ethernet controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+ - Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+# We need a select here so we don't match all nodes with 'snps,dwmac'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ required:
+ - compatible
+
+allOf:
+ - $ref: "snps,dwmac.yaml#"
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: GMAC main clock
+ - description: First parent clock of the internal mux
+ - description: Second parent clock of the internal mux
+
+ clock-names:
+ minItems: 3
+ maxItems: 3
+ items:
+ - const: stmmaceth
+ - const: clkin0
+ - const: clkin1
+
+ amlogic,tx-delay-ns:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description:
+ The internal RGMII TX clock delay (provided by this driver) in
+ nanoseconds. Allowed values are 0ns, 2ns, 4ns, 6ns.
+ When phy-mode is set to "rgmii" then the TX delay should be
+ explicitly configured. When not configured a fallback of 2ns is
+ used. When the phy-mode is set to either "rgmii-id" or "rgmii-txid"
+ the TX clock delay is already provided by the PHY. In that case
+ this property should be set to 0ns (which disables the TX clock
+ delay in the MAC to prevent the clock from going off because both
+ PHY and MAC are adding a delay).
+ Any configuration is ignored when the phy-mode is set to "rmii".
+
+properties:
+ compatible:
+ additionalItems: true
+ maxItems: 3
+ items:
+ - enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ contains:
+ enum:
+ - snps,dwmac-3.70a
+ - snps,dwmac
+
+ reg:
+ items:
+ - description:
+ The first register range should be the one of the DWMAC controller
+ - description:
+ The second range is is for the Amlogic specific configuration
+ (for example the PRG_ETHERNET register range on Meson8b and newer)
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - phy-mode
+
+examples:
+ - |
+ ethmac: ethernet@c9410000 {
+ compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+ reg = <0xc9410000 0x10000>, <0xc8834540 0x8>;
+ interrupts = <8>;
+ interrupt-names = "macirq";
+ clocks = <&clk_eth>, <&clkc_fclk_div2>, <&clk_mpll2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1";
+ phy-mode = "rgmii";
+ };
diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
deleted file mode 100644
index 1321bb194ed9..000000000000
--- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Amlogic Meson DWMAC Ethernet controller
-
-The device inherits all the properties of the dwmac/stmmac devices
-described in the file stmmac.txt in the current directory with the
-following changes.
-
-Required properties on all platforms:
-
-- compatible: Depending on the platform this should be one of:
- - "amlogic,meson6-dwmac"
- - "amlogic,meson8b-dwmac"
- - "amlogic,meson8m2-dwmac"
- - "amlogic,meson-gxbb-dwmac"
- - "amlogic,meson-axg-dwmac"
- Additionally "snps,dwmac" and any applicable more
- detailed version number described in net/stmmac.txt
- should be used.
-
-- reg: The first register range should be the one of the DWMAC
- controller. The second range is is for the Amlogic specific
- configuration (for example the PRG_ETHERNET register range
- on Meson8b and newer)
-
-Required properties on Meson8b, Meson8m2, GXBB and newer:
-- clock-names: Should contain the following:
- - "stmmaceth" - see stmmac.txt
- - "clkin0" - first parent clock of the internal mux
- - "clkin1" - second parent clock of the internal mux
-
-Optional properties on Meson8b, Meson8m2, GXBB and newer:
-- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided
- by this driver) in nanoseconds. Allowed values
- are: 0ns, 2ns, 4ns, 6ns.
- When phy-mode is set to "rgmii" then the TX
- delay should be explicitly configured. When
- not configured a fallback of 2ns is used.
- When the phy-mode is set to either "rgmii-id"
- or "rgmii-txid" the TX clock delay is already
- provided by the PHY. In that case this
- property should be set to 0ns (which disables
- the TX clock delay in the MAC to prevent the
- clock from going off because both PHY and MAC
- are adding a delay).
- Any configuration is ignored when the phy-mode
- is set to "rmii".
-
-Example for Meson6:
-
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson6-dwmac", "snps,dwmac";
- reg = <0xc9410000 0x10000
- 0xc1108108 0x4>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clk81>;
- clock-names = "stmmaceth";
- }
-
-Example for GXBB:
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
- reg = <0x0 0xc9410000 0x0 0x10000>,
- <0x0 0xc8834540 0x0 0x8>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clkc CLKID_ETH>,
- <&clkc CLKID_FCLK_DIV2>,
- <&clkc CLKID_MPLL2>;
- clock-names = "stmmaceth", "clkin0", "clkin1";
- phy-mode = "rgmii";
- };
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 76fea2be66ac..ff1dc662a4e3 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -50,6 +50,11 @@ properties:
- allwinner,sun8i-r40-emac
- allwinner,sun8i-v3s-emac
- allwinner,sun50i-a64-emac
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
- snps,dwmac
- snps,dwmac-3.50a
- snps,dwmac-3.610
--
2.22.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: [linux-sunxi] [PATCH 2/3] rtc: sun6i: Add support for H6 RTC
From: Clément Péron @ 2019-08-05 12:16 UTC (permalink / raw)
To: megous, Chen-Yu Tsai, Alessandro Zummo, Alexandre Belloni,
Rob Herring, Mark Rutland, Maxime Ripard, linux-rtc, devicetree,
linux-arm-kernel, linux-kernel, linux-sunxi
In-Reply-To: <20190805111037.76vmanzcurffpbdf@core.my.home>
Hi,
On Mon, 5 Aug 2019 at 13:10, Ondřej Jirman <megous@megous.com> wrote:
>
> On Mon, Aug 05, 2019 at 06:54:17PM +0800, Chen-Yu Tsai wrote:
> > On Mon, Aug 5, 2019 at 6:45 PM Ondřej Jirman <megous@megous.com> wrote:
> > >
[snip]
>
> Interesting. :) I have the BSP I was using saved here:
>
> https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n649
>
> It's based of 4.9.119
>
> https://megous.com/git/linux/log/?h=h6-4.9-bsp
>
> I don't remember where I found it. But I imported it fairly recently, and
> the code you pointed to looks like an older version that I can found in some
> beta H6 BSP, that I imported way earlier and is based on 4.9.56:
The last recent that I know is from OrangePi H6 but it's based on 4.9.118.
https://github.com/orangepi-xunlong/OrangePiH6_Linux4_9
Regards,
Clément
>
> https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=linux-h6
> https://megous.com/git/linux/log/?h=linux-h6
>
> Hmm, archeology. :)
>
> > > For older BSPs, the init sequence looked like this:
> > >
> > > 482 /*
> > > 483 * Step1: select RTC clock source
> > > 484 */
> > > 485 tmp_data = sunxi_rtc_read(SUNXI_LOSC_CTRL_REG);
> > > 486 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> > > 487 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> > > 488 tmp_data |= (EXT_LOSC_GSM);
> > > 489 sunxi_rtc_write(tmp_data, SUNXI_LOSC_CTRL_REG);
> > > 490
> > >
> > > EXT_LOSC_GSM has values 4 values from low to high, and I guess it configures
> > > gain for the oscillator's amplifier in the feedback loop of the circuit.
> > >
> > > So the new code, for some reason changed from single write to sequence
> > > of individual writes/config steps:
> > >
> > > 1) disable auto-switch and enable auto-switch bypass
> > > 2) select RTC clock source (to LOSC)
> > > (wait)
> >
> > Maybe it's possible to glitch if these two are combined?
>
> That's what I thought too. Or the programmer thought so, and was just
> programming defensively, and there's no real problem in the practice.
>
> But that specific delay() seems like someone trying to solve a real issue. Of
> course there's no knowing if it was on H6 or on some other SoC.
>
> regards,
> o.
>
> >
> > > 3) configure gain on the LOSC
> > >
> > > regards,
> > > o.
> > >
> > > > ChenYu
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> > > To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190805104529.z3mex3m2tss7lzlr%40core.my.home.
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190805111037.76vmanzcurffpbdf%40core.my.home.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] KVM: arm: Don't write junk to CP15 registers on reset
From: Marc Zyngier @ 2019-08-05 12:15 UTC (permalink / raw)
To: kvm, kvmarm, linux-arm-kernel
Cc: Zenghui Yu, Andrew Jones, James Morse, Julien Thierry,
Suzuki K Poulose
In-Reply-To: <20190805121555.130897-1-maz@kernel.org>
At the moment, the way we reset CP15 registers is mildly insane:
We write junk to them, call the reset functions, and then check that
we have something else in them.
The "fun" thing is that this can happen while the guest is running
(PSCI, for example). If anything in KVM has to evaluate the state
of a CP15 register while junk is in there, bad thing may happen.
Let's stop doing that. Instead, we track that we have called a
reset function for that register, and assume that the reset
function has done something.
In the end, the very need of this reset check is pretty dubious,
as it doesn't check everything (a lot of the CP15 reg leave outside
of the cp15_regs[] array). It may well be axed in the near future.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm/kvm/coproc.c | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index d2806bcff8bb..07745ee022a1 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -651,13 +651,22 @@ int kvm_handle_cp14_64(struct kvm_vcpu *vcpu, struct kvm_run *run)
}
static void reset_coproc_regs(struct kvm_vcpu *vcpu,
- const struct coproc_reg *table, size_t num)
+ const struct coproc_reg *table, size_t num,
+ unsigned long *bmap)
{
unsigned long i;
for (i = 0; i < num; i++)
- if (table[i].reset)
+ if (table[i].reset) {
+ int reg = table[i].reg;
+
table[i].reset(vcpu, &table[i]);
+ if (reg > 0 && reg < NR_CP15_REGS) {
+ set_bit(reg, bmap);
+ if (table[i].is_64bit)
+ set_bit(reg + 1, bmap);
+ }
+ }
}
static struct coproc_params decode_32bit_hsr(struct kvm_vcpu *vcpu)
@@ -1432,17 +1441,15 @@ void kvm_reset_coprocs(struct kvm_vcpu *vcpu)
{
size_t num;
const struct coproc_reg *table;
-
- /* Catch someone adding a register without putting in reset entry. */
- memset(vcpu->arch.ctxt.cp15, 0x42, sizeof(vcpu->arch.ctxt.cp15));
+ DECLARE_BITMAP(bmap, NR_CP15_REGS) = { 0, };
/* Generic chip reset first (so target could override). */
- reset_coproc_regs(vcpu, cp15_regs, ARRAY_SIZE(cp15_regs));
+ reset_coproc_regs(vcpu, cp15_regs, ARRAY_SIZE(cp15_regs), bmap);
table = get_target_table(vcpu->arch.target, &num);
- reset_coproc_regs(vcpu, table, num);
+ reset_coproc_regs(vcpu, table, num, bmap);
for (num = 1; num < NR_CP15_REGS; num++)
- WARN(vcpu_cp15(vcpu, num) == 0x42424242,
+ WARN(!test_bit(num, bmap),
"Didn't reset vcpu_cp15(vcpu, %zi)", num);
}
--
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
* [PATCH 1/2] KVM: arm64: Don't write junk to sysregs on reset
From: Marc Zyngier @ 2019-08-05 12:15 UTC (permalink / raw)
To: kvm, kvmarm, linux-arm-kernel
Cc: Zenghui Yu, Andrew Jones, James Morse, Julien Thierry,
Suzuki K Poulose
In-Reply-To: <20190805121555.130897-1-maz@kernel.org>
At the moment, the way we reset system registers is mildly insane:
We write junk to them, call the reset functions, and then check that
we have something else in them.
The "fun" thing is that this can happen while the guest is running
(PSCI, for example). If anything in KVM has to evaluate the state
of a system register while junk is in there, bad thing may happen.
Let's stop doing that. Instead, we track that we have called a
reset function for that register, and assume that the reset
function has done something. This requires fixing a couple of
sysreg refinition in the trap table.
In the end, the very need of this reset check is pretty dubious,
as it doesn't check everything (a lot of the sysregs leave outside of
the sys_regs[] array). It may well be axed in the near future.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/sys_regs.c | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index f26e181d881c..2071260a275b 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -632,7 +632,7 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
*/
val = ((pmcr & ~ARMV8_PMU_PMCR_MASK)
| (ARMV8_PMU_PMCR_MASK & 0xdecafbad)) & (~ARMV8_PMU_PMCR_E);
- __vcpu_sys_reg(vcpu, PMCR_EL0) = val;
+ __vcpu_sys_reg(vcpu, r->reg) = val;
}
static bool check_pmu_access_disabled(struct kvm_vcpu *vcpu, u64 flags)
@@ -981,13 +981,13 @@ static bool access_pmuserenr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
{ SYS_DESC(SYS_DBGBVRn_EL1(n)), \
- trap_bvr, reset_bvr, n, 0, get_bvr, set_bvr }, \
+ trap_bvr, reset_bvr, 0, 0, get_bvr, set_bvr }, \
{ SYS_DESC(SYS_DBGBCRn_EL1(n)), \
- trap_bcr, reset_bcr, n, 0, get_bcr, set_bcr }, \
+ trap_bcr, reset_bcr, 0, 0, get_bcr, set_bcr }, \
{ SYS_DESC(SYS_DBGWVRn_EL1(n)), \
- trap_wvr, reset_wvr, n, 0, get_wvr, set_wvr }, \
+ trap_wvr, reset_wvr, 0, 0, get_wvr, set_wvr }, \
{ SYS_DESC(SYS_DBGWCRn_EL1(n)), \
- trap_wcr, reset_wcr, n, 0, get_wcr, set_wcr }
+ trap_wcr, reset_wcr, 0, 0, get_wcr, set_wcr }
/* Macro to expand the PMEVCNTRn_EL0 register */
#define PMU_PMEVCNTR_EL0(n) \
@@ -1540,7 +1540,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ SYS_DESC(SYS_CSSELR_EL1), access_csselr, reset_unknown, CSSELR_EL1 },
{ SYS_DESC(SYS_CTR_EL0), access_ctr },
- { SYS_DESC(SYS_PMCR_EL0), access_pmcr, reset_pmcr, },
+ { SYS_DESC(SYS_PMCR_EL0), access_pmcr, reset_pmcr, PMCR_EL0 },
{ SYS_DESC(SYS_PMCNTENSET_EL0), access_pmcnten, reset_unknown, PMCNTENSET_EL0 },
{ SYS_DESC(SYS_PMCNTENCLR_EL0), access_pmcnten, NULL, PMCNTENSET_EL0 },
{ SYS_DESC(SYS_PMOVSCLR_EL0), access_pmovs, NULL, PMOVSSET_EL0 },
@@ -2254,13 +2254,19 @@ static int emulate_sys_reg(struct kvm_vcpu *vcpu,
}
static void reset_sys_reg_descs(struct kvm_vcpu *vcpu,
- const struct sys_reg_desc *table, size_t num)
+ const struct sys_reg_desc *table, size_t num,
+ unsigned long *bmap)
{
unsigned long i;
for (i = 0; i < num; i++)
- if (table[i].reset)
+ if (table[i].reset) {
+ int reg = table[i].reg;
+
table[i].reset(vcpu, &table[i]);
+ if (reg > 0 && reg < NR_SYS_REGS)
+ set_bit(reg, bmap);
+ }
}
/**
@@ -2774,18 +2780,16 @@ void kvm_reset_sys_regs(struct kvm_vcpu *vcpu)
{
size_t num;
const struct sys_reg_desc *table;
-
- /* Catch someone adding a register without putting in reset entry. */
- memset(&vcpu->arch.ctxt.sys_regs, 0x42, sizeof(vcpu->arch.ctxt.sys_regs));
+ DECLARE_BITMAP(bmap, NR_SYS_REGS) = { 0, };
/* Generic chip reset first (so target could override). */
- reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
+ reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs), bmap);
table = get_target_table(vcpu->arch.target, true, &num);
- reset_sys_reg_descs(vcpu, table, num);
+ reset_sys_reg_descs(vcpu, table, num, bmap);
for (num = 1; num < NR_SYS_REGS; num++) {
- if (WARN(__vcpu_sys_reg(vcpu, num) == 0x4242424242424242,
+ if (WARN(!test_bit(num, bmap),
"Didn't reset __vcpu_sys_reg(%zi)\n", num))
break;
}
--
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
* [PATCH 0/2] KVM: arm/arm64: Revamp sysreg reset checks
From: Marc Zyngier @ 2019-08-05 12:15 UTC (permalink / raw)
To: kvm, kvmarm, linux-arm-kernel
Cc: Zenghui Yu, Andrew Jones, James Morse, Julien Thierry,
Suzuki K Poulose
The way we deal with sysreg reset is terrible, as we write junk to
them while other parts of the system may be evaluating these. That's
obviously wrong. Instead, let's switch to a mode where we track which
sysregs have had a reset function applied to them.
The result is less bad, but my gut feeling is that we'd be better of
without any of this. Comments welcome.
Marc Zyngier (2):
KVM: arm64: Don't write junk to sysregs on reset
KVM: arm: Don't write junk to CP15 registers on reset
arch/arm/kvm/coproc.c | 23 +++++++++++++++--------
arch/arm64/kvm/sys_regs.c | 32 ++++++++++++++++++--------------
2 files changed, 33 insertions(+), 22 deletions(-)
--
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
* [RFCv2 9/9] dt-bindings: watchdog: meson-gxbb-wdt: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt
Cc: linux-amlogic, devicetree, linux-watchdog, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic GXBB Watchdog timer over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../watchdog/amlogic,meson-gxbb-wdt.yaml | 37 +++++++++++++++++++
.../bindings/watchdog/meson-gxbb-wdt.txt | 16 --------
2 files changed, 37 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
delete mode 100644 Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml b/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
new file mode 100644
index 000000000000..d7352f709b37
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/watchdog/amlogic,meson-gxbb-wdt.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Meson GXBB SoCs Watchdog timer
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-gxbb-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description:
+ A phandle to the clock of this PHY
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+examples:
+ - |
+ watchdog@98d0 {
+ compatible = "amlogic,meson-gxbb-wdt";
+ reg = <0x98d0 0x10>;
+ clocks = <&xtal>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt b/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
deleted file mode 100644
index c7fe36fa739c..000000000000
--- a/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Meson GXBB SoCs Watchdog timer
-
-Required properties:
-
-- compatible : should be "amlogic,meson-gxbb-wdt"
-- reg : Specifies base physical address and size of the registers.
-- clocks : Should be a phandle to the Watchdog clock source, for GXBB the xtal
- is the default clock source.
-
-Example:
-
-wdt: watchdog@98d0 {
- compatible = "amlogic,meson-gxbb-wdt";
- reg = <0 0x98d0 0x0 0x10>;
- clocks = <&xtal>;
-};
--
2.22.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
* [RFCv2 7/9] dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt; +Cc: linux-amlogic, devicetree, kishon, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic G12A USB3 + PCIE Combo PHY over to a YAML schemas.
While the original phy bindings specifies phy-supply as required,
the examples and implementations makes it optional, thus phy-supply
is not present in the properties and required lists.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../phy/amlogic,meson-g12a-usb3-pcie-phy.yaml | 57 +++++++++++++++++++
.../bindings/phy/meson-g12a-usb3-pcie-phy.txt | 22 -------
2 files changed, 57 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml
delete mode 100644 Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml
new file mode 100644
index 000000000000..346f9c35427c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic G12A USB3 + PCIE Combo PHY
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-g12a-usb3-pcie-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: ref_clk
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: phy
+
+ "#phy-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - "#phy-cells"
+
+examples:
+ - |
+ phy@46000 {
+ compatible = "amlogic,meson-g12a-usb3-pcie-phy";
+ reg = <0x46000 0x2000>;
+ clocks = <&ref_clk>;
+ clock-names = "ref_clk";
+ resets = <&phy_reset>;
+ reset-names = "phy";
+ #phy-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt b/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
deleted file mode 100644
index 7cfc17e2df31..000000000000
--- a/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* Amlogic G12A USB3 + PCIE Combo PHY binding
-
-Required properties:
-- compatible: Should be "amlogic,meson-g12a-usb3-pcie-phy"
-- #phys-cells: must be 1. The cell number is used to select the phy mode
- as defined in <dt-bindings/phy/phy.h> between PHY_TYPE_USB3 and PHY_TYPE_PCIE
-- reg: The base address and length of the registers
-- clocks: a phandle to the 100MHz reference clock of this PHY
-- clock-names: must be "ref_clk"
-- resets: phandle to the reset lines for the PHY control
-- reset-names: must be "phy"
-
-Example:
- usb3_pcie_phy: phy@46000 {
- compatible = "amlogic,g12a-usb3-pcie-phy";
- reg = <0x0 0x46000 0x0 0x2000>;
- clocks = <&clkc CLKID_PCIE_PLL>;
- clock-names = "ref_clk";
- resets = <&reset RESET_PCIE_PHY>;
- reset-names = "phy";
- #phy-cells = <1>;
- };
--
2.22.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
* [RFCv2 3/9] dt-bindings: spi: meson: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt
Cc: linux-amlogic, devicetree, linux-spi, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic SPI controllers over to two separate YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/spi/amlogic,meson-gx-spicc.yaml | 67 +++++++++++++++++++
.../bindings/spi/amlogic,meson6-spifc.yaml | 53 +++++++++++++++
.../devicetree/bindings/spi/spi-meson.txt | 55 ---------------
3 files changed, 120 insertions(+), 55 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
create mode 100644 Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/spi-meson.txt
diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
new file mode 100644
index 000000000000..49b617c98ae7
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/spi/amlogic,meson-gx-spicc.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson SPI Communication Controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+description: |
+ The Meson SPICC is a generic SPI controller for general purpose Full-Duplex
+ communications with dedicated 16 words RX/TX PIO FIFOs.
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-gx-spicc # SPICC controller on Amlogic GX and compatible SoCs
+ - amlogic,meson-axg-spicc # SPICC controller on Amlogic AXG and compatible SoCs
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ description: input clock for the baud rate generator
+ items:
+ - const: core
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+examples:
+ - |
+ spi@c1108d80 {
+ compatible = "amlogic,meson-gx-spicc";
+ reg = <0xc1108d80 0x80>;
+ interrupts = <112>;
+ clocks = <&clk81>;
+ clock-names = "core";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-switch@0 {
+ compatible = "micrel,ks8995m";
+ spi-max-frequency = <1000000>;
+ reg = <0>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
new file mode 100644
index 000000000000..67dcedc81a5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/spi/amlogic,meson6-spifc.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson SPI Flash Controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+description: |
+ The Meson SPIFC is a controller optimized for communication with SPI
+ NOR memories, without DMA support and a 64-byte unified transmit /
+ receive buffer.
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson6-spifc # SPI Flash Controller on Meson6 and compatible SoCs
+ - amlogic,meson-gxbb-spifc # SPI Flash Controller on GXBB and compatible SoCs
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+examples:
+ - |
+ spi@c1108c80 {
+ compatible = "amlogic,meson6-spifc";
+ reg = <0xc1108c80 0x80>;
+ clocks = <&clk81>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash: m25p80@0 {
+ compatible = "spansion,m25p80", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/spi/spi-meson.txt b/Documentation/devicetree/bindings/spi/spi-meson.txt
deleted file mode 100644
index b7f5e86fed22..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-meson.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-Amlogic Meson SPI controllers
-
-* SPIFC (SPI Flash Controller)
-
-The Meson SPIFC is a controller optimized for communication with SPI
-NOR memories, without DMA support and a 64-byte unified transmit /
-receive buffer.
-
-Required properties:
- - compatible: should be "amlogic,meson6-spifc" or "amlogic,meson-gxbb-spifc"
- - reg: physical base address and length of the controller registers
- - clocks: phandle of the input clock for the baud rate generator
- - #address-cells: should be 1
- - #size-cells: should be 0
-
- spi@c1108c80 {
- compatible = "amlogic,meson6-spifc";
- reg = <0xc1108c80 0x80>;
- clocks = <&clk81>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
-
-* SPICC (SPI Communication Controller)
-
-The Meson SPICC is generic SPI controller for general purpose Full-Duplex
-communications with dedicated 16 words RX/TX PIO FIFOs.
-
-Required properties:
- - compatible: should be:
- "amlogic,meson-gx-spicc" on Amlogic GX and compatible SoCs.
- "amlogic,meson-axg-spicc" on Amlogic AXG and compatible SoCs
- - reg: physical base address and length of the controller registers
- - interrupts: The interrupt specifier
- - clock-names: Must contain "core"
- - clocks: phandle of the input clock for the baud rate generator
- - #address-cells: should be 1
- - #size-cells: should be 0
-
-Optional properties:
- - resets: phandle of the internal reset line
-
-See ../spi/spi-bus.txt for more details on SPI bus master and slave devices
-required and optional properties.
-
-Example :
- spi@c1108d80 {
- compatible = "amlogic,meson-gx-spicc";
- reg = <0xc1108d80 0x80>;
- interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
- clock-names = "core";
- clocks = <&clk81>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
--
2.22.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
* [RFCv2 8/9] dt-bindings: serial: meson-uart: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt
Cc: linux-amlogic, devicetree, linux-arm-kernel, linux-serial,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic UART Serial controller over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/serial/amlogic,meson-uart.txt | 38 ----------
.../bindings/serial/amlogic,meson-uart.yaml | 73 +++++++++++++++++++
2 files changed, 73 insertions(+), 38 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/serial/amlogic,meson-uart.txt
create mode 100644 Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.txt b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.txt
deleted file mode 100644
index c06c045126fc..000000000000
--- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Amlogic Meson SoC UART Serial Interface
-=======================================
-
-The Amlogic Meson SoC UART Serial Interface is present on a large range
-of SoCs, and can be present either in the "Always-On" power domain or the
-"Everything-Else" power domain.
-
-The particularity of the "Always-On" Serial Interface is that the hardware
-is active since power-on and does not need any clock gating and is usable
-as very early serial console.
-
-Required properties:
-- compatible : compatible: value should be different for each SoC family as :
- - Meson6 : "amlogic,meson6-uart"
- - Meson8 : "amlogic,meson8-uart"
- - Meson8b : "amlogic,meson8b-uart"
- - GX (GXBB, GXL, GXM) : "amlogic,meson-gx-uart"
- eventually followed by : "amlogic,meson-ao-uart" if this UART interface
- is in the "Always-On" power domain.
-- reg : offset and length of the register set for the device.
-- interrupts : identifier to the device interrupt
-- clocks : a list of phandle + clock-specifier pairs, one for each
- entry in clock names.
-- clock-names :
- * "xtal" for external xtal clock identifier
- * "pclk" for the bus core clock, either the clk81 clock or the gate clock
- * "baud" for the source of the baudrate generator, can be either the xtal
- or the pclk.
-
-e.g.
-uart_A: serial@84c0 {
- compatible = "amlogic,meson-gx-uart";
- reg = <0x0 0x84c0 0x0 0x14>;
- interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
- /* Use xtal as baud rate clock source */
- clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>;
- clock-names = "xtal", "pclk", "baud";
-};
diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
new file mode 100644
index 000000000000..5d48a8c04aa9
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/serial/amlogic,meson-uart.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson SoC UART Serial Interface
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+description: |
+ The Amlogic Meson SoC UART Serial Interface is present on a large range
+ of SoCs, and can be present either in the "Always-On" power domain or the
+ "Everything-Else" power domain.
+
+ The particularity of the "Always-On" Serial Interface is that the hardware
+ is active since power-on and does not need any clock gating and is usable
+ as very early serial console.
+
+properties:
+ compatible:
+ oneOf:
+ - description: Allways-on power domain UART controller
+ items:
+ - enum:
+ - amlogic,meson6-uart
+ - amlogic,meson8-uart
+ - amlogic,meson8b-uart
+ - amlogic,meson-gx-uart
+ - const: amlogic,meson-ao-uart
+ - description: Everything-Else power domain UART controller
+ enum:
+ - amlogic,meson6-uart
+ - amlogic,meson8-uart
+ - amlogic,meson8b-uart
+ - amlogic,meson-gx-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: external xtal clock identifier
+ - description: the bus core clock, either the clk81 clock or the gate clock
+ - description: the source of the baudrate generator, can be either the xtal or the pclk
+
+ clock-names:
+ items:
+ - const: xtal
+ - const: pclk
+ - const: baud
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+examples:
+ - |
+ serial@84c0 {
+ compatible = "amlogic,meson-gx-uart";
+ reg = <0x84c0 0x14>;
+ interrupts = <26>;
+ clocks = <&xtal>, <&pclk>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ };
--
2.22.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
* [RFCv2 4/9] dt-bindings: reset: amlogic,meson-reset: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt
Cc: linux-amlogic, devicetree, p.zabel, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic Reset controller over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/reset/amlogic,meson-reset.txt | 19 ----------
.../bindings/reset/amlogic,meson-reset.yaml | 37 +++++++++++++++++++
2 files changed, 37 insertions(+), 19 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
deleted file mode 100644
index 28ef6c295c76..000000000000
--- a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Amlogic Meson SoC Reset Controller
-=======================================
-
-Please also refer to reset.txt in this directory for common reset
-controller binding usage.
-
-Required properties:
-- compatible: Should be "amlogic,meson8b-reset", "amlogic,meson-gxbb-reset" or
- "amlogic,meson-axg-reset".
-- reg: should contain the register address base
-- #reset-cells: 1, see below
-
-example:
-
-reset: reset-controller {
- compatible = "amlogic,meson-gxbb-reset";
- reg = <0x0 0x04404 0x0 0x20>;
- #reset-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
new file mode 100644
index 000000000000..00917d868d58
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/reset/amlogic,meson-reset.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson SoC Reset Controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson8b-reset # Reset Controller on Meson8b and compatible SoCs
+ - amlogic,meson-gxbb-reset # Reset Controller on GXBB and compatible SoCs
+ - amlogic,meson-axg-reset # Reset Controller on AXG and compatible SoCs
+
+ reg:
+ maxItems: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#reset-cells"
+
+examples:
+ - |
+ reset-controller@c884404 {
+ compatible = "amlogic,meson-gxbb-reset";
+ reg = <0xc884404 0x20>;
+ #reset-cells = <1>;
+ };
--
2.22.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
* [RFCv2 6/9] dt-bindings: phy: meson-g12a-usb2-phy: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt; +Cc: linux-amlogic, devicetree, kishon, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic G12A USB2 PHY over to a YAML schemas.
While the original phy bindings specifies phy-supply as required,
the examples and implementations makes it optional, thus phy-supply
is not in the required list of attributes.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../phy/amlogic,meson-g12a-usb2-phy.yaml | 63 +++++++++++++++++++
.../bindings/phy/meson-g12a-usb2-phy.txt | 22 -------
2 files changed, 63 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml
delete mode 100644 Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml
new file mode 100644
index 000000000000..51254b4e65dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/amlogic,meson-g12a-usb2-phy.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic G12A USB2 PHY
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-g12a-usb2-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: xtal
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: phy
+
+ "#phy-cells":
+ const: 0
+
+ phy-supply:
+ maxItems: 1
+ description:
+ Phandle to a regulator that provides power to the PHY. This
+ regulator will be managed during the PHY power on/off sequence.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - "#phy-cells"
+
+examples:
+ - |
+ phy@36000 {
+ compatible = "amlogic,meson-g12a-usb2-phy";
+ reg = <0x36000 0x2000>;
+ clocks = <&xtal>;
+ clock-names = "xtal";
+ resets = <&phy_reset>;
+ reset-names = "phy";
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt b/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
deleted file mode 100644
index a6ebc3dea159..000000000000
--- a/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* Amlogic G12A USB2 PHY binding
-
-Required properties:
-- compatible: Should be "amlogic,meson-g12a-usb2-phy"
-- reg: The base address and length of the registers
-- #phys-cells: must be 0 (see phy-bindings.txt in this directory)
-- clocks: a phandle to the clock of this PHY
-- clock-names: must be "xtal"
-- resets: a phandle to the reset line of this PHY
-- reset-names: must be "phy"
-- phy-supply: see phy-bindings.txt in this directory
-
-Example:
- usb2_phy0: phy@36000 {
- compatible = "amlogic,g12a-usb2-phy";
- reg = <0x0 0x36000 0x0 0x2000>;
- clocks = <&xtal>;
- clock-names = "xtal";
- resets = <&reset RESET_USB_PHY21>;
- reset-names = "phy";
- #phy-cells = <0>;
- };
--
2.22.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
* [RFCv2 2/9] dt-bindings: rng: amlogic,meson-rng: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt
Cc: linux-amlogic, devicetree, linux-crypto, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic Random Number generator over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/rng/amlogic,meson-rng.txt | 21 -----------
.../bindings/rng/amlogic,meson-rng.yaml | 37 +++++++++++++++++++
2 files changed, 37 insertions(+), 21 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
create mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml
diff --git a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
deleted file mode 100644
index 4d403645ac9b..000000000000
--- a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Amlogic Meson Random number generator
-=====================================
-
-Required properties:
-
-- compatible : should be "amlogic,meson-rng"
-- reg : Specifies base physical address and size of the registers.
-
-Optional properties:
-
-- clocks : phandle to the following named clocks
-- clock-names: Name of core clock, must be "core"
-
-Example:
-
-rng {
- compatible = "amlogic,meson-rng";
- reg = <0x0 0xc8834000 0x0 0x4>;
- clocks = <&clkc CLKID_RNG0>;
- clock-names = "core";
-};
diff --git a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml
new file mode 100644
index 000000000000..a9ff3cb35c5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/rng/amlogic,meson-rng.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson Random number generator
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-rng
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: core
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ rng@c8834000 {
+ compatible = "amlogic,meson-rng";
+ reg = <0xc8834000 0x4>;
+ };
--
2.22.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
* [RFCv2 5/9] dt-bindings: arm: amlogic: amlogic, meson-gx-ao-secure: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt; +Cc: linux-amlogic, devicetree, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic Always-On Secure Registers over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../amlogic/amlogic,meson-gx-ao-secure.txt | 28 ----------
.../amlogic/amlogic,meson-gx-ao-secure.yaml | 52 +++++++++++++++++++
2 files changed, 52 insertions(+), 28 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
create mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
deleted file mode 100644
index c67d9f48fb91..000000000000
--- a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Amlogic Meson Firmware registers Interface
-------------------------------------------
-
-The Meson SoCs have a register bank with status and data shared with the
-secure firmware.
-
-Required properties:
- - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure", "syscon"
-
-Properties should indentify components of this register interface :
-
-Meson GX SoC Information
-------------------------
-A firmware register encodes the SoC type, package and revision information on
-the Meson GX SoCs.
-If present, the following property should be added :
-
-Optional properties:
- - amlogic,has-chip-id: If present, the interface gives the current SoC version.
-
-Example
--------
-
-ao-secure@140 {
- compatible = "amlogic,meson-gx-ao-secure", "syscon";
- reg = <0x0 0x140 0x0 0x140>;
- amlogic,has-chip-id;
-};
diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
new file mode 100644
index 000000000000..853d7d2b56f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-gx-ao-secure.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson Firmware registers Interface
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+description: |
+ The Meson SoCs have a register bank with status and data shared with the
+ secure firmware.
+
+# We need a select here so we don't match all nodes with 'syscon'
+select:
+ properties:
+ compatible:
+ contains:
+ const: amlogic,meson-gx-ao-secure
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - const: amlogic,meson-gx-ao-secure
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ amlogic,has-chip-id:
+ description: |
+ A firmware register encodes the SoC type, package and revision
+ information on the Meson GX SoCs. If present, the interface gives
+ the current SoC version.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ ao-secure@140 {
+ compatible = "amlogic,meson-gx-ao-secure", "syscon";
+ reg = <0x140 0x140>;
+ amlogic,has-chip-id;
+ };
--
2.22.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
* [RFCv2 1/9] dt-bindings: mailbox: meson-mhu: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt
Cc: linux-amlogic, devicetree, jassisinghbrar, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic MHU controller over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../mailbox/amlogic,meson-gxbb-mhu.yaml | 53 +++++++++++++++++++
.../devicetree/bindings/mailbox/meson-mhu.txt | 34 ------------
2 files changed, 53 insertions(+), 34 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml
delete mode 100644 Documentation/devicetree/bindings/mailbox/meson-mhu.txt
diff --git a/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml b/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml
new file mode 100644
index 000000000000..2536a0082cff
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/mailbox/amlogic,meson-gxbb-mhu.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson Message-Handling-Unit Controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+description: |
+ The Amlogic's Meson SoCs Message-Handling-Unit (MHU) is a mailbox controller
+ that has 3 independent channels/links to communicate with remote processor(s).
+ MHU links are hardwired on a platform. A link raises interrupt for any
+ received data. However, there is no specified way of knowing if the sent
+ data has been read by the remote. This driver assumes the sender polls
+ STAT register and the remote clears it after having read the data.
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-gxbb-mhu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 3
+ maxItems: 3
+ description:
+ Contains the interrupt information corresponding to each of the 3 links
+ of MHU.
+
+ "#mbox-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#mbox-cells"
+
+examples:
+ - |
+ mailbox@c883c404 {
+ compatible = "amlogic,meson-gxbb-mhu";
+ reg = <0xc883c404 0x4c>;
+ interrupts = <208>, <209>, <210>;
+ #mbox-cells = <1>;
+ };
+
diff --git a/Documentation/devicetree/bindings/mailbox/meson-mhu.txt b/Documentation/devicetree/bindings/mailbox/meson-mhu.txt
deleted file mode 100644
index a530310772b9..000000000000
--- a/Documentation/devicetree/bindings/mailbox/meson-mhu.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Amlogic Meson MHU Mailbox Driver
-================================
-
-The Amlogic's Meson SoCs Message-Handling-Unit (MHU) is a mailbox controller
-that has 3 independent channels/links to communicate with remote processor(s).
-MHU links are hardwired on a platform. A link raises interrupt for any
-received data. However, there is no specified way of knowing if the sent
-data has been read by the remote. This driver assumes the sender polls
-STAT register and the remote clears it after having read the data.
-
-Mailbox Device Node:
-====================
-
-Required properties:
---------------------
-- compatible: Shall be "amlogic,meson-gxbb-mhu"
-- reg: Contains the mailbox register address range (base
- address and length)
-- #mbox-cells Shall be 1 - the index of the channel needed.
-- interrupts: Contains the interrupt information corresponding to
- each of the 2 links of MHU.
-
-Example:
---------
-
- mailbox: mailbox@c883c404 {
- #mbox-cells = <1>;
- compatible = "amlogic,meson-gxbb-mhu";
- reg = <0 0xc883c404 0 0x4c>;
- interrupts = <0 208 IRQ_TYPE_EDGE_RISING>,
- <0 209 IRQ_TYPE_EDGE_RISING>,
- <0 210 IRQ_TYPE_EDGE_RISING>;
- #mbox-cells = <1>;
- };
--
2.22.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
* [RFCv2 0/9] dt-bindings: first tentative of conversion to yaml format
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt
Cc: p.zabel, devicetree, linux-watchdog, Neil Armstrong,
jassisinghbrar, linux-spi, linux-crypto, linux-serial,
linux-amlogic, kishon, linux-arm-kernel
This is a first tentative to convert some of the simplest Amlogic
dt-bindings to the yaml format.
All have been tested using :
$ make ARCH=arm64 dtbs_check
Issues with the amlogic arm64 DTs has already been identified thanks
to the validation scripts. The DT fixes will be pushed once these yaml
bindings are acked.
Changes since rfc v1:
- Fixed bindings according to Rob's comments
- Added commit log
- renamed yaml files using amlogic prefix
Neil Armstrong (9):
dt-bindings: mailbox: meson-mhu: convert to yaml
dt-bindings: rng: amlogic,meson-rng: convert to yaml
dt-bindings: spi: meson: convert to yaml
dt-bindings: reset: amlogic,meson-reset: convert to yaml
dt-bindings: arm: amlogic: amlogic,meson-gx-ao-secure: convert to yaml
dt-bindings: phy: meson-g12a-usb2-phy: convert to yaml
dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml
dt-bindings: serial: meson-uart: convert to yaml
dt-bindings: watchdog: meson-gxbb-wdt: convert to yaml
.../amlogic/amlogic,meson-gx-ao-secure.txt | 28 -------
.../amlogic/amlogic,meson-gx-ao-secure.yaml | 52 +++++++++++++
.../mailbox/amlogic,meson-gxbb-mhu.yaml | 53 ++++++++++++++
.../devicetree/bindings/mailbox/meson-mhu.txt | 34 ---------
.../phy/amlogic,meson-g12a-usb2-phy.yaml | 63 ++++++++++++++++
.../phy/amlogic,meson-g12a-usb3-pcie-phy.yaml | 57 +++++++++++++++
.../bindings/phy/meson-g12a-usb2-phy.txt | 22 ------
.../bindings/phy/meson-g12a-usb3-pcie-phy.txt | 22 ------
.../bindings/reset/amlogic,meson-reset.txt | 19 -----
.../bindings/reset/amlogic,meson-reset.yaml | 37 ++++++++++
.../bindings/rng/amlogic,meson-rng.txt | 21 ------
.../bindings/rng/amlogic,meson-rng.yaml | 37 ++++++++++
.../bindings/serial/amlogic,meson-uart.txt | 38 ----------
.../bindings/serial/amlogic,meson-uart.yaml | 73 +++++++++++++++++++
.../bindings/spi/amlogic,meson-gx-spicc.yaml | 67 +++++++++++++++++
.../bindings/spi/amlogic,meson6-spifc.yaml | 53 ++++++++++++++
.../devicetree/bindings/spi/spi-meson.txt | 55 --------------
.../watchdog/amlogic,meson-gxbb-wdt.yaml | 37 ++++++++++
.../bindings/watchdog/meson-gxbb-wdt.txt | 16 ----
19 files changed, 529 insertions(+), 255 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
create mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
create mode 100644 Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml
delete mode 100644 Documentation/devicetree/bindings/mailbox/meson-mhu.txt
create mode 100644 Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml
create mode 100644 Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml
delete mode 100644 Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
delete mode 100644 Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
delete mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
delete mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
create mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml
delete mode 100644 Documentation/devicetree/bindings/serial/amlogic,meson-uart.txt
create mode 100644 Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
create mode 100644 Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
create mode 100644 Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/spi-meson.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
delete mode 100644 Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
--
2.22.0
_______________________________________________
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] arm64/prefetch: fix a -Wtype-limits warning
From: Qian Cai @ 2019-08-05 12:03 UTC (permalink / raw)
To: Will Deacon
Cc: rrichter, Catalin Marinas, robin.murphy, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190805100059.4gml6c4kclz2iin3@willie-the-truck>
> On Aug 5, 2019, at 6:00 AM, Will Deacon <will@kernel.org> wrote:
>
> On Fri, Aug 02, 2019 at 08:33:58PM -0400, Qian Cai wrote:
>> The commit d5370f754875 ("arm64: prefetch: add alternative pattern for
>> CPUs without a prefetcher") introduced MIDR_IS_CPU_MODEL_RANGE() to be
>> used in has_no_hw_prefetch() with rv_min=0 which generates a compilation
>> warning from GCC,
>>
>> In file included from ./arch/arm64/include/asm/cache.h:8,
>> from ./include/linux/cache.h:6,
>> from ./include/linux/printk.h:9,
>> from ./include/linux/kernel.h:15,
>> from ./include/linux/cpumask.h:10,
>> from arch/arm64/kernel/cpufeature.c:11:
>> arch/arm64/kernel/cpufeature.c: In function 'has_no_hw_prefetch':
>> ./arch/arm64/include/asm/cputype.h:59:26: warning: comparison of
>> unsigned expression >= 0 is always true [-Wtype-limits]
>> _model == (model) && rv >= (rv_min) && rv <= (rv_max); \
>> ^~
>> arch/arm64/kernel/cpufeature.c:889:9: note: in expansion of macro
>> 'MIDR_IS_CPU_MODEL_RANGE'
>> return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX,
>> ^~~~~~~~~~~~~~~~~~~~~~~
>>
>> Fix it by making "rv" a "s32".
>>
>> Signed-off-by: Qian Cai <cai@lca.pw>
>> ---
>>
>> v2: Use "s32" for "rv", so "variant 0/revision 0" can be covered.
>>
>> arch/arm64/include/asm/cputype.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
>> index e7d46631cc42..d52fe8651c2d 100644
>> --- a/arch/arm64/include/asm/cputype.h
>> +++ b/arch/arm64/include/asm/cputype.h
>> @@ -54,7 +54,7 @@
>> #define MIDR_IS_CPU_MODEL_RANGE(midr, model, rv_min, rv_max) \
>> ({ \
>> u32 _model = (midr) & MIDR_CPU_MODEL_MASK; \
>> - u32 rv = (midr) & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK); \
>> + s32 rv = (midr) & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK); \
>
> Hmm, but this really isn't a signed quantity: it's two fields extracted
> from an ID register. I think the code is fine. Are you explicitly enabling
> -Wtype-limits somehow?
Yes, it is useful to catch unintended developer mistakes or simply optimize wasted instructions of
checking like in,
919aef44d73d (“x86/efi: fix a -Wtype-limits compilation warning”)
5a82bdb48f04 (“x86/cacheinfo: Fix a -Wtype-limits warning”)
It is normal to fix a false positive this way as in other mainline commits,
ec6335586953 (“x86/apic: Silence -Wtype-limits compiler warnings”)
Once those false-positives are under control, the warning flag could be then enabled by default in
the future.
_______________________________________________
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/2] arm64: Relax ICC_PMR_EL1 accesses when ICC_CTLR_EL1.PMHE is clear
From: Marc Zyngier @ 2019-08-05 12:03 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas
Cc: Suzuki K Poulose, liwei391, James Morse, Julien Thierry,
huawei.libin, guohanjun, Will Deacon, linux-arm-kernel
In-Reply-To: <20190802125208.73162-2-maz@kernel.org>
On 02/08/2019 13:52, Marc Zyngier wrote:
> From: Marc Zyngier <marc.zyngier@arm.com>
>
> The GICv3 architecture specification is incredibly misleading when it
> comes to PMR and the requirement for a DSB. It turns out that this DSB
> is only required if the CPU interface sends an Upstream Control
> message to the redistributor in order to update the RD's view of PMR.
>
> This message is only sent when ICC_CTLR_EL1.PMHE is set, which isn't
> the case in Linux. It can still be set from EL3, so some special care
> is required. But the upshot is that in the (hopefuly large) majority
> of the cases, we can drop the DSB altogether.
>
> This relies on a new static key being set if the boot CPU has PMHE
> set. The drawback is that this static key has to be exported to
> modules.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: James Morse <james.morse@arm.com>
> Cc: Julien Thierry <julien.thierry.kdev@gmail.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/include/asm/barrier.h | 12 ++++++++++++
> arch/arm64/include/asm/daifflags.h | 3 ++-
> arch/arm64/include/asm/irqflags.h | 19 ++++++++++---------
> arch/arm64/include/asm/kvm_host.h | 3 +--
> arch/arm64/kernel/entry.S | 6 ++++--
> arch/arm64/kvm/hyp/switch.c | 4 ++--
> drivers/irqchip/irq-gic-v3.c | 17 +++++++++++++++++
> include/linux/irqchip/arm-gic-v3.h | 2 ++
> 8 files changed, 50 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
> index e0e2b1946f42..7d9cc5ec4971 100644
> --- a/arch/arm64/include/asm/barrier.h
> +++ b/arch/arm64/include/asm/barrier.h
> @@ -29,6 +29,18 @@
> SB_BARRIER_INSN"nop\n", \
> ARM64_HAS_SB))
>
> +#ifdef CONFIG_ARM64_PSEUDO_NMI
> +#define pmr_sync() \
> + do { \
> + extern struct static_key_false gic_pmr_sync; \
> + \
> + if (static_branch_unlikely(&gic_pmr_sync)) \
> + dsb(sy); \
> + } while(0)
> +#else
> +#define pmr_sync() do {} while (0)
> +#endif
> +
> #define mb() dsb(sy)
> #define rmb() dsb(ld)
> #define wmb() dsb(st)
> diff --git a/arch/arm64/include/asm/daifflags.h b/arch/arm64/include/asm/daifflags.h
> index 987926ed535e..00b16793505a 100644
> --- a/arch/arm64/include/asm/daifflags.h
> +++ b/arch/arm64/include/asm/daifflags.h
> @@ -8,6 +8,7 @@
> #include <linux/irqflags.h>
>
> #include <asm/arch_gicv3.h>
> +#include <asm/barrier.h>
> #include <asm/cpufeature.h>
>
> #define DAIF_PROCCTX 0
> @@ -63,7 +64,7 @@ static inline void local_daif_restore(unsigned long flags)
>
> if (system_uses_irq_prio_masking()) {
> gic_write_pmr(GIC_PRIO_IRQON);
> - dsb(sy);
> + pmr_sync();
> }
> } else if (system_uses_irq_prio_masking()) {
> u64 pmr;
> diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
> index 7872f260c9ee..a5e7115d2f93 100644
> --- a/arch/arm64/include/asm/irqflags.h
> +++ b/arch/arm64/include/asm/irqflags.h
> @@ -8,6 +8,7 @@
> #ifdef __KERNEL__
>
> #include <asm/alternative.h>
> +#include <asm/barrier.h>
> #include <asm/ptrace.h>
> #include <asm/sysreg.h>
>
> @@ -36,14 +37,14 @@ static inline void arch_local_irq_enable(void)
> }
>
> asm volatile(ALTERNATIVE(
> - "msr daifclr, #2 // arch_local_irq_enable\n"
> - "nop",
> - __msr_s(SYS_ICC_PMR_EL1, "%0")
> - "dsb sy",
> + "msr daifclr, #2 // arch_local_irq_enable",
> + __msr_s(SYS_ICC_PMR_EL1, "%0"),
> ARM64_HAS_IRQ_PRIO_MASKING)
> :
> : "r" ((unsigned long) GIC_PRIO_IRQON)
> : "memory");
> +
> + pmr_sync();
> }
>
> static inline void arch_local_irq_disable(void)
> @@ -118,14 +119,14 @@ static inline unsigned long arch_local_irq_save(void)
> static inline void arch_local_irq_restore(unsigned long flags)
> {
> asm volatile(ALTERNATIVE(
> - "msr daif, %0\n"
> - "nop",
> - __msr_s(SYS_ICC_PMR_EL1, "%0")
> - "dsb sy",
> - ARM64_HAS_IRQ_PRIO_MASKING)
> + "msr daif, %0",
> + __msr_s(SYS_ICC_PMR_EL1, "%0"),
> + ARM64_HAS_IRQ_PRIO_MASKING)
> :
> : "r" (flags)
> : "memory");
> +
> + pmr_sync();
> }
>
> #endif
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index f656169db8c3..5ecb091c8576 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -600,8 +600,7 @@ static inline void kvm_arm_vhe_guest_enter(void)
> * local_daif_mask() already sets GIC_PRIO_PSR_I_SET, we just need a
> * dsb to ensure the redistributor is forwards EL2 IRQs to the CPU.
> */
> - if (system_uses_irq_prio_masking())
> - dsb(sy);
> + pmr_sync();
> }
>
> static inline void kvm_arm_vhe_guest_exit(void)
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 9cdc4592da3e..6803dd5b4256 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -269,8 +269,10 @@ alternative_else_nop_endif
> alternative_if ARM64_HAS_IRQ_PRIO_MASKING
> ldr x20, [sp, #S_PMR_SAVE]
> msr_s SYS_ICC_PMR_EL1, x20
> - /* Ensure priority change is seen by redistributor */
> - dsb sy
> + mrs_s x21, SYS_ICC_CTLR_EL1
> + tbz x21, #6, .L__skip_pmr_sync\@ // Check for ICC_CTLR_EL1.PMHE
> + dsb sy // Ensure priority change is seen by redistributor
> +.L__skip_pmr_sync\@:
> alternative_else_nop_endif
>
> ldp x21, x22, [sp, #S_PC] // load ELR, SPSR
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index adaf266d8de8..eb131e09d207 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -12,7 +12,7 @@
>
> #include <kvm/arm_psci.h>
>
> -#include <asm/arch_gicv3.h>
> +#include <asm/barrier.h>
> #include <asm/cpufeature.h>
> #include <asm/kprobes.h>
> #include <asm/kvm_asm.h>
> @@ -605,7 +605,7 @@ int __hyp_text __kvm_vcpu_run_nvhe(struct kvm_vcpu *vcpu)
> */
> if (system_uses_irq_prio_masking()) {
> gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
> - dsb(sy);
> + pmr_sync();
> }
>
> vcpu = kern_hyp_va(vcpu);
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 005b70e398b8..38fcb7eebdde 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -87,6 +87,15 @@ static DEFINE_STATIC_KEY_TRUE(supports_deactivate_key);
> */
> static DEFINE_STATIC_KEY_FALSE(supports_pseudo_nmis);
>
> +/*
> + * Global static key controlling whether an update to PMR allowing more
> + * interrupts requires to be propagated to the redistributor (DSB SY).
> + * And this needs to be exported for modules to be able to enable
> + * interrupts...
> + */
> +DEFINE_STATIC_KEY_FALSE(gic_pmr_sync);
> +EXPORT_SYMBOL(gic_pmr_sync);
> +
> /* ppi_nmi_refs[n] == number of cpus having ppi[n + 16] set as NMI */
> static refcount_t *ppi_nmi_refs;
>
> @@ -1494,6 +1503,14 @@ static void gic_enable_nmi_support(void)
> for (i = 0; i < gic_data.ppi_nr; i++)
> refcount_set(&ppi_nmi_refs[i], 0);
>
> + /*
> + * Linux itself doesn't use 1:N distribution, so has no need to
> + * set PMHE. The only reason to have it set is if EL3 requires it
> + * (and we can't change it).
> + */
> + if (read_sysreg_s(SYS_ICC_CTLR_EL1) & ICC_CTLR_EL1_PMHE_MASK)
This raw sysreg access breaks 32bit, and should be replaced with
gic_read_ctrl() instead. I'll post an updated version later in the week.
Thanks,
M.
--
Jazz is not dead, it just smells funny...
_______________________________________________
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 v1 01/16] drm/bridge: tc358767: fix opencoded use of drm_panel_*
From: Sam Ravnborg @ 2019-08-05 11:53 UTC (permalink / raw)
To: Philipp Zabel
Cc: Neil Armstrong, David Airlie, dri-devel, Thierry Reding,
Laurent Pinchart, Marek Vasut, linux-samsung-soc, Sean Paul,
Krzysztof Kozlowski, Jonathan Hunter, Maxime Ripard, Kukjin Kim,
NXP Linux Team, Jonas Karlman, Alison Wang, Gwan-gyeong Mun,
Alexios Zavras, Laurent Pinchart, linux-tegra, Thomas Gleixner,
Vincent Abriou, Allison Randal, linux-arm-kernel, Jernej Skrabec,
Enrico Weigelt, Seung-Woo Kim, Kyungmin Park,
Pengutronix Kernel Team, Shawn Guo
In-Reply-To: <1564997756.3056.13.camel@pengutronix.de>
Hi Philipp.
On Mon, Aug 05, 2019 at 11:35:56AM +0200, Philipp Zabel wrote:
> On Sun, 2019-08-04 at 22:16 +0200, Sam Ravnborg wrote:
> > Replace open coded version with call to drm_panel_get_modes().
> >
> > Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Andrzej Hajda <a.hajda@samsung.com>
> > Cc: Neil Armstrong <narmstrong@baylibre.com>
> > Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
> > Cc: Jonas Karlman <jonas@kwiboo.se>
> > Cc: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> > drivers/gpu/drm/bridge/tc358767.c | 10 ++++------
> > 1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c
> > index 42f03a985ac0..cebc8e620820 100644
> > --- a/drivers/gpu/drm/bridge/tc358767.c
> > +++ b/drivers/gpu/drm/bridge/tc358767.c
> > @@ -1312,7 +1312,7 @@ static int tc_connector_get_modes(struct drm_connector *connector)
> > {
> > struct tc_data *tc = connector_to_tc(connector);
> > struct edid *edid;
> > - unsigned int count;
> > + int count;
>
> This looks like it also fixes a potential bug ...
get_modes() return either 0 or number of modes.
The negative return values come into play in drm_panel_get_modes() when
panel for example s NULL.
I will add this to changelog before I apply to avoid any
misunderstanding.
Sam
_______________________________________________
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 v1 05/16] drm/fsl-dcu: fix opencoded use of drm_panel_*
From: Sam Ravnborg @ 2019-08-05 11:54 UTC (permalink / raw)
To: Stefan Agner
Cc: Neil Armstrong, David Airlie, dri-devel, Thierry Reding,
Laurent Pinchart, Marek Vasut, linux-samsung-soc, Sean Paul,
Allison Randal, Krzysztof Kozlowski, Jonathan Hunter,
Maxime Ripard, Kukjin Kim, NXP Linux Team, Sam Ravnborg,
Jonas Karlman, Alison Wang, Gwan-gyeong Mun, Alexios Zavras,
Laurent Pinchart, linux-tegra, Thomas Gleixner, Vincent Abriou,
linux-arm-kernel, Jernej Skrabec, Enrico Weigelt, Seung-Woo Kim,
Kyungmin Park, Pengutronix Kernel Team, Shawn Guo
In-Reply-To: <8567eb4c916a0b1d134bd62112a11903@agner.ch>
Hi Stefan.
Thanks for the feedback.
On Mon, Aug 05, 2019 at 11:16:26AM +0200, Stefan Agner wrote:
> On 2019-08-04 22:16, Sam Ravnborg wrote:
> > Use drm_panel_get_modes() to access modes.
> > This has a nice side effect to simplify the code.
> >
> > Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Stefan Agner <stefan@agner.ch>
> > Cc: Alison Wang <alison.wang@nxp.com>
> > ---
> > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 10 +---------
> > 1 file changed, 1 insertion(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> > index 279d83eaffc0..a92fd6c70b09 100644
> > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> > @@ -65,17 +65,9 @@ static const struct drm_connector_funcs
> > fsl_dcu_drm_connector_funcs = {
> > static int fsl_dcu_drm_connector_get_modes(struct drm_connector *connector)
> > {
> > struct fsl_dcu_drm_connector *fsl_connector;
> > - int (*get_modes)(struct drm_panel *panel);
> > - int num_modes = 0;
> >
> > fsl_connector = to_fsl_dcu_connector(connector);
> > - if (fsl_connector->panel && fsl_connector->panel->funcs &&
> > - fsl_connector->panel->funcs->get_modes) {
> > - get_modes = fsl_connector->panel->funcs->get_modes;
> > - num_modes = get_modes(fsl_connector->panel);
> > - }
> > -
> > - return num_modes;
> > + return drm_panel_get_modes(fsl_connector->panel);
>
> Oh, that old code looks rather messy. Thanks for the simplification!
>
> This behaves slightly different since it now returns -EINVAL or -ENOSYS,
> but that is what we want.
You are right, and I will add this to the changelog when I apply.
Sam
_______________________________________________
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