* Re: [PATCH v4 4/4] ARM: dts: aspeed: Add Mihawk BMC platform
From: Andrew Jeffery @ 2019-08-05 0:32 UTC (permalink / raw)
To: Ben Pai, Rob Herring, mark.rutland, Joel Stanley, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel
Cc: wangat
In-Reply-To: <20190802083736.26783-1-Ben_Pai@wistron.com>
On Fri, 2 Aug 2019, at 18:07, Ben Pai wrote:
> The Mihawk BMC is an ASPEED ast2500 based BMC that is part of an
> OpenPower Power9 server.
>
> Signed-off-by: Ben Pai <Ben_Pai@wistron.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC-ish PATCH 00/17] Clean up ASPEED devicetree warnings
From: Andrew Jeffery @ 2019-08-05 0:48 UTC (permalink / raw)
To: Joel Stanley
Cc: Mark Rutland, linux-aspeed, Linus Walleij, Corey Minyard,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, Xo Wang, Arnd Bergmann, Ken Chen, Adriana Kobylak,
open list:GPIO SUBSYSTEM, Rob Herring,
YangBrianC.W 楊嘉偉 TAO, openipmi-developer,
Alexander A. Filippov, Tao Ren, linux-kernel@vger.kernel.org,
yao.yuan, Patrick Venture, John Wang, Greg Kroah-Hartman,
Stefan M Schaeckeler, Haiyue Wang
In-Reply-To: <CACPK8Xc4Vigeu1B1Su5392BSCSKfoEDqt_tiDtgKmNH5ucAvAg@mail.gmail.com>
On Fri, 2 Aug 2019, at 15:21, Joel Stanley wrote:
> On Tue, 30 Jul 2019 at 01:09, Andrew Jeffery <andrew@aj.id.au> wrote:
>
> > > > The bang-for-buck is in fixing up the KCS bindings which removes all-but-two of
> > > > the remaining warnings (which we can't feasibly remove), but doing so forces
> > > > code changes (which I'd avoided up until this point).
> > > >
> > > > Reflecting broadly on the fixes, I think I've made a mistake way back by using
> > > > syscon/simple-mfds to expose the innards of the SCU and LPC controllers in the
> > > > devicetree. This series cleans up what's currently there, but I have half a
> > > > mind to rev the SCU and LPC bindings to not use simple-mfd and instead have a
> > > > driver implementation that uses `platform_device_register_full()` or similar to
> > > > deal with the mess.
> > > >
> > > > Rob - I'm looking for your thoughts here and on the series, I've never felt
> > > > entirely comfortable with what I cooked up. Your advice would be appreciated.
> > >
> > > The series generally looks fine to me from a quick scan. As far as
> > > dropping 'simple-mfd', having less fine grained description in DT is
> > > generally my preference. It comes down to whether what you have
> > > defined is maintainable. As most of it is just additions, I think what
> > > you have is fine. Maybe keep all this in mind for the next chip
> > > depending how the SCU and LPC change.
> >
> > Okay, I think the timing of that suggestion is good given where things are with
> > the AST2600. I'll keep that in mind.
> >
> > Consensus so far seems to be that the series is fine. I'll split it up and send out
> > the sub-series to the relevant lists with the acks accumulated here.
>
> The series look good. I suggest posting the KCS bindings and driver
> changes as their own series to go through the IPMI tree.
Yeah, that was the plan.
>
> Please add my tag to all the patches except the OCC one, which I need
> to do some investigation in to.
>
> Reviewed-by: Joel Stanley <joel@jms.id.au>
Thanks, will do.
>
> The others can go via the aspeed tree. Perhaps post them as their own
> series too so I don't get confused and apply the wrong ones. That way
> if Rob wants to send his reviewed-by he can.
SGTM.
Cheers,
Andrew
_______________________________________________
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 1/1] arm64: dts: rockchip: Add support for TB-96AI board
From: Elon Zhang @ 2019-08-05 1:57 UTC (permalink / raw)
To: heiko, mark.rutland, robh+dt
Cc: devicetree, linux-kernel, Elon Zhang, linux-rockchip,
manivannan.sadhasivam, linux-arm-kernel
Add devicetree support for RK3399Pro TB-96AI board, one of
the 96Boards family.
The TB-96AI board is a 96Boards Compute SOM design, launched
by Linaro, Rockchip and Beiqicloud.
More information can be obtained from the following websites:
1.https://www.96boards.org/product/tb-96ai/
2.http://t.rock-chips.com/
3.http://www.beiqicloud.com/
This patch add basic node for the board and support booting up
to Fedora.
Signed-off-by: Elon Zhang <zhangzj@rock-chips.com>
---
changes since v1:
- remove needless node
- using a standard LED formats for 96Boards
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399pro-tb-96ai.dts | 560 ++++++++++++++++++
2 files changed, 561 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 5f2687acbf94..3d6c8d4363b5 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -27,3 +27,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-tb-96ai.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts b/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
new file mode 100644
index 000000000000..767b37b854ba
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
@@ -0,0 +1,560 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+#include "rk3399pro.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+ compatible = "beiqi,rk3399pro-tb-96ai", "rockchip,rk3399pro";
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ xin32k: xin32k {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ clock-output-names = "xin32k";
+ #clock-cells = <0>;
+ };
+
+ vcc5v0_sys: vccsys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&work_led1>,<&work_led2>,<&work_led3>;
+
+ work_led1 {
+ gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
+ label = "system_work_led1";
+ retain-state-suspended;
+ };
+
+ work_led2 {
+ gpios = <&gpio2 4 GPIO_ACTIVE_HIGH>;
+ label = "system_work_led2";
+ retain-state-suspended;
+ };
+
+ work_led3 {
+ gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
+ label = "system_work_led3";
+ retain-state-suspended;
+ };
+ };
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&emmc_phy {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+ i2c-scl-rising-time-ns = <180>;
+ i2c-scl-falling-time-ns = <30>;
+ clock-frequency = <400000>;
+
+ rk809: pmic@20 {
+ compatible = "rockchip,rk809";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <RK_PC2 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default", "pmic-sleep",
+ "pmic-power-off", "pmic-reset";
+ pinctrl-0 = <&pmic_int_l>;
+ pinctrl-1 = <&soc_slppin_slp>, <&rk809_slppin_slp>;
+ pinctrl-2 = <&soc_slppin_gpio>, <&rk809_slppin_pwrdn>;
+ pinctrl-3 = <&soc_slppin_gpio>,<&rk809_slppin_null>;
+ rockchip,system-power-controller;
+ pmic-reset-func = <1>;
+ wakeup-source;
+ #clock-cells = <1>;
+ clock-output-names = "rk808-clkout1", "rk808-clkout2";
+
+ vcc1-supply = <&vcc5v0_sys>;
+ vcc2-supply = <&vcc5v0_sys>;
+ vcc3-supply = <&vcc5v0_sys>;
+ vcc4-supply = <&vcc5v0_sys>;
+ vcc5-supply = <&vcc_buck5>;
+ vcc6-supply = <&vcc_buck5>;
+ vcc7-supply = <&vcc3v3_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc5v0_sys>;
+
+ pwrkey {
+ status = "okay";
+ };
+
+ rtc {
+ status = "okay";
+ };
+
+ pinctrl_rk8xx: pinctrl_rk8xx {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ rk809_slppin_null: rk809_slppin_null {
+ pins = "gpio_slp";
+ function = "pin_fun0";
+ };
+
+ rk809_slppin_slp: rk809_slppin_slp {
+ pins = "gpio_slp";
+ function = "pin_fun1";
+ };
+
+ rk809_slppin_pwrdn: rk809_slppin_pwrdn {
+ pins = "gpio_slp";
+ function = "pin_fun2";
+ };
+
+ rk809_slppin_rst: rk809_slppin_rst {
+ pins = "gpio_slp";
+ function = "pin_fun3";
+ };
+ };
+
+ regulators {
+ vdd_center: DCDC_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-initial-mode = <0x2>;
+ regulator-name = "vdd_center";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <900000>;
+ };
+ };
+
+ vdd_cpu_l: DCDC_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-initial-mode = <0x2>;
+ regulator-name = "vdd_cpu_l";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vcc_ddr";
+ regulator-initial-mode = <0x2>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc3v3_sys: DCDC_REG4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <0x2>;
+ regulator-name = "vcc3v3_sys";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcc_buck5: DCDC_REG5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <2200000>;
+ regulator-max-microvolt = <2200000>;
+ regulator-name = "vcc_buck5";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <2200000>;
+ };
+ };
+
+ vcca_0v9: LDO_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ regulator-name = "vcca_0v9";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8: LDO_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-name = "vcc_1v8";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc0v9_soc: LDO_REG3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-name = "vcc0v9_soc";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <900000>;
+ };
+ };
+
+ vcca_1v8: LDO_REG4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-name = "vcca_1v8";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd1v5_dvp: LDO_REG5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+
+ regulator-name = "vdd1v5_dvp";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v5: LDO_REG6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+
+ regulator-name = "vcc_1v5";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v0: LDO_REG7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+
+ regulator-name = "vcc_3v0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd: LDO_REG8 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-name = "vccio_sd";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcc_sd: LDO_REG9 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-name = "vcc_sd";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcc5v0_usb: SWITCH_REG1 {
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+
+ regulator-name = "vcc5v0_usb";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_3v3: SWITCH_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-name = "vccio_3v3";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+
+ vdd_cpu_b: regulator@1c {
+ compatible = "fcs,fan53555";
+ reg = <0x1c>;
+ vin-supply = <&vcc5v0_sys>;
+ pinctrl-0 = <&vsel1_gpio>;
+ vsel-gpios = <&gpio1 RK_PC1 GPIO_ACTIVE_HIGH>;
+ regulator-name = "vdd_cpu_b";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <2300>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-state = <3>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: regulator@10 {
+ compatible = "fcs,fan53555";
+ status = "okay";
+ reg = <0x10>;
+ vin-supply = <&vcc5v0_sys>;
+ pinctrl-0 = <&vsel2_gpio>;
+ vsel-gpios = <&gpio1 RK_PB6 GPIO_ACTIVE_HIGH>;
+ regulator-name = "vdd_gpu";
+ regulator-min-microvolt = <735000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-ramp-delay = <2300>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+&i2c8 {
+ status = "okay";
+ i2c-scl-rising-time-ns = <345>;
+ i2c-scl-falling-time-ns = <11>;
+ clock-frequency = <100000>;
+};
+
+&io_domains {
+ status = "okay";
+ bt656-supply = <&vcca_1v8>; /* APIO2_VDD */
+ audio-supply = <&vcca_1v8>; /* APIO5_VDD */
+ sdmmc-supply = <&vccio_sd>; /* SDMMC0_VDD */
+ gpio1830-supply = <&vcc_1v8>; /* APIO4_VDD */
+};
+
+&pinctrl {
+ pinctrl-names = "default";
+ pinctrl-0 = <&npu_ref_clk>;
+
+ leds {
+ work_led1: work_led1 {
+ rockchip,pins =
+ <2 5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ work_led2: work_led2 {
+ rockchip,pins =
+ <2 4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ work_led3: work_led3 {
+ rockchip,pins =
+ <2 3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ npu_clk {
+ npu_ref_clk: npu-ref-clk {
+ rockchip,pins =
+ <0 RK_PA2 1 &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins =
+ <1 RK_PC2 0 &pcfg_pull_up>;
+ };
+
+ soc_slppin_gpio: soc-slppin-gpio {
+ rockchip,pins =
+ <1 RK_PA5 0 &pcfg_output_low>;
+ };
+
+ soc_slppin_slp: soc-slppin-slp {
+ rockchip,pins =
+ <1 RK_PA5 1 &pcfg_pull_down>;
+ };
+
+ vsel1_gpio: vsel1-gpio {
+ rockchip,pins =
+ <1 RK_PC1 0 &pcfg_pull_down>;
+ };
+
+ vsel2_gpio: vsel2-gpio {
+ rockchip,pins =
+ <1 RK_PB6 0 &pcfg_pull_down>;
+ };
+ };
+
+ usb3 {
+ usb3_host_en: usb3-host-en {
+ rockchip,pins =
+ <2 RK_PA2 RK_FUNC_GPIO &pcfg_output_high>;
+ };
+ };
+};
+
+&pmu_io_domains {
+ status = "okay";
+ pmu1830-supply = <&vcc_1v8>;
+};
+
+&pwm0 {
+ status = "okay";
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&saradc {
+ status = "okay";
+ vref-supply = <&vcc_1v8>;
+};
+
+&sdhci {
+ bus-width = <8>;
+ mmc-hs400-1_8v;
+ non-removable;
+ keep-power-in-suspend;
+ mmc-hs400-enhanced-strobe;
+ status = "okay";
+};
+
+&tcphy1 {
+ status = "okay";
+};
+
+&tsadc {
+ rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
+ rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
+ status = "okay";
+};
+
+&u2phy1 {
+ status = "okay";
+
+ u2phy1_otg: otg-port {
+ status = "okay";
+ };
+
+ u2phy1_host: host-port {
+ phy-supply = <&vcc5v0_usb>;
+ status = "okay";
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_cts>;
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart4 {
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&usbdrd3_1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb3_host_en>;
+};
+
+&usbdrd_dwc3_0 {
+ status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+ snps,dis-u3-autosuspend-quirk;
+ status = "okay";
+};
+
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 1/2] dt-bindings: mmc: Document Aspeed SD controller
From: Andrew Jeffery @ 2019-08-05 2:10 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Ulf Hansson, linux-aspeed, Ryan Chen,
linux-mmc, Adrian Hunter, linux-kernel@vger.kernel.org,
Joel Stanley,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_Jsq+oZRREV=VjYUxT3WphOa5tBaF1pvS_JKSphBY=3XB5MA@mail.gmail.com>
On Fri, 2 Aug 2019, at 08:29, Rob Herring wrote:
> On Tue, Jul 30, 2019 at 12:23 AM Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> > The ASPEED SD/SDIO/eMMC controller exposes two slots implementing the
> > SDIO Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit
> > data bus if only a single slot is enabled.
> >
> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> >
> > ---
> > v3:
> > * Fix compatible enums
> > * Add AST2600 compatibles
> > * Describe #address-cells / #size-cells
> > ---
> > .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 100 ++++++++++++++++++
> > 1 file changed, 100 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> > new file mode 100644
> > index 000000000000..dd2a00c59641
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> > @@ -0,0 +1,100 @@
> > +# SPDX-License-Identifier: GPL-2.0-or-later
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mmc/aspeed,sdhci.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: ASPEED SD/SDIO/eMMC Controller
> > +
> > +maintainers:
> > + - Andrew Jeffery <andrew@aj.id.au>
> > + - Ryan Chen <ryanchen.aspeed@gmail.com>
> > +
> > +description: |+
> > + The ASPEED SD/SDIO/eMMC controller exposes two slots implementing the SDIO
> > + Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit data bus if
> > + only a single slot is enabled.
> > +
> > + The two slots are supported by a common configuration area. As the SDHCIs for
> > + the slots are dependent on the common configuration area, they are described
> > + as child nodes.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - aspeed,ast2400-sd-controller
> > + - aspeed,ast2500-sd-controller
> > + - aspeed,ast2600-sd-controller
> > + reg:
> > + maxItems: 1
> > + description: Common configuration registers
> > + "#address-cells":
> > + const: 1
> > + "#size-cells":
> > + const: 1
> > + ranges: true
> > + clocks:
> > + maxItems: 1
> > + description: The SD/SDIO controller clock gate
> > +
> > +patternProperties:
> > + "^sdhci@[0-9a-f]+$":
>
> This should probably have:
>
> allOf:
> - $ref: mmc-controller.yaml
>
> Another new thing in 5.3. :)
Ack.
>
> > + type: object
> > + properties:
> > + compatible:
> > + enum:
> > + - aspeed,ast2400-sdhci
> > + - aspeed,ast2500-sdhci
> > + - aspeed,ast2600-sdhci
> > + reg:
> > + maxItems: 1
> > + description: The SDHCI registers
> > + clocks:
> > + maxItems: 1
> > + description: The SD bus clock
> > + interrupts:
> > + maxItems: 1
> > + description: The SD interrupt shared between both slots
> > + required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - interrupts
> > +
> > +additionalProperties: false
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - "#address-cells"
> > + - "#size-cells"
> > + - ranges
> > + - clocks
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/aspeed-clock.h>
> > + sdc@1e740000 {
> > + compatible = "aspeed,ast2500-sd-controller";
> > + reg = <0x1e740000 0x100>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x1e740000 0x10000>;
> > + clocks = <&syscon ASPEED_CLK_GATE_SDCLK>;
> > +
> > + sdhci0: sdhci@100 {
> > + compatible = "aspeed,ast2500-sdhci";
> > + reg = <0x100 0x100>;
> > + interrupts = <26>;
> > + sdhci,auto-cmd12;
>
> Not documented. Maybe should be common, but there's only a few users.
I'll document it locally for the moment.
Cheers,
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: kvm-unit-tests: psci_cpu_on_test FAILed
From: Zenghui Yu @ 2019-08-05 2:38 UTC (permalink / raw)
To: Marc Zyngier
Cc: drjones, kvm, suzuki.poulose, James Morse, linux-arm-kernel,
Wanghaibin (D), kvmarm, julien.thierry.kdev
In-Reply-To: <20190803111047.11493907@why>
Hi Marc,
On 2019/8/3 18:10, Marc Zyngier wrote:
> On Sat, 3 Aug 2019 17:27:41 +0800
> Zenghui Yu <yuzenghui@huawei.com> wrote:
>
>> Hi Marc,
>>
>> On 2019/8/2 23:56, Marc Zyngier wrote:
>>> On 02/08/2019 11:56, Zenghui Yu wrote:
>>>> Hi folks,
>>>>
>>>> Running kvm-unit-tests with Linux 5.3.0-rc2 on Kunpeng 920, we will get
>>>> the following fail info:
>>>>
>>>> [...]
>>>> FAIL psci (4 tests, 1 unexpected failures)
>>>> [...]
>>>> and
>>>> [...]
>>>> INFO: unexpected cpu_on return value: caller=CPU9, ret=-2
>>>> FAIL: cpu-on
>>>> SUMMARY: 4 tests, 1 unexpected failures
>>>>
>>>>
>>>> I think this is an issue had been fixed once by commit 6c7a5dce22b3
>>>> ("KVM: arm/arm64: fix races in kvm_psci_vcpu_on"), which makes use of
>>>> kvm->lock mutex to fix the race between two PSCI_CPU_ON calls - one
>>>> does reset on the MPIDR register whilst another reads it.
>>>>
>>>> But commit 358b28f09f0 ("arm/arm64: KVM: Allow a VCPU to fully reset
>>>> itself") later moves the reset work into check_vcpu_requests(), by
>>>> making a KVM_REQ_VCPU_RESET request in PSCI code. Thus the reset work
>>>> has not been protected by kvm->lock mutex anymore, and the race shows up
>>>> again...
>>>>
>>>> Do we need a fix for this issue? At least achieve a mutex execution
>>>> between the reset of MPIDR and kvm_mpidr_to_vcpu()?
>>>
>>> The thing is that the way we reset registers is marginally insane.
>>> Yes, it catches most reset bugs. It also introduces many more in
>>> the rest of the paths.
>>>
>>> The fun part is that there is hardly a need for resetting MPIDR.
>>> It has already been set when we've created the vcpu. It is the
>>
>> (That means we can let reset_mpidr() do nothing?)
>
> It should ever be only written once, as MPIDR is a constant from the
> guest perspective. So it is not that it can do nothing. It is just that
> there should never be any other value written to it.
Thanks for this explanation.
>>
>>> poisoning of the sysreg array that creates a situation where
>>> the MPIDR is temporarily invalid.
>>>
>>> So instead of poisoning the array, how about we just keep
>>> track of the registers for which we've called a reset function?
>>> It should be enough to track the most obvious bugs... I've
>>
>> The reset of DBG{BCR,BVR,WVR,WCR}n_EL1 registers will also be tracked.
>> It may affect our judgment?
>
> How so?
bmap[0..15] will be set multiple times. But it also will not affect
anything now (it's safe).
>>
>>> cobbled the following patch together, which seems to fix the
>>> issue on my TX2 with 64 vcpus.
>>>
>>> Thoughts?
>>>
>>> M.
>>>
>>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>>> index f26e181d881c..17f46ee7dc83 100644
>>> --- a/arch/arm64/kvm/sys_regs.c
>>> +++ b/arch/arm64/kvm/sys_regs.c
>>> @@ -2254,13 +2254,17 @@ 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) {
>>> table[i].reset(vcpu, &table[i]);
>>> + if (bmap)
>>> + set_bit(i, bmap);
>>
>> I think this should be:
>> set_bit(table[i].reg, bmap);
>>
>> Am I wrong?
>
> No, you're absolutely right.
>
>>
>>> + }
>>> }
>>> > /**
>>> @@ -2772,21 +2776,23 @@ void kvm_sys_reg_table_init(void)
>>> */
>>> void kvm_reset_sys_regs(struct kvm_vcpu *vcpu)
>>> {
>>> + unsigned long *bmap;
>>> 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));
>>> + bmap = bitmap_alloc(NR_SYS_REGS, GFP_KERNEL);
>>
>> LOCKDEP kernel will be not happy with this bitmap_alloc:
>>
>> " BUG: sleeping function called from invalid context at mm/slab.h:501
>> in_atomic(): 1, irqs_disabled(): 0, pid: 8710, name: qemu-system-aar "
>
> Well spotted. I guess GFP_ATOMIC is in order.
>
>>
>>> > /* 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(bmap && !test_bit(num, bmap),
>>> "Didn't reset __vcpu_sys_reg(%zi)\n", num))
>>> break;
>>> }
>>> +
>>> + kfree(bmap);
>>> }
>>>
>>>
>>
>> Some other minor questions about the sys reg resetting:
>> 1. Pointer Authentication Registers haven't have reset entry yet,
>> do they need? The same for ACTLR_EL1.
>
> Pointer auth registers definitely have a reset function, set to
> reset_unknown. So does ACTLR_EL1, which resets to the host's value.
I find them now :-)
>
>> 2. Why does PMCR_EL0 register have no "reg" field, in sys_reg_descs[]?
>
> This looks like a (very minor) bug. reset_pmcr writes directly to the
> PMCR_EL0 shadow register without using r->reg as the register number.
> But in the light of the reset tracking we want to add, this needs
> fixing.
>
>> I will test this patch with kvm-unit-tests next week!
>
> Well, wait until I repost something a bit less buggy...
Thanks,
zenghui
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 0/2] mmc: Add support for the ASPEED SD controller
From: Andrew Jeffery @ 2019-08-05 2:51 UTC (permalink / raw)
To: linux-mmc
Cc: mark.rutland, devicetree, ulf.hansson, linux-aspeed,
Andrew Jeffery, ryanchen.aspeed, adrian.hunter, linux-kernel,
robh+dt, joel, linux-arm-kernel
Hello,
v4 of the ASPEED SDHCI driver addresses Rob's comments on the binding, making
it utilise the new mmc-controller schema and describing the sdhci,auto-cmd12
property.
v3 can be found here:
http://patchwork.ozlabs.org/cover/1138793/
Please review!
Andrew
Andrew Jeffery (2):
dt-bindings: mmc: Document Aspeed SD controller
mmc: Add support for the ASPEED SD controller
.../devicetree/bindings/mmc/aspeed,sdhci.yaml | 105 ++++++
drivers/mmc/host/Kconfig | 12 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-of-aspeed.c | 328 ++++++++++++++++++
4 files changed, 446 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
create mode 100644 drivers/mmc/host/sdhci-of-aspeed.c
--
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
* [PATCH v4 1/2] dt-bindings: mmc: Document Aspeed SD controller
From: Andrew Jeffery @ 2019-08-05 2:51 UTC (permalink / raw)
To: linux-mmc
Cc: mark.rutland, devicetree, ulf.hansson, linux-aspeed,
Andrew Jeffery, ryanchen.aspeed, adrian.hunter, linux-kernel,
robh+dt, joel, linux-arm-kernel
In-Reply-To: <20190805025155.9020-1-andrew@aj.id.au>
The ASPEED SD/SDIO/MMC controller exposes two slots implementing the
SDIO Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit
data bus if only a single slot is enabled.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
v3:
* Make use of mmc-controller.yaml
* Document sdhci,auto-cmd12
v2:
* Fix compatible enums
* Add AST2600 compatibles
* Describe #address-cells / #size-cells
---
.../devicetree/bindings/mmc/aspeed,sdhci.yaml | 105 ++++++++++++++++++
1 file changed, 105 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
new file mode 100644
index 000000000000..ca8684f47962
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/aspeed,sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED SD/SDIO/eMMC Controller
+
+maintainers:
+ - Andrew Jeffery <andrew@aj.id.au>
+ - Ryan Chen <ryanchen.aspeed@gmail.com>
+
+description: |+
+ The ASPEED SD/SDIO/eMMC controller exposes two slots implementing the SDIO
+ Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit data bus if
+ only a single slot is enabled.
+
+ The two slots are supported by a common configuration area. As the SDHCIs for
+ the slots are dependent on the common configuration area, they are described
+ as child nodes.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2400-sd-controller
+ - aspeed,ast2500-sd-controller
+ - aspeed,ast2600-sd-controller
+ reg:
+ maxItems: 1
+ description: Common configuration registers
+ "#address-cells":
+ const: 1
+ "#size-cells":
+ const: 1
+ ranges: true
+ clocks:
+ maxItems: 1
+ description: The SD/SDIO controller clock gate
+
+patternProperties:
+ "^sdhci@[0-9a-f]+$":
+ type: object
+ allOf:
+ - $ref: mmc-controller.yaml
+ properties:
+ compatible:
+ enum:
+ - aspeed,ast2400-sdhci
+ - aspeed,ast2500-sdhci
+ - aspeed,ast2600-sdhci
+ reg:
+ maxItems: 1
+ description: The SDHCI registers
+ clocks:
+ maxItems: 1
+ description: The SD bus clock
+ interrupts:
+ maxItems: 1
+ description: The SD interrupt shared between both slots
+ sdhci,auto-cmd12:
+ type: boolean
+ description: Specifies that controller should use auto CMD12
+ required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+ - clocks
+
+examples:
+ - |
+ #include <dt-bindings/clock/aspeed-clock.h>
+ sdc@1e740000 {
+ compatible = "aspeed,ast2500-sd-controller";
+ reg = <0x1e740000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x1e740000 0x10000>;
+ clocks = <&syscon ASPEED_CLK_GATE_SDCLK>;
+
+ sdhci0: sdhci@100 {
+ compatible = "aspeed,ast2500-sdhci";
+ reg = <0x100 0x100>;
+ interrupts = <26>;
+ sdhci,auto-cmd12;
+ clocks = <&syscon ASPEED_CLK_SDIO>;
+ };
+
+ sdhci1: sdhci@200 {
+ compatible = "aspeed,ast2500-sdhci";
+ reg = <0x200 0x100>;
+ interrupts = <26>;
+ sdhci,auto-cmd12;
+ clocks = <&syscon ASPEED_CLK_SDIO>;
+ };
+ };
--
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 v4 2/2] mmc: Add support for the ASPEED SD controller
From: Andrew Jeffery @ 2019-08-05 2:51 UTC (permalink / raw)
To: linux-mmc
Cc: mark.rutland, devicetree, ulf.hansson, linux-aspeed,
Andrew Jeffery, ryanchen.aspeed, adrian.hunter, linux-kernel,
robh+dt, joel, linux-arm-kernel
In-Reply-To: <20190805025155.9020-1-andrew@aj.id.au>
Add a minimal driver for ASPEED's SD controller, which exposes two
SDHCIs.
The ASPEED design implements a common register set for the SDHCIs, and
moves some of the standard configuration elements out to this common
area (e.g. 8-bit mode, and card detect configuration which is not
currently supported).
The SD controller has a dedicated hardware interrupt that is shared
between the slots. The common register set exposes information on which
slot triggered the interrupt; early revisions of the patch introduced an
irqchip for the register, but reality is it doesn't behave as an
irqchip, and the result fits awkwardly into the irqchip APIs. Instead
I've taken the simple approach of using the IRQ as a shared IRQ with
some minor performance impact for the second slot.
Ryan was the original author of the patch - I've taken his work and
massaged it to drop the irqchip support and rework the devicetree
integration. The driver has been smoke tested under qemu against a
minimal SD controller model and lightly tested on an ast2500-evb.
Signed-off-by: Ryan Chen <ryanchen.aspeed@gmail.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
v3: No change
v2:
* Add AST2600 compatible
* Drop SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN
* Ensure slot number is valid
* Fix build with CONFIG_MODULES
* Fix module license string
* Non-PCI devices won't die
* Rename aspeed_sdc_configure_8bit_mode()
* Rename aspeed_sdhci_pdata
* Switch to sdhci_enable_clk()
* Use PTR_ERR() on the right `struct platform_device *`
---
drivers/mmc/host/Kconfig | 12 ++
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-of-aspeed.c | 328 +++++++++++++++++++++++++++++
3 files changed, 341 insertions(+)
create mode 100644 drivers/mmc/host/sdhci-of-aspeed.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 14d89a108edd..0f8a230de2f3 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -154,6 +154,18 @@ config MMC_SDHCI_OF_ARASAN
If unsure, say N.
+config MMC_SDHCI_OF_ASPEED
+ tristate "SDHCI OF support for the ASPEED SDHCI controller"
+ depends on MMC_SDHCI_PLTFM
+ depends on OF
+ help
+ This selects the ASPEED Secure Digital Host Controller Interface.
+
+ If you have a controller with this interface, say Y or M here. You
+ also need to enable an appropriate bus interface.
+
+ If unsure, say N.
+
config MMC_SDHCI_OF_AT91
tristate "SDHCI OF support for the Atmel SDMMC controller"
depends on MMC_SDHCI_PLTFM
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 73578718f119..390ee162fe71 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -84,6 +84,7 @@ obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX) += sdhci-esdhc-imx.o
obj-$(CONFIG_MMC_SDHCI_DOVE) += sdhci-dove.o
obj-$(CONFIG_MMC_SDHCI_TEGRA) += sdhci-tegra.o
obj-$(CONFIG_MMC_SDHCI_OF_ARASAN) += sdhci-of-arasan.o
+obj-$(CONFIG_MMC_SDHCI_OF_ASPEED) += sdhci-of-aspeed.o
obj-$(CONFIG_MMC_SDHCI_OF_AT91) += sdhci-of-at91.o
obj-$(CONFIG_MMC_SDHCI_OF_ESDHC) += sdhci-of-esdhc.o
obj-$(CONFIG_MMC_SDHCI_OF_HLWD) += sdhci-of-hlwd.o
diff --git a/drivers/mmc/host/sdhci-of-aspeed.c b/drivers/mmc/host/sdhci-of-aspeed.c
new file mode 100644
index 000000000000..d31785ec90d7
--- /dev/null
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -0,0 +1,328 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* Copyright (C) 2019 ASPEED Technology Inc. */
+/* Copyright (C) 2019 IBM Corp. */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/mmc/host.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+
+#include "sdhci-pltfm.h"
+
+#define ASPEED_SDC_INFO 0x00
+#define ASPEED_SDC_S1MMC8 BIT(25)
+#define ASPEED_SDC_S0MMC8 BIT(24)
+
+struct aspeed_sdc {
+ struct clk *clk;
+ struct resource *res;
+
+ spinlock_t lock;
+ void __iomem *regs;
+};
+
+struct aspeed_sdhci {
+ struct aspeed_sdc *parent;
+ u32 width_mask;
+};
+
+static void aspeed_sdc_configure_8bit_mode(struct aspeed_sdc *sdc,
+ struct aspeed_sdhci *sdhci,
+ bool bus8)
+{
+ u32 info;
+
+ /* Set/clear 8 bit mode */
+ spin_lock(&sdc->lock);
+ info = readl(sdc->regs + ASPEED_SDC_INFO);
+ if (bus8)
+ info |= sdhci->width_mask;
+ else
+ info &= ~sdhci->width_mask;
+ writel(info, sdc->regs + ASPEED_SDC_INFO);
+ spin_unlock(&sdc->lock);
+}
+
+static void aspeed_sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+ int div;
+ u16 clk;
+
+ if (clock == host->clock)
+ return;
+
+ sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
+
+ if (clock == 0)
+ goto out;
+
+ for (div = 1; div < 256; div *= 2) {
+ if ((host->max_clk / div) <= clock)
+ break;
+ }
+ div >>= 1;
+
+ clk = div << SDHCI_DIVIDER_SHIFT;
+
+ sdhci_enable_clk(host, clk);
+
+out:
+ host->clock = clock;
+}
+
+static void aspeed_sdhci_set_bus_width(struct sdhci_host *host, int width)
+{
+ struct sdhci_pltfm_host *pltfm_priv;
+ struct aspeed_sdhci *aspeed_sdhci;
+ struct aspeed_sdc *aspeed_sdc;
+ u8 ctrl;
+
+ pltfm_priv = sdhci_priv(host);
+ aspeed_sdhci = sdhci_pltfm_priv(pltfm_priv);
+ aspeed_sdc = aspeed_sdhci->parent;
+
+ /* Set/clear 8-bit mode */
+ aspeed_sdc_configure_8bit_mode(aspeed_sdc, aspeed_sdhci,
+ width == MMC_BUS_WIDTH_8);
+
+ /* Set/clear 1 or 4 bit mode */
+ ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
+ if (width == MMC_BUS_WIDTH_4)
+ ctrl |= SDHCI_CTRL_4BITBUS;
+ else
+ ctrl &= ~SDHCI_CTRL_4BITBUS;
+ sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
+}
+
+static const struct sdhci_ops aspeed_sdhci_ops = {
+ .set_clock = aspeed_sdhci_set_clock,
+ .get_max_clock = sdhci_pltfm_clk_get_max_clock,
+ .set_bus_width = aspeed_sdhci_set_bus_width,
+ .get_timeout_clock = sdhci_pltfm_clk_get_max_clock,
+ .reset = sdhci_reset,
+ .set_uhs_signaling = sdhci_set_uhs_signaling,
+};
+
+static const struct sdhci_pltfm_data aspeed_sdhci_pdata = {
+ .ops = &aspeed_sdhci_ops,
+ .quirks = SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
+};
+
+static inline int aspeed_sdhci_calculate_slot(struct aspeed_sdhci *dev,
+ struct resource *res)
+{
+ resource_size_t delta;
+
+ if (!res || resource_type(res) != IORESOURCE_MEM)
+ return -EINVAL;
+
+ if (res->start < dev->parent->res->start)
+ return -EINVAL;
+
+ delta = res->start - dev->parent->res->start;
+ if (delta & (0x100 - 1))
+ return -EINVAL;
+
+ return (delta / 0x100) - 1;
+}
+
+static int aspeed_sdhci_probe(struct platform_device *pdev)
+{
+ struct sdhci_pltfm_host *pltfm_host;
+ struct aspeed_sdhci *dev;
+ struct sdhci_host *host;
+ struct resource *res;
+ int slot;
+ int ret;
+
+ host = sdhci_pltfm_init(pdev, &aspeed_sdhci_pdata, sizeof(*dev));
+ if (IS_ERR(host))
+ return PTR_ERR(host);
+
+ pltfm_host = sdhci_priv(host);
+ dev = sdhci_pltfm_priv(pltfm_host);
+ dev->parent = dev_get_drvdata(pdev->dev.parent);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ slot = aspeed_sdhci_calculate_slot(dev, res);
+
+ if (slot < 0)
+ return slot;
+ else if (slot >= 2)
+ return -EINVAL;
+
+ dev_info(&pdev->dev, "Configuring for slot %d\n", slot);
+ dev->width_mask = !slot ? ASPEED_SDC_S0MMC8 : ASPEED_SDC_S1MMC8;
+
+ sdhci_get_of_property(pdev);
+
+ pltfm_host->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(pltfm_host->clk))
+ return PTR_ERR(pltfm_host->clk);
+
+ ret = clk_prepare_enable(pltfm_host->clk);
+ if (ret) {
+ dev_err(&pdev->dev, "Unable to enable SDIO clock\n");
+ goto err_pltfm_free;
+ }
+
+ ret = mmc_of_parse(host->mmc);
+ if (ret)
+ goto err_sdhci_add;
+
+ ret = sdhci_add_host(host);
+ if (ret)
+ goto err_sdhci_add;
+
+ return 0;
+
+err_sdhci_add:
+ clk_disable_unprepare(pltfm_host->clk);
+err_pltfm_free:
+ sdhci_pltfm_free(pdev);
+ return ret;
+}
+
+static int aspeed_sdhci_remove(struct platform_device *pdev)
+{
+ struct sdhci_pltfm_host *pltfm_host;
+ struct sdhci_host *host;
+ int dead = 0;
+
+ host = platform_get_drvdata(pdev);
+ pltfm_host = sdhci_priv(host);
+
+ sdhci_remove_host(host, dead);
+
+ clk_disable_unprepare(pltfm_host->clk);
+
+ sdhci_pltfm_free(pdev);
+
+ return 0;
+}
+
+static const struct of_device_id aspeed_sdhci_of_match[] = {
+ { .compatible = "aspeed,ast2400-sdhci", },
+ { .compatible = "aspeed,ast2500-sdhci", },
+ { .compatible = "aspeed,ast2600-sdhci", },
+ { }
+};
+
+static struct platform_driver aspeed_sdhci_driver = {
+ .driver = {
+ .name = "sdhci-aspeed",
+ .of_match_table = aspeed_sdhci_of_match,
+ },
+ .probe = aspeed_sdhci_probe,
+ .remove = aspeed_sdhci_remove,
+};
+
+static int aspeed_sdc_probe(struct platform_device *pdev)
+
+{
+ struct device_node *parent, *child;
+ struct aspeed_sdc *sdc;
+ int ret;
+
+ sdc = devm_kzalloc(&pdev->dev, sizeof(*sdc), GFP_KERNEL);
+ if (!sdc)
+ return -ENOMEM;
+
+ spin_lock_init(&sdc->lock);
+
+ sdc->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(sdc->clk))
+ return PTR_ERR(sdc->clk);
+
+ ret = clk_prepare_enable(sdc->clk);
+ if (ret) {
+ dev_err(&pdev->dev, "Unable to enable SDCLK\n");
+ return ret;
+ }
+
+ sdc->res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ sdc->regs = devm_ioremap_resource(&pdev->dev, sdc->res);
+ if (IS_ERR(sdc->regs)) {
+ ret = PTR_ERR(sdc->regs);
+ goto err_clk;
+ }
+
+ dev_set_drvdata(&pdev->dev, sdc);
+
+ parent = pdev->dev.of_node;
+ for_each_available_child_of_node(parent, child) {
+ struct platform_device *cpdev;
+
+ cpdev = of_platform_device_create(child, NULL, &pdev->dev);
+ if (IS_ERR(cpdev)) {
+ of_node_put(child);
+ ret = PTR_ERR(cpdev);
+ goto err_clk;
+ }
+ }
+
+ return 0;
+
+err_clk:
+ clk_disable_unprepare(sdc->clk);
+ return ret;
+}
+
+static int aspeed_sdc_remove(struct platform_device *pdev)
+{
+ struct aspeed_sdc *sdc = dev_get_drvdata(&pdev->dev);
+
+ clk_disable_unprepare(sdc->clk);
+
+ return 0;
+}
+
+static const struct of_device_id aspeed_sdc_of_match[] = {
+ { .compatible = "aspeed,ast2400-sd-controller", },
+ { .compatible = "aspeed,ast2500-sd-controller", },
+ { .compatible = "aspeed,ast2600-sd-controller", },
+ { }
+};
+
+MODULE_DEVICE_TABLE(of, aspeed_sdc_of_match);
+
+static struct platform_driver aspeed_sdc_driver = {
+ .driver = {
+ .name = "sd-controller-aspeed",
+ .pm = &sdhci_pltfm_pmops,
+ .of_match_table = aspeed_sdc_of_match,
+ },
+ .probe = aspeed_sdc_probe,
+ .remove = aspeed_sdc_remove,
+};
+
+static int __init aspeed_sdc_init(void)
+{
+ int rc;
+
+ rc = platform_driver_register(&aspeed_sdhci_driver);
+ if (rc < 0)
+ return rc;
+
+ return platform_driver_register(&aspeed_sdc_driver);
+}
+module_init(aspeed_sdc_init);
+
+static void __exit aspeed_sdc_exit(void)
+{
+ platform_driver_unregister(&aspeed_sdc_driver);
+ platform_driver_unregister(&aspeed_sdhci_driver);
+}
+module_exit(aspeed_sdc_exit);
+
+MODULE_DESCRIPTION("Driver for the ASPEED SD/SDIO/SDHCI Controllers");
+MODULE_AUTHOR("Ryan Chen <ryan_chen@aspeedtech.com>");
+MODULE_AUTHOR("Andrew Jeffery <andrew@aj.id.au>");
+MODULE_LICENSE("GPL");
--
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 v5 1/4] mailbox: imx: Fix Tx doorbell shutdown path
From: Richard Zhu @ 2019-08-05 2:51 UTC (permalink / raw)
To: jassisinghbrar, o.rempel, daniel.baluta, aisheng.dong
Cc: Richard Zhu, linux-imx, linux-arm-kernel, linux-kernel
In-Reply-To: <1564973491-18286-1-git-send-email-hongxing.zhu@nxp.com>
Tx doorbell is handled by txdb_tasklet and doesn't
have an associated IRQ.
Anyhow, imx_mu_shutdown ignores this and tries to
free an IRQ that wasn't requested for Tx DB resulting
in the following warning:
[ 1.967644] Trying to free already-free IRQ 26
[ 1.972108] WARNING: CPU: 2 PID: 157 at kernel/irq/manage.c:1708 __free_irq+0xc0/0x358
[ 1.980024] Modules linked in:
[ 1.983088] CPU: 2 PID: 157 Comm: kworker/2:1 Tainted: G
[ 1.993524] Hardware name: Freescale i.MX8QXP MEK (DT)
[ 1.998668] Workqueue: events deferred_probe_work_func
[ 2.003812] pstate: 60000085 (nZCv daIf -PAN -UAO)
[ 2.008607] pc : __free_irq+0xc0/0x358
[ 2.012364] lr : __free_irq+0xc0/0x358
[ 2.016111] sp : ffff00001179b7e0
[ 2.019422] x29: ffff00001179b7e0 x28: 0000000000000018
[ 2.024736] x27: ffff000011233000 x26: 0000000000000004
[ 2.030053] x25: 000000000000001a x24: ffff80083bec74d4
[ 2.035369] x23: 0000000000000000 x22: ffff80083bec7588
[ 2.040686] x21: ffff80083b1fe8d8 x20: ffff80083bec7400
[ 2.046003] x19: 0000000000000000 x18: ffffffffffffffff
[ 2.051320] x17: 0000000000000000 x16: 0000000000000000
[ 2.056637] x15: ffff0000111296c8 x14: ffff00009179b517
[ 2.061953] x13: ffff00001179b525 x12: ffff000011142000
[ 2.067270] x11: ffff000011129f20 x10: ffff0000105da970
[ 2.072587] x9 : 00000000ffffffd0 x8 : 0000000000000194
[ 2.077903] x7 : 612065657266206f x6 : ffff0000111e7b09
[ 2.083220] x5 : 0000000000000003 x4 : 0000000000000000
[ 2.088537] x3 : 0000000000000000 x2 : 00000000ffffffff
[ 2.093854] x1 : 28b70f0a2b60a500 x0 : 0000000000000000
[ 2.099173] Call trace:
[ 2.101618] __free_irq+0xc0/0x358
[ 2.105021] free_irq+0x38/0x98
[ 2.108170] imx_mu_shutdown+0x90/0xb0
[ 2.111921] mbox_free_channel.part.2+0x24/0xb8
[ 2.116453] mbox_free_channel+0x18/0x28
This bug is present from the beginning of times.
Cc: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
drivers/mailbox/imx-mailbox.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 25be8bb..1eeabc5 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -214,8 +214,10 @@ static void imx_mu_shutdown(struct mbox_chan *chan)
struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
struct imx_mu_con_priv *cp = chan->con_priv;
- if (cp->type == IMX_MU_TYPE_TXDB)
+ if (cp->type == IMX_MU_TYPE_TXDB) {
tasklet_kill(&cp->txdb_tasklet);
+ return;
+ }
imx_mu_xcr_rmw(priv, 0,
IMX_MU_xCR_TIEn(cp->idx) | IMX_MU_xCR_RIEn(cp->idx));
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 2/4] mailbox: imx: Clear the right interrupts at shutdown
From: Richard Zhu @ 2019-08-05 2:51 UTC (permalink / raw)
To: jassisinghbrar, o.rempel, daniel.baluta, aisheng.dong
Cc: Richard Zhu, linux-imx, linux-arm-kernel, linux-kernel
In-Reply-To: <1564973491-18286-1-git-send-email-hongxing.zhu@nxp.com>
Make sure to only clear enabled interrupts keeping count
of the connection type.
Suggested-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
drivers/mailbox/imx-mailbox.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 1eeabc5..afe625e 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -219,8 +219,19 @@ static void imx_mu_shutdown(struct mbox_chan *chan)
return;
}
- imx_mu_xcr_rmw(priv, 0,
- IMX_MU_xCR_TIEn(cp->idx) | IMX_MU_xCR_RIEn(cp->idx));
+ switch (cp->type) {
+ case IMX_MU_TYPE_TX:
+ imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_TIEn(cp->idx));
+ break;
+ case IMX_MU_TYPE_RX:
+ imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_RIEn(cp->idx));
+ break;
+ case IMX_MU_TYPE_RXDB:
+ imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_GIEn(cp->idx));
+ break;
+ default:
+ break;
+ }
free_irq(priv->irq, chan);
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 3/4] dt-bindings: mailbox: imx-mu: add imx7ulp MU support
From: Richard Zhu @ 2019-08-05 2:51 UTC (permalink / raw)
To: jassisinghbrar, o.rempel, daniel.baluta, aisheng.dong
Cc: Richard Zhu, linux-imx, linux-arm-kernel, linux-kernel
In-Reply-To: <1564973491-18286-1-git-send-email-hongxing.zhu@nxp.com>
There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu" compatible
to support it.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
index f3cf77e..9c43357 100644
--- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
+++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
@@ -21,6 +21,8 @@ Required properties:
imx6sx, imx7s, imx8qxp, imx8qm.
The "fsl,imx6sx-mu" compatible is seen as generic and should
be included together with SoC specific compatible.
+ There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu"
+ compatible to support it.
- reg : Should contain the registers location and length
- interrupts : Interrupt number. The interrupt specifier format depends
on the interrupt controller parent.
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 0/4] mailbox: imx: bug fix and add support for imx v1 mu
From: Richard Zhu @ 2019-08-05 2:51 UTC (permalink / raw)
To: jassisinghbrar, o.rempel, daniel.baluta, aisheng.dong
Cc: Richard Zhu, linux-imx, linux-arm-kernel, linux-kernel
Change logs:
v4 --> v5:
- Include Daniel's patch-set into this one.
v3 --> v4:
- Change "version1.0" to "version 1.0" in the commit log.
- Update the devicetree binding document to support the imx7ulp mu.
- Rebase the patch refer to the following bug-fixs patch-set issued
by Daniel Baluta <daniel.baluta@gmail.com>.
"https://patchwork.kernel.org/patch/11069479/"
v2 --> v3:
- Format the patch-set refer to Oleksij's guidance.
- Init the register array by a simple way recommended by Oleksij.
- Add Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de> tag.
v1 --> v2:
- Use to have the register layout linked on probe, suggested by
Oleksij Rempel <o.rempel@pengutronix.de>.
- Add Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> tag.
Richard Zhu (4):
mailbox: imx: Fix Tx doorbell shutdown path
mailbox: imx: Clear the right interrupts at shutdown
dt-bindings: mailbox: imx-mu: add imx7ulp MU support
mailbox: imx: add support for imx v1 mu
.../devicetree/bindings/mailbox/fsl,mu.txt | 2 +
drivers/mailbox/imx-mailbox.c | 74 ++++++++++++++++------
2 files changed, 56 insertions(+), 20 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 4/4] mailbox: imx: add support for imx v1 mu
From: Richard Zhu @ 2019-08-05 2:51 UTC (permalink / raw)
To: jassisinghbrar, o.rempel, daniel.baluta, aisheng.dong
Cc: Richard Zhu, linux-imx, linux-arm-kernel, linux-kernel
In-Reply-To: <1564973491-18286-1-git-send-email-hongxing.zhu@nxp.com>
There is a version 1.0 MU on i.MX7ULP platform.
One new version ID register is added, and it's offset is 0.
TRn registers are defined at the offset 0x20 ~ 0x2C.
RRn registers are defined at the offset 0x40 ~ 0x4C.
SR/CR registers are defined at 0x60/0x64.
Extend this driver to support it.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Suggested-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
drivers/mailbox/imx-mailbox.c | 55 ++++++++++++++++++++++++++++++-------------
1 file changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index afe625e..2cdcdc5 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -12,19 +12,11 @@
#include <linux/of_device.h>
#include <linux/slab.h>
-/* Transmit Register */
-#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
-/* Receive Register */
-#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
-/* Status Register */
-#define IMX_MU_xSR 0x20
#define IMX_MU_xSR_GIPn(x) BIT(28 + (3 - (x)))
#define IMX_MU_xSR_RFn(x) BIT(24 + (3 - (x)))
#define IMX_MU_xSR_TEn(x) BIT(20 + (3 - (x)))
#define IMX_MU_xSR_BRDIP BIT(9)
-/* Control Register */
-#define IMX_MU_xCR 0x24
/* General Purpose Interrupt Enable */
#define IMX_MU_xCR_GIEn(x) BIT(28 + (3 - (x)))
/* Receive Interrupt Enable */
@@ -44,6 +36,13 @@ enum imx_mu_chan_type {
IMX_MU_TYPE_RXDB, /* Rx doorbell */
};
+struct imx_mu_dcfg {
+ u32 xTR[4]; /* Transmit Registers */
+ u32 xRR[4]; /* Receive Registers */
+ u32 xSR; /* Status Register */
+ u32 xCR; /* Control Register */
+};
+
struct imx_mu_con_priv {
unsigned int idx;
char irq_desc[IMX_MU_CHAN_NAME_SIZE];
@@ -61,12 +60,27 @@ struct imx_mu_priv {
struct mbox_chan mbox_chans[IMX_MU_CHANS];
struct imx_mu_con_priv con_priv[IMX_MU_CHANS];
+ const struct imx_mu_dcfg *dcfg;
struct clk *clk;
int irq;
bool side_b;
};
+static const struct imx_mu_dcfg imx_mu_cfg_imx6sx = {
+ .xTR = {0x0, 0x4, 0x8, 0xc},
+ .xRR = {0x10, 0x14, 0x18, 0x1c},
+ .xSR = 0x20,
+ .xCR = 0x24,
+};
+
+static const struct imx_mu_dcfg imx_mu_cfg_imx7ulp = {
+ .xTR = {0x20, 0x24, 0x28, 0x2c},
+ .xRR = {0x40, 0x44, 0x48, 0x4c},
+ .xSR = 0x60,
+ .xCR = 0x64,
+};
+
static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
{
return container_of(mbox, struct imx_mu_priv, mbox);
@@ -88,10 +102,10 @@ static u32 imx_mu_xcr_rmw(struct imx_mu_priv *priv, u32 set, u32 clr)
u32 val;
spin_lock_irqsave(&priv->xcr_lock, flags);
- val = imx_mu_read(priv, IMX_MU_xCR);
+ val = imx_mu_read(priv, priv->dcfg->xCR);
val &= ~clr;
val |= set;
- imx_mu_write(priv, val, IMX_MU_xCR);
+ imx_mu_write(priv, val, priv->dcfg->xCR);
spin_unlock_irqrestore(&priv->xcr_lock, flags);
return val;
@@ -111,8 +125,8 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
struct imx_mu_con_priv *cp = chan->con_priv;
u32 val, ctrl, dat;
- ctrl = imx_mu_read(priv, IMX_MU_xCR);
- val = imx_mu_read(priv, IMX_MU_xSR);
+ ctrl = imx_mu_read(priv, priv->dcfg->xCR);
+ val = imx_mu_read(priv, priv->dcfg->xSR);
switch (cp->type) {
case IMX_MU_TYPE_TX:
@@ -138,10 +152,10 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_TIEn(cp->idx));
mbox_chan_txdone(chan, 0);
} else if (val == IMX_MU_xSR_RFn(cp->idx)) {
- dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
+ dat = imx_mu_read(priv, priv->dcfg->xRR[cp->idx]);
mbox_chan_received_data(chan, (void *)&dat);
} else if (val == IMX_MU_xSR_GIPn(cp->idx)) {
- imx_mu_write(priv, IMX_MU_xSR_GIPn(cp->idx), IMX_MU_xSR);
+ imx_mu_write(priv, IMX_MU_xSR_GIPn(cp->idx), priv->dcfg->xSR);
mbox_chan_received_data(chan, NULL);
} else {
dev_warn_ratelimited(priv->dev, "Not handled interrupt\n");
@@ -159,7 +173,7 @@ static int imx_mu_send_data(struct mbox_chan *chan, void *data)
switch (cp->type) {
case IMX_MU_TYPE_TX:
- imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
+ imx_mu_write(priv, *arg, priv->dcfg->xTR[cp->idx]);
imx_mu_xcr_rmw(priv, IMX_MU_xCR_TIEn(cp->idx), 0);
break;
case IMX_MU_TYPE_TXDB:
@@ -270,7 +284,7 @@ static void imx_mu_init_generic(struct imx_mu_priv *priv)
return;
/* Set default MU configuration */
- imx_mu_write(priv, 0, IMX_MU_xCR);
+ imx_mu_write(priv, 0, priv->dcfg->xCR);
}
static int imx_mu_probe(struct platform_device *pdev)
@@ -278,6 +292,7 @@ static int imx_mu_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
struct imx_mu_priv *priv;
+ const struct imx_mu_dcfg *dcfg;
unsigned int i;
int ret;
@@ -295,6 +310,11 @@ static int imx_mu_probe(struct platform_device *pdev)
if (priv->irq < 0)
return priv->irq;
+ dcfg = of_device_get_match_data(dev);
+ if (!dcfg)
+ return -EINVAL;
+ priv->dcfg = dcfg;
+
priv->clk = devm_clk_get(dev, NULL);
if (IS_ERR(priv->clk)) {
if (PTR_ERR(priv->clk) != -ENOENT)
@@ -348,7 +368,8 @@ static int imx_mu_remove(struct platform_device *pdev)
}
static const struct of_device_id imx_mu_dt_ids[] = {
- { .compatible = "fsl,imx6sx-mu" },
+ { .compatible = "fsl,imx7ulp-mu", .data = &imx_mu_cfg_imx7ulp },
+ { .compatible = "fsl,imx6sx-mu", .data = &imx_mu_cfg_imx6sx },
{ },
};
MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/9] KVM: arm64: Document PV-time interface
From: Zenghui Yu @ 2019-08-05 3:23 UTC (permalink / raw)
To: Steven Price
Cc: kvm, linux-doc, Catalin Marinas, Russell King, linux-kernel,
Marc Zyngier, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <20190802145017.42543-2-steven.price@arm.com>
Hi Steven,
On 2019/8/2 22:50, Steven Price wrote:
> Introduce a paravirtualization interface for KVM/arm64 based on the
> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
>
> This only adds the details about "Stolen Time" as the details of "Live
> Physical Time" have not been fully agreed.
>
> User space can specify a reserved area of memory for the guest and
> inform KVM to populate the memory with information on time that the host
> kernel has stolen from the guest.
>
> A hypercall interface is provided for the guest to interrogate the
> hypervisor's support for this interface and the location of the shared
> memory structures.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Documentation/virtual/kvm/arm/pvtime.txt | 107 +++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
> create mode 100644 Documentation/virtual/kvm/arm/pvtime.txt
^^^^^^^
This directory has been renamed recently, see:
https://patchwork.ozlabs.org/patch/1136104/
Zenghui
>
> diff --git a/Documentation/virtual/kvm/arm/pvtime.txt b/Documentation/virtual/kvm/arm/pvtime.txt
> new file mode 100644
> index 000000000000..e6ae9799e1d5
> --- /dev/null
> +++ b/Documentation/virtual/kvm/arm/pvtime.txt
> @@ -0,0 +1,107 @@
> +Paravirtualized time support for arm64
> +======================================
> +
> +Arm specification DEN0057/A defined a standard for paravirtualised time
> +support for Aarch64 guests:
> +
> +https://developer.arm.com/docs/den0057/a
> +
> +KVM/Arm64 implements the stolen time part of this specification by providing
> +some hypervisor service calls to support a paravirtualized guest obtaining a
> +view of the amount of time stolen from its execution.
> +
> +Two new SMCCC compatible hypercalls are defined:
> +
> +PV_FEATURES 0xC5000020
> +PV_TIME_ST 0xC5000022
> +
> +These are only available in the SMC64/HVC64 calling convention as
> +paravirtualized time is not available to 32 bit Arm guests.
> +
> +PV_FEATURES
> + Function ID: (uint32) : 0xC5000020
> + PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST
> + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
> + PV-time feature is supported by the hypervisor.
> +
> +PV_TIME_ST
> + Function ID: (uint32) : 0xC5000022
> + Return value: (int64) : IPA of the stolen time data structure for this
> + (V)CPU. On failure:
> + NOT_SUPPORTED (-1)
> +
> +Stolen Time
> +-----------
> +
> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
> +
> + Field | Byte Length | Byte Offset | Description
> + ----------- | ----------- | ----------- | --------------------------
> + Revision | 4 | 0 | Must be 0 for version 0.1
> + Attributes | 4 | 4 | Must be 0
> + Stolen time | 8 | 8 | Stolen time in unsigned
> + | | | nanoseconds indicating how
> + | | | much time this VCPU thread
> + | | | was involuntarily not
> + | | | running on a physical CPU.
> +
> +The structure will be updated by the hypervisor periodically as time is stolen
> +from the VCPU. It will be present within a reserved region of the normal
> +memory given to the guest. The guest should not attempt to write into this
> +memory. There is a structure by VCPU of the guest.
> +
> +User space interface
> +====================
> +
> +User space can request that KVM provide the paravirtualized time interface to
> +a guest by creating a KVM_DEV_TYPE_ARM_PV_TIME device, for example:
> +
> + struct kvm_create_device pvtime_device = {
> + .type = KVM_DEV_TYPE_ARM_PV_TIME,
> + .attr = 0,
> + .flags = 0,
> + };
> +
> + pvtime_fd = ioctl(vm_fd, KVM_CREATE_DEVICE, &pvtime_device);
> +
> +The guest IPA of the structures must be given to KVM. This is the base address
> +of an array of stolen time structures (one for each VCPU). For example:
> +
> + struct kvm_device_attr st_base = {
> + .group = KVM_DEV_ARM_PV_TIME_PADDR,
> + .attr = KVM_DEV_ARM_PV_TIME_ST,
> + .addr = (u64)(unsigned long)&st_paddr
> + };
> +
> + ioctl(pvtime_fd, KVM_SET_DEVICE_ATTR, &st_base);
> +
> +For migration (or save/restore) of a guest it is necessary to save the contents
> +of the shared page(s) and later restore them. KVM_DEV_ARM_PV_TIME_STATE_SIZE
> +provides the size of this data and KVM_DEV_ARM_PV_TIME_STATE allows the state
> +to be read/written.
> +
> +It is also necessary for the physical address to be set identically when
> +restoring.
> +
> + void *save_state(int fd, u64 attr, u32 *size) {
> + struct kvm_device_attr get_size = {
> + .group = KVM_DEV_ARM_PV_TIME_STATE_SIZE,
> + .attr = attr,
> + .addr = (u64)(unsigned long)size
> + };
> +
> + ioctl(fd, KVM_GET_DEVICE_ATTR, get_size);
> +
> + void *buffer = malloc(*size);
> +
> + struct kvm_device_attr get_state = {
> + .group = KVM_DEV_ARM_PV_TIME_STATE,
> + .attr = attr,
> + .addr = (u64)(unsigned long)size
> + };
> +
> + ioctl(fd, KVM_GET_DEVICE_ATTR, buffer);
> + }
> +
> + void *st_state = save_state(pvtime_fd, KVM_DEV_ARM_PV_TIME_ST, &st_size);
> +
>
_______________________________________________
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: dts: allwinner: a64: Enable eMMC on A64-OLinuXino
From: Chen-Yu Tsai @ 2019-08-05 3:33 UTC (permalink / raw)
To: Sunil Mohan Adapa; +Cc: Maxime Ripard, Martin Ayotte, linux-arm-kernel
In-Reply-To: <fd19b2e3-e340-f4fd-a320-1cfc45964f5b@medhas.org>
On Fri, Aug 2, 2019 at 2:47 AM Sunil Mohan Adapa <sunil@medhas.org> wrote:
>
> On 01/08/19 6:49 am, Martin Ayotte wrote:
> > If my SOB could help here, I don't mind since I've done the commit
> > more than a year ago for Armbian ...
> >
> > Signed-off-by: Martin Ayotte <martinayotte@gmai.com>
> > Tested-by: Martin Ayotte <martinayotte@gmai.com>
> gmai.com is likely a typo.
>
> > On Wed, Jul 31, 2019 at 10:42 PM Chen-Yu Tsai <wens@csie.org
> >
> >> Thanks. The patch looks good overall. The authorship is a little
> >> confusing though. If it was initially done by Martin (CC-ed), then
> >> he should be the author, and we should get his Signed-off-by if
> >> possible.
>
> Martin is indeed the original author of the patch. Thank you for reviewing.
I'd like to apply this patch with Martin as the author, if that's OK with you
both?
Thanks
ChenYu
> --
> Sunil
>
_______________________________________________
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 v3 02/11] dt-bindings: clock: imx-lpcg: add support to parse clocks from device tree
From: Dong Aisheng @ 2019-08-05 3:27 UTC (permalink / raw)
To: Shawn Guo
Cc: Dong Aisheng, devicetree, sboyd, Michael Turquette, Rob Herring,
dl-linux-imx, Sascha Hauer, Fabio Estevam, linux-clk,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190803135048.GL8870@X250.getinternet.no>
On Sun, Aug 4, 2019 at 11:45 AM Shawn Guo <shawnguo@kernel.org> wrote:
>
> On Tue, Jul 16, 2019 at 11:00:56PM +0800, Dong Aisheng wrote:
> > MX8QM and MX8QXP LPCG Clocks are mostly the same except they may reside
> > in different subsystems across CPUs and also vary a bit on the availability.
> >
> > Same as SCU clock, we want to move the clock definition into device tree
> > which can fully decouple the dependency of Clock ID definition from device
> > tree and make us be able to write a fully generic lpcg clock driver.
> >
> > And we can also use the existence of clock nodes in device tree to address
> > the device and clock availability differences across different SoCs.
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> > ---
> > ChangeLog:
> > v2->v3:
> > * no changes
> > v1->v2:
> > * Update example
> > * Add power domain property
> > ---
> > .../devicetree/bindings/clock/imx8qxp-lpcg.txt | 34 ++++++++++++++++++----
> > 1 file changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
> > index 965cfa4..6fc2fd8 100644
> > --- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
> > +++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
> > @@ -11,6 +11,21 @@ enabled by these control bits, it might still not be running based
> > on the base resource.
> >
> > Required properties:
> > +- compatible: Should be one of:
> > + "fsl,imx8qxp-lpcg"
> > + "fsl,imx8qm-lpcg" followed by "fsl,imx8qxp-lpcg".
> > +- reg: Address and length of the register set.
> > +- #clock-cells: Should be 1. One LPCG supports multiple clocks.
> > +- clocks: Input parent clocks phandle array for each clock.
> > +- bit-offset: An integer array indicating the bit offset for each clock.
>
> I guess that the driver should be able to figure bit offset from
> 'clock-indices' property.
>
Yes, it can be done in theory.
Then the binding may look like:
sdhc0_lpcg: clock-controller@5b200000 {
...
#clock-cells = <1>;
clocks = <&sdhc0_clk IMX_SC_PM_CLK_PER>,
<&conn_ipg_clk>, <&conn_axi_clk>;
clock-indices = <0>, <16>, <20>;
clock-output-names = "sdhc0_lpcg_per_clk",
"sdhc0_lpcg_ipg_clk",
"sdhc0_lpcg_ahb_clk";
power-domains = <&pd IMX_SC_R_SDHC_0>;
};
usdhc1: mmc@5b010000 {
...
clocks = <&sdhc0_lpcg 16>,
<&sdhc0_lpcg 0>,
<&sdhc0_lpcg 20>;
clock-names = "ipg", "per", "ahb";
};
However, after trying, i found one limitation if using clock-indices
that users have to do a secondary search for the indices value from clock names
which is not very friendly.
Formerly from the clock output names, user can easily get the clock
index as they're
in fixed orders as output names, so very easily to use.
e.g.
clocks = <&sdhc0_lpcg 1>,
<&sdhc0_lpcg 0>,
<&sdhc0_lpcg 2>;
If using clock-indices, users have no way to know it's clock index
from clock output names order
unless they do a secondary search from the clock-indice array accordingly.
For example, for "sdhc0_lpcg_ahb_clk", user can easily know its
reference is <&sdhc0_lpcg 2>.
But if using clock-indice, we need search clock-indices array to find
its reference
becomes <&sdhc0_lpcg 20>. So this seems like a drawback if using clock-indices.
Therefore, personally i'm still a bit intend to the original way which
is more simple and
straightforward from user point of view, unless there's a strong
objections on define another
vendor private property.
Shawn,
How do you think?
Should we enforce the complexity to users?
> > +- hw-autogate: Boolean array indicating whether supports HW autogate for
> > + each clock.
>
> Not sure why it needs to be a property in DT. Or asking it different
> way, when it should be true and when false?
>
It is one LPCG feature.
For some specific device LPCGs, it may support clock auto gating. (depends on
IP's capability. e.g. uSDHC).
So we define this feature in DT as well in case if user may want to
use it in the future.
But AFAIK, there's still no one using it. Most drivers reply on runtime PM to do
clock management. Did not use LPCG auto gate off feature.
But the current LPCG driver API does support this parameter.
If you think it's unnecessary to define it in DT as there're still no
users, i can remove it
and disabling autogate in driver by default.
Regards
Aisheng
> Shawn
>
> > +- clock-output-names: Shall be the corresponding names of the outputs.
> > + NOTE this property must be specified in the same order
> > + as the clock bit-offset and hw-autogate property.
> > +- power-domains: Should contain the power domain used by this clock.
> > +
> > +Legacy binding (DEPRECATED):
> > - compatible: Should be one of:
> > "fsl,imx8qxp-lpcg-adma",
> > "fsl,imx8qxp-lpcg-conn",
> > @@ -33,10 +48,17 @@ Examples:
> >
> > #include <dt-bindings/clock/imx8qxp-clock.h>
> >
> > -conn_lpcg: clock-controller@5b200000 {
> > - compatible = "fsl,imx8qxp-lpcg-conn";
> > - reg = <0x5b200000 0xb0000>;
> > +sdhc0_lpcg: clock-controller@5b200000 {
> > + compatible = "fsl,imx8qxp-lpcg";
> > + reg = <0x5b200000 0x10000>;
> > #clock-cells = <1>;
> > + clocks = <&sdhc0_clk IMX_SC_PM_CLK_PER>,
> > + <&conn_ipg_clk>, <&conn_axi_clk>;
> > + bit-offset = <0 16 20>;
> > + clock-output-names = "sdhc0_lpcg_per_clk",
> > + "sdhc0_lpcg_ipg_clk",
> > + "sdhc0_lpcg_ahb_clk";
> > + power-domains = <&pd IMX_SC_R_SDHC_0>;
> > };
> >
> > usdhc1: mmc@5b010000 {
> > @@ -44,8 +66,8 @@ usdhc1: mmc@5b010000 {
> > interrupt-parent = <&gic>;
> > interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>;
> > reg = <0x5b010000 0x10000>;
> > - clocks = <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_IPG_CLK>,
> > - <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_PER_CLK>,
> > - <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_HCLK>;
> > + clocks = <&sdhc0_lpcg 1>,
> > + <&sdhc0_lpcg 0>,
> > + <&sdhc0_lpcg 2>;
> > clock-names = "ipg", "per", "ahb";
> > };
> > --
> > 2.7.4
> >
_______________________________________________
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 v3 0/2] Add CCPI2 PMU support
From: Ganapatrao Kulkarni @ 2019-08-05 3:47 UTC (permalink / raw)
To: Ganapatrao Kulkarni, will@kernel.org
Cc: mark.rutland@arm.com, corbet@lwn.net, Jan Glauber,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Robert Richter, Jayachandran Chandrasekharan Nair,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAKTKpr5kmG3k4b85Zf05Q9xXpxMNZJyzWN7RXqZdteYUdMkc6g@mail.gmail.com>
On Mon, Jul 29, 2019 at 4:24 PM Ganapatrao Kulkarni <gklkml16@gmail.com> wrote:
>
> Hi Will,
>
> Any comments to this patchset?
If no further comments, can it be queued please?
>
> On Tue, Jul 23, 2019 at 2:46 PM Ganapatrao Kulkarni
> <gkulkarni@marvell.com> wrote:
> >
> > Add Cavium Coherent Processor Interconnect (CCPI2) PMU
> > support in ThunderX2 Uncore driver.
> >
> > v3: Rebased to 5.3-rc1
> >
> > v2: Updated with review comments [1]
> >
> > [1] https://lkml.org/lkml/2019/6/14/965
> >
> > v1: initial patch
> >
> > Ganapatrao Kulkarni (2):
> > Documentation: perf: Update documentation for ThunderX2 PMU uncore
> > driver
> > drivers/perf: Add CCPI2 PMU support in ThunderX2 UNCORE driver.
> >
> > .../admin-guide/perf/thunderx2-pmu.rst | 20 +-
> > drivers/perf/thunderx2_pmu.c | 248 +++++++++++++++---
> > 2 files changed, 225 insertions(+), 43 deletions(-)
> >
> > --
> > 2.17.1
> >
>
> Thanks,
> Ganapat
Thanks,
Ganapat
_______________________________________________
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 v3 01/11] dt-bindings: firmware: imx-scu: new binding to parse clocks from device tree
From: Dong Aisheng @ 2019-08-05 3:48 UTC (permalink / raw)
To: Shawn Guo
Cc: Dong Aisheng, devicetree, sboyd, Michael Turquette, Rob Herring,
dl-linux-imx, Sascha Hauer, Fabio Estevam, linux-clk,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190803144246.GM8870@X250.getinternet.no>
On Sun, Aug 4, 2019 at 11:49 AM Shawn Guo <shawnguo@kernel.org> wrote:
>
> On Tue, Jul 16, 2019 at 11:00:55PM +0800, Dong Aisheng wrote:
> > There's a few limitations on the original one cell clock binding
> > (#clock-cells = <1>) that we have to define some SW clock IDs for device
> > tree to reference. This may cause troubles if we want to use common
> > clock IDs for multi platforms support when the clock of those platforms
> > are mostly the same.
> > e.g. Current clock IDs name are defined with SS prefix.
> >
> > However the device may reside in different SS across CPUs, that means the
> > SS prefix may not valid anymore for a new SoC. Furthermore, the device
> > availability of those clocks may also vary a bit.
> >
> > For such situation, we want to eliminate the using of SW Clock IDs and
> > change to use a more close to HW one instead.
> > For SCU clocks usage, only two params required: Resource id + Clock Type.
>
> If this is how SCU firmware addresses the clock, I agree that it's worth
> witching to this new bindings, which describes the hardware (SCU
> firmware in this case) better, IMO.
>
> > Both parameters are platform independent. So we could use two cells binding
> > to pass those parameters,
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> > ---
> > ChangeLog:
> > v2->v3:
> > * Changed to two cells binding and register all clocks in driver
> > instead of parse from device tree.
> > v1->v2:
> > * changed to one cell binding inspired by arm,scpi.txt
> > Documentation/devicetree/bindings/arm/arm,scpi.txt
> > Resource ID is encoded in 'reg' property.
> > Clock type is encoded in generic clock-indices property.
> > Then we don't have to search all the DT nodes to fetch
> > those two value to construct clocks which is relatively
> > low efficiency.
> > * Add required power-domain property as well.
> > ---
> > .../devicetree/bindings/arm/freescale/fsl,scu.txt | 12 +++++++-----
> > include/dt-bindings/firmware/imx/rsrc.h | 17 +++++++++++++++++
> > 2 files changed, 24 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > index 5d7dbab..351d335 100644
> > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > @@ -89,7 +89,10 @@ Required properties:
> > "fsl,imx8qm-clock"
> > "fsl,imx8qxp-clock"
> > followed by "fsl,scu-clk"
> > -- #clock-cells: Should be 1. Contains the Clock ID value.
> > +- #clock-cells: Should be either
> > + 2: Contains the Resource and Clock ID value.
> > + or
> > + 1: Contains the Clock ID value. (DEPRECATED)
> > - clocks: List of clock specifiers, must contain an entry for
> > each required entry in clock-names
> > - clock-names: Should include entries "xtal_32KHz", "xtal_24MHz"
> > @@ -162,7 +165,7 @@ firmware {
> >
> > clk: clk {
> > compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
> > - #clock-cells = <1>;
> > + #clock-cells = <2>;
> > };
> >
> > iomuxc {
> > @@ -192,8 +195,7 @@ serial@5a060000 {
> > ...
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_lpuart0>;
> > - clocks = <&clk IMX8QXP_UART0_CLK>,
> > - <&clk IMX8QXP_UART0_IPG_CLK>;
> > - clock-names = "per", "ipg";
> > + clocks = <&uart0_clk IMX_SC_R_UART_0 IMX_SC_PM_CLK_PER>;
> > + clock-names = "ipg";
> > power-domains = <&pd IMX_SC_R_UART_0>;
> > };
> > diff --git a/include/dt-bindings/firmware/imx/rsrc.h b/include/dt-bindings/firmware/imx/rsrc.h
> > index 4e61f64..fbeaca7 100644
> > --- a/include/dt-bindings/firmware/imx/rsrc.h
> > +++ b/include/dt-bindings/firmware/imx/rsrc.h
> > @@ -547,4 +547,21 @@
> > #define IMX_SC_R_ATTESTATION 545
> > #define IMX_SC_R_LAST 546
> >
> > +/*
> > + * Defines for SC PM CLK
> > + */
> > +#define IMX_SC_PM_CLK_SLV_BUS 0 /* Slave bus clock */
> > +#define IMX_SC_PM_CLK_MST_BUS 1 /* Master bus clock */
> > +#define IMX_SC_PM_CLK_PER 2 /* Peripheral clock */
> > +#define IMX_SC_PM_CLK_PHY 3 /* Phy clock */
> > +#define IMX_SC_PM_CLK_MISC 4 /* Misc clock */
This is for typical device resource.
> > +#define IMX_SC_PM_CLK_MISC0 0 /* Misc 0 clock */
> > +#define IMX_SC_PM_CLK_MISC1 1 /* Misc 1 clock */
> > +#define IMX_SC_PM_CLK_MISC2 2 /* Misc 2 clock */
> > +#define IMX_SC_PM_CLK_MISC3 3 /* Misc 3 clock */
> > +#define IMX_SC_PM_CLK_MISC4 4 /* Misc 4 clock */
This is for some special clock types which do not belong to above
normal clock types.
Used very rare in SCU firmware.
e.g.
enet0_mac0_rxclk SC_R_ENE T_0 / SC_PM_CL K_MISC0
> > +#define IMX_SC_PM_CLK_CPU 2 /* CPU clock */
> > +#define IMX_SC_PM_CLK_PLL 4 /* PLL */
> > +#define IMX_SC_PM_CLK_BYPASS 4 /* Bypass clock */
They're for specific clock types for CPU/PLL/BYPASS only.
>
> It seems that there are several sets of clock type which apply to
> different resources/devices? If so, can you separate them a bit with
> some comments to make the list easier for readers?
>
Yes, i could add comments as above.
Thanks for the suggestions.
Aisheng
> Shawn
>
> > +
> > #endif /* __DT_BINDINGS_RSCRC_IMX_H */
> > --
> > 2.7.4
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv2 1/3] dt-bindings: pci: layerscape-pci: add compatible strings "fsl, ls1028a-pcie"
From: Xiaowei Bao @ 2019-08-05 4:04 UTC (permalink / raw)
To: bhelgaas, robh+dt, mark.rutland, shawnguo, leoyang.li, kishon,
lorenzo.pieralisi, arnd, gregkh, minghuan.Lian, mingkai.hu,
zhiqiang.hou, roy.zang, kstewart, pombredanne, shawn.lin,
linux-pci, devicetree, linux-kernel, linux-arm-kernel,
linuxppc-dev
Cc: Xiaowei Bao
Add the PCIe compatible string for LS1028A
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
---
v2:
- no change.
Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index e20ceaa..99a386e 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -21,6 +21,7 @@ Required properties:
"fsl,ls1046a-pcie"
"fsl,ls1043a-pcie"
"fsl,ls1012a-pcie"
+ "fsl,ls1028a-pcie"
EP mode:
"fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
- reg: base addresses and lengths of the PCIe controller register blocks.
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv2 3/3] PCI: layerscape: Add LS1028a support
From: Xiaowei Bao @ 2019-08-05 4:04 UTC (permalink / raw)
To: bhelgaas, robh+dt, mark.rutland, shawnguo, leoyang.li, kishon,
lorenzo.pieralisi, arnd, gregkh, minghuan.Lian, mingkai.hu,
zhiqiang.hou, roy.zang, kstewart, pombredanne, shawn.lin,
linux-pci, devicetree, linux-kernel, linux-arm-kernel,
linuxppc-dev
Cc: Xiaowei Bao
In-Reply-To: <20190805040453.48009-1-xiaowei.bao@nxp.com>
Add support for the LS1028a PCIe controller.
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
---
v2:
- no change.
drivers/pci/controller/dwc/pci-layerscape.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index 3a5fa26..8c556e1 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -236,6 +236,14 @@ static const struct ls_pcie_drvdata ls1043_drvdata = {
.dw_pcie_ops = &dw_ls_pcie_ops,
};
+static const struct ls_pcie_drvdata ls1028a_drvdata = {
+ .lut_offset = 0x80000,
+ .ltssm_shift = 0,
+ .lut_dbg = 0x407fc,
+ .ops = &ls_pcie_host_ops,
+ .dw_pcie_ops = &dw_ls_pcie_ops,
+};
+
static const struct ls_pcie_drvdata ls1046_drvdata = {
.lut_offset = 0x80000,
.ltssm_shift = 24,
@@ -263,6 +271,7 @@ static const struct ls_pcie_drvdata ls2088_drvdata = {
static const struct of_device_id ls_pcie_of_match[] = {
{ .compatible = "fsl,ls1012a-pcie", .data = &ls1046_drvdata },
{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
+ { .compatible = "fsl,ls1028a-pcie", .data = &ls1028a_drvdata },
{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
{ .compatible = "fsl,ls1046a-pcie", .data = &ls1046_drvdata },
{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv2 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
From: Xiaowei Bao @ 2019-08-05 4:04 UTC (permalink / raw)
To: bhelgaas, robh+dt, mark.rutland, shawnguo, leoyang.li, kishon,
lorenzo.pieralisi, arnd, gregkh, minghuan.Lian, mingkai.hu,
zhiqiang.hou, roy.zang, kstewart, pombredanne, shawn.lin,
linux-pci, devicetree, linux-kernel, linux-arm-kernel,
linuxppc-dev
Cc: Xiaowei Bao
In-Reply-To: <20190805040453.48009-1-xiaowei.bao@nxp.com>
LS1028a implements 2 PCIe 3.0 controllers.
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
---
v2:
- Fix up the legacy INTx allocate failed issue.
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 52 ++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index aef5b06..0b542ed 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -503,6 +503,58 @@
status = "disabled";
};
+ pcie@3400000 {
+ compatible = "fsl,ls1028a-pcie";
+ reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */
+ 0x80 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
+ <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>; /* aer interrupt */
+ interrupt-names = "pme", "aer";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ num-lanes = <4>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000 /* downstream I/O */
+ 0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ pcie@3500000 {
+ compatible = "fsl,ls1028a-pcie";
+ reg = <0x00 0x03500000 0x0 0x00100000 /* controller registers */
+ 0x88 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "pme", "aer";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ num-lanes = <4>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x81000000 0x0 0x00000000 0x88 0x00010000 0x0 0x00010000 /* downstream I/O */
+ 0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
pcie@1f0000000 { /* Integrated Endpoint Root Complex */
compatible = "pci-host-ecam-generic";
reg = <0x01 0xf0000000 0x0 0x100000>;
--
2.9.5
_______________________________________________
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 20/34] xen: convert put_page() to put_user_page*()
From: Juergen Gross @ 2019-08-05 4:15 UTC (permalink / raw)
To: john.hubbard, Andrew Morton
Cc: linux-fbdev, Jan Kara, kvm, Boris Ostrovsky, Dave Hansen,
Dave Chinner, dri-devel, linux-mm, sparclinux, Ira Weiny,
Dan Williams, devel, rds-devel, linux-rdma, x86, amd-gfx,
Christoph Hellwig, Jason Gunthorpe, xen-devel, devel, linux-media,
John Hubbard, intel-gfx, linux-block, Jérôme Glisse,
linux-rpi-kernel, ceph-devel, linux-arm-kernel, linux-nfs, netdev,
LKML, linux-xfs, linux-crypto, linux-fsdevel
In-Reply-To: <20190804224915.28669-21-jhubbard@nvidia.com>
On 05.08.19 00:49, john.hubbard@gmail.com wrote:
> From: John Hubbard <jhubbard@nvidia.com>
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> This also handles pages[i] == NULL cases, thanks to an approach
> that is actually written by Juergen Gross.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: xen-devel@lists.xenproject.org
> ---
>
> Hi Juergen,
>
> Say, this is *exactly* what you proposed in your gup.patch, so
> I've speculatively added your Signed-off-by above, but need your
> approval before that's final. Let me know please...
Yes, that's fine with me.
Juergen
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC] mm/pgtable/debug: Add test validating architecture page table helpers
From: Anshuman Khandual @ 2019-08-05 4:35 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Mark Rutland, Kees Cook, Sri Krishna chowdary, Ard Biesheuvel,
Masahiro Yamada, Tetsuo Handa, x86, Dave Hansen, linux-kernel,
Steven Price, linux-mm, Mark Brown, Andrew Morton, Michal Hocko,
linux-arm-kernel
In-Reply-To: <20190730170323.GA4700@bombadil.infradead.org>
On 07/30/2019 10:33 PM, Matthew Wilcox wrote:
> On Mon, Jul 29, 2019 at 02:02:52PM +0530, Anshuman Khandual wrote:
>> On 07/27/2019 01:24 AM, Matthew Wilcox wrote:
>>> On Fri, Jul 26, 2019 at 10:17:11AM +0530, Anshuman Khandual wrote:
>>>>> But 'page' isn't necessarily PMD-aligned. I don't think we can rely on
>>>>> architectures doing the right thing if asked to make a PMD for a randomly
>>>>> aligned page.
>>>>>
>>>>> How about finding the physical address of something like kernel_init(),
>>>>
>>>> Physical address corresponding to the symbol in the kernel text segment ?
>>>
>>> Yes. We need the address of something that's definitely memory.
>>> The stack might be in vmalloc space. We can't allocate memory from the
>>> allocator that's PUD-aligned. This seems like a reasonable approximation
>>> to something that might work.
>>
>> Okay sure. What is about vmalloc space being PUD aligned and how that is
>> problematic here ? Could you please give some details. Just being curious.
>
> Those were two different sentences.
>
> We can't use the address of something on the stack, because we don't
> know whether the stack is in vmalloc space or in the direct map.
Okay because kernel stack might be on vmalloc() space.
>
> We can't use the address of something we've allocated from the page
> allocator, because the page allocator can't give us PUD-aligned memory.
Because this test will be executed early during boot, alloc_contig_range()
makes sense for this purpose. Something like alloc_gigantic_page() which other
than getting the order from huge_page_order(h) is sort of a generic allocator.
Shall we make core part of the function a generic allocator for broader usage
in kernel in case the page allocator would not be sufficient like in this case
which requires a PUD size and a PUD aligned memory.
In case PUD aligned memory block cannot be allocated, pud_basic_tests() must
be skipped and a PMD aligned memory block should be used instead as fallback
for other tests.
>
>>> I think that's a mistake. As Russell said, the ARM p*d manipulation
>>> functions expect to operate on tables, not on individual entries
>>> constructed on the stack.
>>
>> Hmm. I assume that it will take care of dual 32 bit entry updates on arm
>> platform through various helper functions as Russel had mentioned earlier.
>> After we create page table with p?d_alloc() functions and pick an entry at
>> each page table level.
>
> Right.
>
>>> So I think the right thing to do here is allocate an mm, then do the
>>> pgd_alloc / p4d_alloc / pud_alloc / pmd_alloc / pte_alloc() steps giving
>>> you real page tables that you can manipulate.
>>>
>>> Then destroy them, of course. And don't access through them.
>>
>> mm_alloc() seems like a comprehensive helper to allocate and initialize a
>> mm_struct. But could we use mm_init() with 'current' in the driver context or we
>> need to create a dummy task_struct for this purpose. Some initial tests show that
>> p?d_alloc() and p?d_free() at each level with a fixed virtual address gives p?d_t
>> entries required at various page table level to test upon.
>
> I think it's wise to start a new mm. I'm not sure exactly what calls
> to make to get one going.>
>>>>>> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
>>>>>> +static void pud_basic_tests(void)
>>>>>
>>>>> Is this the right ifdef?
>>>>
>>>> IIUC THP at PUD is where the pud_t entries are directly operated upon and the
>>>> corresponding accessors are present only when HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
>>>> is enabled. Am I missing something here ?
>>>
>>> Maybe I am. I thought we could end up operating on PUDs for kernel mappings,
>>> even without transparent hugepages turned on.
>>
>> In generic MM ? IIUC except ioremap mapping all other PUD handling for kernel virtual
>> range is platform specific. All the helpers used in the function pud_basic_tests() are
>> part of THP and used in mm/huge_memory.c
>
> But what about hugetlbfs? And vmalloc can also use larger pages these days.
> I don't think these tests should be conditional on transparent hugepages.
The current proposal restricts itself to very basic operations at each page
table level for now. I have subsequent patches which adds various MM feature
related specific helpers with respect to SPECIAL, DEVMAP, HugeTLB entries
etc. We can also explore platform specific helpers for ioremap and vmalloc.
But that is for subsequent patches and scope for current proposal is limited.
THP (or PUD THP) config wrappers are here because these helpers mentioned in
the current proposal are present only when THP (or PUD THP) is enabled but
are absent otherwise. Without these wrappers, we will have build failures.
Hence these wrappers are necessary.
_______________________________________________
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 v5 1/4] mailbox: imx: Fix Tx doorbell shutdown path
From: Aisheng Dong @ 2019-08-05 4:38 UTC (permalink / raw)
To: Richard Zhu, jassisinghbrar@gmail.com, o.rempel@pengutronix.de,
Daniel Baluta
Cc: Richard Zhu, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1564973491-18286-2-git-send-email-hongxing.zhu@nxp.com>
> From: Richard Zhu <hongxing.zhu@nxp.com>
> Sent: Monday, August 5, 2019 10:51 AM
>
> Tx doorbell is handled by txdb_tasklet and doesn't have an associated IRQ.
>
> Anyhow, imx_mu_shutdown ignores this and tries to free an IRQ that wasn't
> requested for Tx DB resulting in the following warning:
>
> [ 1.967644] Trying to free already-free IRQ 26
> [ 1.972108] WARNING: CPU: 2 PID: 157 at kernel/irq/manage.c:1708
> __free_irq+0xc0/0x358
> [ 1.980024] Modules linked in:
> [ 1.983088] CPU: 2 PID: 157 Comm: kworker/2:1 Tainted: G
> [ 1.993524] Hardware name: Freescale i.MX8QXP MEK (DT)
> [ 1.998668] Workqueue: events deferred_probe_work_func
> [ 2.003812] pstate: 60000085 (nZCv daIf -PAN -UAO)
> [ 2.008607] pc : __free_irq+0xc0/0x358
> [ 2.012364] lr : __free_irq+0xc0/0x358
> [ 2.016111] sp : ffff00001179b7e0
> [ 2.019422] x29: ffff00001179b7e0 x28: 0000000000000018
> [ 2.024736] x27: ffff000011233000 x26: 0000000000000004
> [ 2.030053] x25: 000000000000001a x24: ffff80083bec74d4
> [ 2.035369] x23: 0000000000000000 x22: ffff80083bec7588
> [ 2.040686] x21: ffff80083b1fe8d8 x20: ffff80083bec7400
> [ 2.046003] x19: 0000000000000000 x18: ffffffffffffffff
> [ 2.051320] x17: 0000000000000000 x16: 0000000000000000
> [ 2.056637] x15: ffff0000111296c8 x14: ffff00009179b517
> [ 2.061953] x13: ffff00001179b525 x12: ffff000011142000
> [ 2.067270] x11: ffff000011129f20 x10: ffff0000105da970
> [ 2.072587] x9 : 00000000ffffffd0 x8 : 0000000000000194
> [ 2.077903] x7 : 612065657266206f x6 : ffff0000111e7b09
> [ 2.083220] x5 : 0000000000000003 x4 : 0000000000000000
> [ 2.088537] x3 : 0000000000000000 x2 : 00000000ffffffff
> [ 2.093854] x1 : 28b70f0a2b60a500 x0 : 0000000000000000
> [ 2.099173] Call trace:
> [ 2.101618] __free_irq+0xc0/0x358
> [ 2.105021] free_irq+0x38/0x98
> [ 2.108170] imx_mu_shutdown+0x90/0xb0
> [ 2.111921] mbox_free_channel.part.2+0x24/0xb8
> [ 2.116453] mbox_free_channel+0x18/0x28
>
> This bug is present from the beginning of times.
>
> Cc: Oleksij Rempel <o.rempel@pengutronix.de>
> Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
I think you should keep the original author and Fixes tag.
Otherwise:
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Aisheng
_______________________________________________
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 v5 2/4] mailbox: imx: Clear the right interrupts at shutdown
From: Aisheng Dong @ 2019-08-05 4:43 UTC (permalink / raw)
To: Richard Zhu, jassisinghbrar@gmail.com, o.rempel@pengutronix.de,
Daniel Baluta
Cc: Richard Zhu, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1564973491-18286-3-git-send-email-hongxing.zhu@nxp.com>
> From: Richard Zhu <hongxing.zhu@nxp.com>
> Sent: Monday, August 5, 2019 10:51 AM
>
> Make sure to only clear enabled interrupts keeping count of the connection
> type.
>
> Suggested-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Keep original author if any.
Otherwise:
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Aisheng
> ---
> drivers/mailbox/imx-mailbox.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
> index 1eeabc5..afe625e 100644
> --- a/drivers/mailbox/imx-mailbox.c
> +++ b/drivers/mailbox/imx-mailbox.c
> @@ -219,8 +219,19 @@ static void imx_mu_shutdown(struct mbox_chan
> *chan)
> return;
> }
>
> - imx_mu_xcr_rmw(priv, 0,
> - IMX_MU_xCR_TIEn(cp->idx) | IMX_MU_xCR_RIEn(cp->idx));
> + switch (cp->type) {
> + case IMX_MU_TYPE_TX:
> + imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_TIEn(cp->idx));
> + break;
> + case IMX_MU_TYPE_RX:
> + imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_RIEn(cp->idx));
> + break;
> + case IMX_MU_TYPE_RXDB:
> + imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_GIEn(cp->idx));
> + break;
> + default:
> + break;
> + }
>
> free_irq(priv->irq, chan);
> }
> --
> 2.7.4
_______________________________________________
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