* Re: [PATCH] ARM: dts: imx6ull: add MYiR MYS-6ULX SBC
From: Parthiban @ 2020-06-01 14:55 UTC (permalink / raw)
To: Marco Felsch
Cc: robh+dt, shawnguo, s.hauer, kernel, festevam, linux-imx,
devicetree, linux-kernel, linux-arm-kernel, Parthiban
In-Reply-To: <20200427061844.i5hb2xatq2ntdqbe@pengutronix.de>
On 4/27/20 8:18 AM, Marco Felsch wrote:
> Hi Parthiban,
>
> a few more minor comments..
>
> On 20-04-08 20:43, Parthiban Nallathambi wrote:
>
> ...
>
>> diff --git a/arch/arm/boot/dts/imx6ull-myir-mys-6ulx.dtsi b/arch/arm/boot/dts/imx6ull-myir-mys-6ulx.dtsi
>> new file mode 100644
>> index 000000000000..f0a514187c21
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/imx6ull-myir-mys-6ulx.dtsi
>> @@ -0,0 +1,247 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2020 Linumiz
>> + * Author: Parthiban Nallathambi <parthiban@linumiz.com>
>> + */
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/pwm/pwm.h>
>> +
>> +/ {
>> + model = "MYiR MYS-6ULX Single Board Computer";
>> + compatible = "myir,imx6ull-mys-6ulx", "fsl,imx6ull";
>> +
>> + chosen {
>> + stdout-path = &uart1;
>> + };
>> +
>> + regulators: regulators {
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + vdd_5v: regulator@0 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "VDD_5V";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + regulator-always-on;
>> + regulator-boot-on;
>> + };
>> +
>> + vdd_3v3: regulator@1 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "VDD_3V3";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-always-on;
>> + vin-supply = <&vdd_5v>;
>> + };
>> + };
>> +};
>> +
>> +&fec1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_enet1>;
>> + phy-mode = "rmii";
>> + phy-handle = <ðphy0>;
>> + phy-supply = <&vdd_3v3>;
>> + status = "okay";
>> +
>> + mdio: mdio {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + ethphy0: ethernet-phy@0 {
>> + reg = <0>;
>> + compatible = "ethernet-phy-ieee802.3-c22";
>> + interrupt-parent = <&gpio5>;
>> + interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
>> + clocks = <&clks IMX6UL_CLK_ENET_REF>;
>> + clock-names = "rmii-ref";
>> + status = "okay";
>
> Status not needed here.
Thanks, removed it.
>
>> + };
>> + };
>> +};
>> +
>> +&gpmi {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_gpmi_nand>;
>> + nand-on-flash-bbt;
>> + status = "disabled";
>> +};
>> +
>> +&uart1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_uart1>;
>> + status = "okay";
>> +};
>> +
>> +&usbotg1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_usb_otg1_id>;
>> + dr_mode = "otg";
>> + status = "okay";
>> +};
>> +
>> +&usbotg2 {
>> + dr_mode = "host";
>> + disable-over-current;
>> + status = "okay";
>> +};
>> +
>> +&usdhc1 {
>> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
>> + pinctrl-0 = <&pinctrl_usdhc1>;
>> + pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
>> + pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
>> + cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
>> + no-1-8-v;
>> + keep-power-in-suspend;
>> + wakeup-source;
>> + vmmc-supply = <&vdd_3v3>;
>> + status = "okay";
>> +};
>> +
>> +&usdhc2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_usdhc2>;
>> + pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
>> + pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
>> + bus-width = <8>;
>> + non-removable;
>> + keep-power-in-suspend;
>> + vmmc-supply = <&vdd_3v3>;
>> + status = "disabled";
>
> Status not needed here.
Removed, thanks.
>
> Regards,
> Marco
>
>> +};
>> +
>> +&iomuxc {
>> + pinctrl_enet1: enet1grp {
>> + fsl,pins = <
>> + MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0
>> + MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
>> + MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0
>> + MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0
>> + MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
>> + MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
>> + MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
>> + MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
>> + MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
>> + MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031
>> + MX6UL_PAD_SNVS_TAMPER5__GPIO5_IO05 0x1b0b0
>> + >;
>> + };
>> +
>> + pinctrl_gpmi_nand: gpminandgrp {
>> + fsl,pins = <
>> + MX6UL_PAD_NAND_CLE__RAWNAND_CLE 0x0b0b1
>> + MX6UL_PAD_NAND_ALE__RAWNAND_ALE 0x0b0b1
>> + MX6UL_PAD_NAND_WP_B__RAWNAND_WP_B 0x0b0b1
>> + MX6UL_PAD_NAND_READY_B__RAWNAND_READY_B 0x0b000
>> + MX6UL_PAD_NAND_CE0_B__RAWNAND_CE0_B 0x0b0b1
>> + MX6UL_PAD_NAND_RE_B__RAWNAND_RE_B 0x0b0b1
>> + MX6UL_PAD_NAND_WE_B__RAWNAND_WE_B 0x0b0b1
>> + MX6UL_PAD_NAND_DATA00__RAWNAND_DATA00 0x0b0b1
>> + MX6UL_PAD_NAND_DATA01__RAWNAND_DATA01 0x0b0b1
>> + MX6UL_PAD_NAND_DATA02__RAWNAND_DATA02 0x0b0b1
>> + MX6UL_PAD_NAND_DATA03__RAWNAND_DATA03 0x0b0b1
>> + MX6UL_PAD_NAND_DATA04__RAWNAND_DATA04 0x0b0b1
>> + MX6UL_PAD_NAND_DATA05__RAWNAND_DATA05 0x0b0b1
>> + MX6UL_PAD_NAND_DATA06__RAWNAND_DATA06 0x0b0b1
>> + MX6UL_PAD_NAND_DATA07__RAWNAND_DATA07 0x0b0b1
>> + >;
>> + };
>> +
>> + pinctrl_uart1: uart1grp {
>> + fsl,pins = <
>> + MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
>> + MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
>> + >;
>> + };
>> +
>> + pinctrl_usb_otg1_id: usbotg1idgrp {
>> + fsl,pins = <
>> + MX6UL_PAD_GPIO1_IO00__ANATOP_OTG1_ID 0x17059
>> + >;
>> + };
>> +
>> + pinctrl_usdhc1: usdhc1grp {
>> + fsl,pins = <
>> + MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
>> + MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10059
>> + MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
>> + MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
>> + MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
>> + MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
>> + MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x17059
>> + >;
>> + };
>> +
>> + pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
>> + fsl,pins = <
>> + MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x170b9
>> + MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x100b9
>> + MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170b9
>> + MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170b9
>> + MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170b9
>> + MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170b9
>> + >;
>> + };
>> +
>> + pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
>> + fsl,pins = <
>> + MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x170f9
>> + MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x100f9
>> + MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170f9
>> + MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170f9
>> + MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170f9
>> + MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170f9
>> + >;
>> + };
>> +
>> + pinctrl_usdhc2: usdhc2grp {
>> + fsl,pins = <
>> + MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x10069
>> + MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x17059
>> + MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x17059
>> + MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x17059
>> + MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x17059
>> + MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x17059
>> + MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x17059
>> + MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x17059
>> + MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x17059
>> + MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x17059
>> + >;
>> + };
>> +
>> + pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
>> + fsl,pins = <
>> + MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x100b9
>> + MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x170b9
>> + MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x170b9
>> + MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x170b9
>> + MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x170b9
>> + MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x170b9
>> + MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x170b9
>> + MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x170b9
>> + MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x170b9
>> + MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x170b9
>> + >;
>> + };
>> +
>> + pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
>> + fsl,pins = <
>> + MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x100f9
>> + MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x170f9
>> + MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x170f9
>> + MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x170f9
>> + MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x170f9
>> + MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x170f9
>> + MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x170f9
>> + MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x170f9
>> + MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x170f9
>> + MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x170f9
>> + >;
>> + };
>> +};
>> --
>> 2.11.0
>>
--
Thanks,
Parthiban N
+4915163761545
^ permalink raw reply
* Re: [PATCH v2 6/6] MAINTAINERS: Add maintainers for MIPS core drivers
From: Serge Semin @ 2020-06-01 15:19 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Thomas Bogendoerfer, Thomas Gleixner,
Greg Kroah-Hartman, Alexey Malahov, Paul Burton, Rob Herring,
Arnd Bergmann, Jason Cooper, Marc Zyngier, Rafael J. Wysocki,
Daniel Lezcano, James Hogan, linux-mips, devicetree,
Linux Kernel Mailing List
In-Reply-To: <CAHp75Vec8DA+dVDGif7UhBtxDPFZG0nnCav=qLJON=j8=9QxSA@mail.gmail.com>
On Mon, Jun 01, 2020 at 04:56:21PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 1, 2020 at 3:26 PM Serge Semin
> <Sergey.Semin@baikalelectronics.ru> wrote:
> >
> > Add myself as a maintainer of MIPS CPU and GIC IRQchip, MIPS GIC timer
> > and MIPS CPS CPUidle drivers.
> ...
> > +MIPS CORE DRIVERS
> > +M: Serge Semin <fancer.lancer@gmail.com>
> > +L: linux-mips@vger.kernel.org
> > +S: Supported
> > +F: drivers/bus/mips_cdmm.c
> > +F: drivers/irqchip/irq-mips-cpu.c
> > +F: drivers/irqchip/irq-mips-gic.c
> > +F: drivers/clocksource/mips-gic-timer.c
> > +F: drivers/cpuidle/cpuidle-cps.c
>
> I think nowadays checkpatch.pl warns on wrong ordering in this data base.
Alas it doesn't. Good point though.
-Sergey
>
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: arm: fsl: Add MYiR Tech boards
From: Parthiban Nallathambi @ 2020-06-01 14:58 UTC (permalink / raw)
To: m.felsch, shawnguo, robh+dt, s.hauer
Cc: kernel, festevam, linux-imx, devicetree, linux-kernel,
linux-arm-kernel, Parthiban Nallathambi
Add entries for MYiR Tech imx6ULL eval boards.
Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index cd3fbe7e3948..592d73187da4 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -264,6 +264,8 @@ properties:
- armadeus,imx6ull-opos6uldev # OPOS6UL (i.MX6ULL) SoM on OPOS6ULDev board
- fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK Board
- kontron,imx6ull-n6411-som # Kontron N6411 SOM
+ - myir,imx6ull-mys-6ulx # MYiR Tech iMX6ULL Evaluation Board
+ - myir,imx6ull-mys-6ulx-nand # MYiR Tech iMX6ULL Evaluation Board with NAND
- toradex,colibri-imx6ull-eval # Colibri iMX6ULL Module on Colibri Evaluation Board
- toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / Bluetooth Module on Colibri Evaluation Board
- const: fsl,imx6ull
--
2.26.2
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: imx6ull: add MYiR MYS-6ULX SBC
From: Parthiban Nallathambi @ 2020-06-01 14:58 UTC (permalink / raw)
To: m.felsch, shawnguo, robh+dt, s.hauer
Cc: kernel, festevam, linux-imx, devicetree, linux-kernel,
linux-arm-kernel, Parthiban Nallathambi
In-Reply-To: <20200601145857.5658-1-parthiban@linumiz.com>
Add support for the MYiR imx6ULL based single board computer
equipped with on board 256MB NAND & RAM. The board also
provides expansion header for expansion board, but this
commit adds only support for SBC.
Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>
---
Notes:
Changelog v2:
- moved regulator under root node
- status property removed
arch/arm/boot/dts/Makefile | 1 +
.../boot/dts/imx6ull-myir-mys-6ulx-nand.dts | 19 ++
arch/arm/boot/dts/imx6ull-myir-mys-6ulx.dtsi | 238 ++++++++++++++++++
3 files changed, 258 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ull-myir-mys-6ulx-nand.dts
create mode 100644 arch/arm/boot/dts/imx6ull-myir-mys-6ulx.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e8dd99201397..eab86051d782 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -612,6 +612,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ull-14x14-evk.dtb \
imx6ull-colibri-eval-v3.dtb \
imx6ull-colibri-wifi-eval-v3.dtb \
+ imx6ull-myir-mys-6ulx-nand.dtb \
imx6ull-opos6uldev.dtb \
imx6ull-phytec-segin-ff-rdk-nand.dtb \
imx6ull-phytec-segin-ff-rdk-emmc.dtb \
diff --git a/arch/arm/boot/dts/imx6ull-myir-mys-6ulx-nand.dts b/arch/arm/boot/dts/imx6ull-myir-mys-6ulx-nand.dts
new file mode 100644
index 000000000000..43e072671ca4
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-myir-mys-6ulx-nand.dts
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Linumiz
+ * Author: Parthiban Nallathambi <parthiban@linumiz.com>
+ */
+
+/dts-v1/;
+#include "imx6ull.dtsi"
+#include "imx6ull-myir-mys-6ulx.dtsi"
+
+/ {
+ model = "MYiR i.MX6ULL MYS-6ULX Single Board Computer with NAND";
+ compatible = "myir,imx6ull-mys-6ulx-nand", "myir,imx6ull-mys-6ulx",
+ "fsl,imx6ull";
+};
+
+&gpmi {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6ull-myir-mys-6ulx.dtsi b/arch/arm/boot/dts/imx6ull-myir-mys-6ulx.dtsi
new file mode 100644
index 000000000000..03365a1ca8e6
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-myir-mys-6ulx.dtsi
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Linumiz
+ * Author: Parthiban Nallathambi <parthiban@linumiz.com>
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pwm/pwm.h>
+
+/ {
+ model = "MYiR MYS-6ULX Single Board Computer";
+ compatible = "myir,imx6ull-mys-6ulx", "fsl,imx6ull";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ reg_vdd_5v: regulator-vdd-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ reg_vdd_3v3: regulator-vdd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <®_vdd_5v>;
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy0>;
+ phy-supply = <®_vdd_3v3>;
+ status = "okay";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ reg = <0>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&clks IMX6UL_CLK_ENET_REF>;
+ clock-names = "rmii-ref";
+ };
+ };
+};
+
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ nand-on-flash-bbt;
+ status = "disabled";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&usbotg1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_otg1_id>;
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbotg2 {
+ dr_mode = "host";
+ disable-over-current;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ keep-power-in-suspend;
+ wakeup-source;
+ vmmc-supply = <®_vdd_3v3>;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ keep-power-in-suspend;
+ vmmc-supply = <®_vdd_3v3>;
+};
+
+&iomuxc {
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0
+ MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+ MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031
+ MX6UL_PAD_SNVS_TAMPER5__GPIO5_IO05 0x1b0b0
+ >;
+ };
+
+ pinctrl_gpmi_nand: gpminandgrp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_CLE__RAWNAND_CLE 0x0b0b1
+ MX6UL_PAD_NAND_ALE__RAWNAND_ALE 0x0b0b1
+ MX6UL_PAD_NAND_WP_B__RAWNAND_WP_B 0x0b0b1
+ MX6UL_PAD_NAND_READY_B__RAWNAND_READY_B 0x0b000
+ MX6UL_PAD_NAND_CE0_B__RAWNAND_CE0_B 0x0b0b1
+ MX6UL_PAD_NAND_RE_B__RAWNAND_RE_B 0x0b0b1
+ MX6UL_PAD_NAND_WE_B__RAWNAND_WE_B 0x0b0b1
+ MX6UL_PAD_NAND_DATA00__RAWNAND_DATA00 0x0b0b1
+ MX6UL_PAD_NAND_DATA01__RAWNAND_DATA01 0x0b0b1
+ MX6UL_PAD_NAND_DATA02__RAWNAND_DATA02 0x0b0b1
+ MX6UL_PAD_NAND_DATA03__RAWNAND_DATA03 0x0b0b1
+ MX6UL_PAD_NAND_DATA04__RAWNAND_DATA04 0x0b0b1
+ MX6UL_PAD_NAND_DATA05__RAWNAND_DATA05 0x0b0b1
+ MX6UL_PAD_NAND_DATA06__RAWNAND_DATA06 0x0b0b1
+ MX6UL_PAD_NAND_DATA07__RAWNAND_DATA07 0x0b0b1
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_usb_otg1_id: usbotg1idgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO00__ANATOP_OTG1_ID 0x17059
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10059
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+ MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x17059
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x170b9
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x100b9
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170b9
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170b9
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170b9
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170b9
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x170f9
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x100f9
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170f9
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170f9
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170f9
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170f9
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x10069
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x17059
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x17059
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x17059
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x17059
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x17059
+ MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x17059
+ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x17059
+ MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x17059
+ MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x17059
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x100b9
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x170b9
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x170b9
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x170b9
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x170b9
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x170b9
+ MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x170b9
+ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x170b9
+ MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x170b9
+ MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x170b9
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x100f9
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x170f9
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x170f9
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x170f9
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x170f9
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x170f9
+ MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x170f9
+ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x170f9
+ MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x170f9
+ MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x170f9
+ >;
+ };
+};
--
2.26.2
^ permalink raw reply related
* Re: [PATCH RESEND v2 0/6] mips: Add DT bindings for MIPS CDMM and MIPS GIC
From: Serge Semin @ 2020-06-01 15:24 UTC (permalink / raw)
To: Marc Zyngier
Cc: Serge Semin, Thomas Bogendoerfer, Thomas Gleixner,
Greg Kroah-Hartman, Alexey Malahov, Paul Burton, Rob Herring,
Arnd Bergmann, Jason Cooper, Rafael J. Wysocki, Daniel Lezcano,
James Hogan, linux-mips, devicetree, linux-kernel
In-Reply-To: <d59ef33155e2ae965e79522ab220c177@kernel.org>
Hello Marc,
On Mon, Jun 01, 2020 at 01:31:27PM +0100, Marc Zyngier wrote:
> On 2020-06-01 13:21, Serge Semin wrote:
>
> [...]
>
> > Since Paul isn't looking after the MIPS arch code anymore, Ralf hasn't
> > been seen maintaining MIPS for a long time, Thomas is only responsible
> > for the next part of it:
> > F: Documentation/devicetree/bindings/mips/
> > F: Documentation/mips/
> > F: arch/mips/
> > F: drivers/platform/mips/
> > the MIPS-specific drivers like:
> > F: drivers/bus/mips_cdmm.c
> > F: drivers/irqchip/irq-mips-cpu.c
> > F: drivers/irqchip/irq-mips-gic.c
> > F: drivers/clocksource/mips-gic-timer.c
> > F: drivers/cpuidle/cpuidle-cps.c
> > seem to be left for the subsystems maintainers to support. So if you
> > don't
> > mind or unless there is a better alternative, I can help with looking
> > after them to ease the maintainers review burden and since I'll be
> > working
> > on our MIPS-based SoC drivers integrating into the mainline kernel repo
> > anyway. If you don't like this idea, please just decline the last
> > patch in the series.
>
> Given how deeply integrated the MIPS GIC is in the architecture, I'd
> really like Thomas to co-maintain it, or at the very least give his
> blessing on you being the dedicated point of contact for MIPS GIC
> stuff.
I don't mind either way. First option might be even better. Thomas, what do you
think?
-Sergey
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v2 6/6] MAINTAINERS: Add maintainers for MIPS core drivers
From: Andy Shevchenko @ 2020-06-01 15:30 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, Thomas Bogendoerfer, Thomas Gleixner,
Greg Kroah-Hartman, Alexey Malahov, Paul Burton, Rob Herring,
Arnd Bergmann, Jason Cooper, Marc Zyngier, Rafael J. Wysocki,
Daniel Lezcano, James Hogan, linux-mips, devicetree,
Linux Kernel Mailing List
In-Reply-To: <20200601151903.ipd5ikw35z53eq2t@mobilestation>
On Mon, Jun 1, 2020 at 6:19 PM Serge Semin
<Sergey.Semin@baikalelectronics.ru> wrote:
> On Mon, Jun 01, 2020 at 04:56:21PM +0300, Andy Shevchenko wrote:
> > On Mon, Jun 1, 2020 at 3:26 PM Serge Semin
> > <Sergey.Semin@baikalelectronics.ru> wrote:
> > >
> > > Add myself as a maintainer of MIPS CPU and GIC IRQchip, MIPS GIC timer
> > > and MIPS CPS CPUidle drivers.
> > ...
> > > +MIPS CORE DRIVERS
> > > +M: Serge Semin <fancer.lancer@gmail.com>
> > > +L: linux-mips@vger.kernel.org
> > > +S: Supported
> > > +F: drivers/bus/mips_cdmm.c
> > > +F: drivers/irqchip/irq-mips-cpu.c
> > > +F: drivers/irqchip/irq-mips-gic.c
> > > +F: drivers/clocksource/mips-gic-timer.c
> > > +F: drivers/cpuidle/cpuidle-cps.c
> >
> > I think nowadays checkpatch.pl warns on wrong ordering in this data base.
>
> Alas it doesn't.
Ah, it definitely will.
it was relatively recently added by:
commit 9bbce40a4f72fe01a65669aee9f4036baa7fa26e
Author: Joe Perches <joe@perches.com>
Date: Tue May 26 10:36:34 2020 +1000
checkpatch: additional MAINTAINER section entry ordering checks
> Good point though.
You're welcome.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: ti: k3-am654-main: Update otap-del-sel values
From: Faiz Abbas @ 2020-06-01 15:37 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-arm-kernel; +Cc: robh+dt, t-kristo, nm
In-Reply-To: <20200519082027.5726-1-faiz_abbas@ti.com>
Hi,
On 19/05/20 1:50 pm, Faiz Abbas wrote:
> According to the latest AM65x Data Manual[1], a different output tap
> delay value is optimum for a given speed mode. Update these values.
>
> [1] http://www.ti.com/lit/gpn/am6526
>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> ---
>
> v3: Updated values to the latest data manual revision
>
> v2: Updated to the latest mainline kernel
>
Can this patch be picked up?
Thanks,
Faiz
^ permalink raw reply
* Re: [PATCH v11 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
From: Rob Herring @ 2020-06-01 15:38 UTC (permalink / raw)
To: Ramuthevar,Vadivel MuruganX
Cc: brendanhiggins, linux-mips, linux-mtd, tglx, hauke.mehrtens,
devicetree, robh+dt, andriy.shevchenko, anders.roxell,
cheol.yong.kim, arnd, boris.brezillon, qi-ming.wu, linux-kernel,
richard, masonccyang, vigneshr, miquel.raynal
In-Reply-To: <20200530005117.10986-2-vadivel.muruganx.ramuthevar@linux.intel.com>
On Sat, 30 May 2020 08:51:16 +0800, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>
> Add YAML file for dt-bindings to support NAND Flash Controller
> on Intel's Lightning Mountain SoC.
>
> Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> ---
> .../devicetree/bindings/mtd/intel,lgm-nand.yaml | 99 ++++++++++++++++++++++
> 1 file changed, 99 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH V2] dt-bindings: thermal: Convert qoriq to json-schema
From: Rob Herring @ 2020-06-01 15:39 UTC (permalink / raw)
To: Anson Huang
Cc: robh+dt, daniel.lezcano, amit.kucheria, linux-kernel, hongtao.jia,
rui.zhang, linux-pm, Linux-imx, devicetree
In-Reply-To: <1590982520-5437-1-git-send-email-Anson.Huang@nxp.com>
On Mon, 01 Jun 2020 11:35:20 +0800, Anson Huang wrote:
> Convert the qoriq thermal binding to DT schema format using json-schema
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V1:
> - add 'maxItems' for 'fsl,tmu-range' property;
> - add 'minItems'/'maxItems' and items descriptions for 'fsl,tmu-calibration' property;
> - remove description for common property '#thermal-sensor-cells';
> - refine 'fsl,tmu-calibration' format in example.
> ---
> .../devicetree/bindings/thermal/qoriq-thermal.txt | 71 -------------
> .../devicetree/bindings/thermal/qoriq-thermal.yaml | 112 +++++++++++++++++++++
> 2 files changed, 112 insertions(+), 71 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
> create mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: power: Convert imx gpc to json-schema
From: Rob Herring @ 2020-06-01 15:43 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, linux-arm-kernel, kernel, robh+dt, festevam,
ulf.hansson, Linux-imx, sboyd, shawnguo, p.zabel, andrew.smirnov,
krzk, linux-kernel, s.hauer
In-Reply-To: <1590998803-29191-1-git-send-email-Anson.Huang@nxp.com>
On Mon, 01 Jun 2020 16:06:42 +0800, Anson Huang wrote:
> Convert the i.MX GPC binding to DT schema format using json-schema
>
> >From latest reference manual, there is actually ONLY 1 interrupt for
> GPC, so the additional GPC interrupt is removed.
>
> Consumer's example is also removed since it is NOT that useful.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/power/fsl,imx-gpc.txt | 91 ---------------
> .../devicetree/bindings/power/fsl,imx-gpc.yaml | 124 +++++++++++++++++++++
> 2 files changed, 124 insertions(+), 91 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
> create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: power: Convert imx gpcv2 to json-schema
From: Rob Herring @ 2020-06-01 15:43 UTC (permalink / raw)
To: Anson Huang
Cc: andrew.smirnov, krzk, festevam, p.zabel, sboyd, linux-arm-kernel,
kernel, ulf.hansson, devicetree, s.hauer, linux-kernel, Linux-imx,
shawnguo, robh+dt
In-Reply-To: <1590998803-29191-2-git-send-email-Anson.Huang@nxp.com>
On Mon, 01 Jun 2020 16:06:43 +0800, Anson Huang wrote:
> Convert the i.MX GPCv2 binding to DT schema format using json-schema
>
> Example is updated based on latest DT file and consumer's example is
> removed since it is NOT that useful.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/power/fsl,imx-gpcv2.txt | 77 ---------------
> .../devicetree/bindings/power/fsl,imx-gpcv2.yaml | 108 +++++++++++++++++++++
> 2 files changed, 108 insertions(+), 77 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
> create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] dt-bindings: mailbox: Convert imx mu to json-schema
From: Rob Herring @ 2020-06-01 15:45 UTC (permalink / raw)
To: Anson Huang
Cc: linux-kernel, peng.fan, hongxing.zhu, linux, devicetree,
Linux-imx, aisheng.dong, jaswinder.singh, robh+dt
In-Reply-To: <1591007864-30267-1-git-send-email-Anson.Huang@nxp.com>
On Mon, 01 Jun 2020 18:37:44 +0800, Anson Huang wrote:
> Convert the i.MX MU binding to DT schema format using json-schema
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/mailbox/fsl,mu.txt | 58 --------------
> .../devicetree/bindings/mailbox/fsl,mu.yaml | 89 ++++++++++++++++++++++
> 2 files changed, 89 insertions(+), 58 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> create mode 100644 Documentation/devicetree/bindings/mailbox/fsl,mu.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 6/6] MAINTAINERS: Add maintainers for MIPS core drivers
From: Serge Semin @ 2020-06-01 15:52 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Thomas Bogendoerfer, Thomas Gleixner,
Greg Kroah-Hartman, Alexey Malahov, Paul Burton, Rob Herring,
Arnd Bergmann, Jason Cooper, Marc Zyngier, Rafael J. Wysocki,
Daniel Lezcano, James Hogan, linux-mips, devicetree,
Linux Kernel Mailing List
In-Reply-To: <CAHp75VdQYBqRUbUEHqjp0XE8bEsRcfTuDRn=R-j4c9TYH6niqw@mail.gmail.com>
On Mon, Jun 01, 2020 at 06:30:22PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 1, 2020 at 6:19 PM Serge Semin
> <Sergey.Semin@baikalelectronics.ru> wrote:
> > On Mon, Jun 01, 2020 at 04:56:21PM +0300, Andy Shevchenko wrote:
> > > On Mon, Jun 1, 2020 at 3:26 PM Serge Semin
> > > <Sergey.Semin@baikalelectronics.ru> wrote:
> > > >
> > > > Add myself as a maintainer of MIPS CPU and GIC IRQchip, MIPS GIC timer
> > > > and MIPS CPS CPUidle drivers.
> > > ...
> > > > +MIPS CORE DRIVERS
> > > > +M: Serge Semin <fancer.lancer@gmail.com>
> > > > +L: linux-mips@vger.kernel.org
> > > > +S: Supported
> > > > +F: drivers/bus/mips_cdmm.c
> > > > +F: drivers/irqchip/irq-mips-cpu.c
> > > > +F: drivers/irqchip/irq-mips-gic.c
> > > > +F: drivers/clocksource/mips-gic-timer.c
> > > > +F: drivers/cpuidle/cpuidle-cps.c
> > >
> > > I think nowadays checkpatch.pl warns on wrong ordering in this data base.
> >
> > Alas it doesn't.
>
> Ah, it definitely will.
> it was relatively recently added by:
> commit 9bbce40a4f72fe01a65669aee9f4036baa7fa26e
> Author: Joe Perches <joe@perches.com>
> Date: Tue May 26 10:36:34 2020 +1000
>
> checkpatch: additional MAINTAINER section entry ordering checks
>
>
> > Good point though.
>
> You're welcome.
Next time I won't forget that then. BTW the notes at the top of the MAINTAINERS
file don't explicitly say about the files-list order. Only about the
whole maintainers list entries order. Seeing the rest of the sub-entries like
L:, M:, etc. aren't ordered then it's probably better to have an explicit
statement, that files should be alphabetically listed, especially when
checkpatch.pl starts warning about that.
-Sergey
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 6/6] MAINTAINERS: Add maintainers for MIPS core drivers
From: Andy Shevchenko @ 2020-06-01 16:04 UTC (permalink / raw)
To: Serge Semin, Joe Perches
Cc: Serge Semin, Thomas Bogendoerfer, Thomas Gleixner,
Greg Kroah-Hartman, Alexey Malahov, Paul Burton, Rob Herring,
Arnd Bergmann, Jason Cooper, Marc Zyngier, Rafael J. Wysocki,
Daniel Lezcano, James Hogan, linux-mips, devicetree,
Linux Kernel Mailing List
In-Reply-To: <20200601155204.hsatjbukj6haxhld@mobilestation>
On Mon, Jun 1, 2020 at 6:52 PM Serge Semin
<Sergey.Semin@baikalelectronics.ru> wrote:
> On Mon, Jun 01, 2020 at 06:30:22PM +0300, Andy Shevchenko wrote:
> > On Mon, Jun 1, 2020 at 6:19 PM Serge Semin
> > <Sergey.Semin@baikalelectronics.ru> wrote:
> > > On Mon, Jun 01, 2020 at 04:56:21PM +0300, Andy Shevchenko wrote:
> > > > On Mon, Jun 1, 2020 at 3:26 PM Serge Semin
> > > > <Sergey.Semin@baikalelectronics.ru> wrote:
> > > > >
> > > > > Add myself as a maintainer of MIPS CPU and GIC IRQchip, MIPS GIC timer
> > > > > and MIPS CPS CPUidle drivers.
> > > > ...
> > > > > +MIPS CORE DRIVERS
> > > > > +M: Serge Semin <fancer.lancer@gmail.com>
> > > > > +L: linux-mips@vger.kernel.org
> > > > > +S: Supported
> > > > > +F: drivers/bus/mips_cdmm.c
> > > > > +F: drivers/irqchip/irq-mips-cpu.c
> > > > > +F: drivers/irqchip/irq-mips-gic.c
> > > > > +F: drivers/clocksource/mips-gic-timer.c
> > > > > +F: drivers/cpuidle/cpuidle-cps.c
> > > >
> > > > I think nowadays checkpatch.pl warns on wrong ordering in this data base.
> > >
> > > Alas it doesn't.
> >
>
> > Ah, it definitely will.
> > it was relatively recently added by:
> > commit 9bbce40a4f72fe01a65669aee9f4036baa7fa26e
> > Author: Joe Perches <joe@perches.com>
> > Date: Tue May 26 10:36:34 2020 +1000
> >
> > checkpatch: additional MAINTAINER section entry ordering checks
> >
> >
> > > Good point though.
> >
> > You're welcome.
>
> Next time I won't forget that then. BTW the notes at the top of the MAINTAINERS
> file don't explicitly say about the files-list order. Only about the
> whole maintainers list entries order. Seeing the rest of the sub-entries like
> L:, M:, etc. aren't ordered then it's probably better to have an explicit
> statement, that files should be alphabetically listed, especially when
> checkpatch.pl starts warning about that.
Joe, what do you think?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH V2] dt-bindings: thermal: Convert qoriq to json-schema
From: Rob Herring @ 2020-06-01 16:53 UTC (permalink / raw)
To: Anson Huang
Cc: Zhang Rui, Daniel Lezcano, Amit Kucheria, open list:THERMAL,
devicetree, linux-kernel@vger.kernel.org, NXP Linux Team,
Jia Hongtao
In-Reply-To: <1590982520-5437-1-git-send-email-Anson.Huang@nxp.com>
On Sun, May 31, 2020 at 9:45 PM Anson Huang <Anson.Huang@nxp.com> wrote:
>
> Convert the qoriq thermal binding to DT schema format using json-schema
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V1:
> - add 'maxItems' for 'fsl,tmu-range' property;
> - add 'minItems'/'maxItems' and items descriptions for 'fsl,tmu-calibration' property;
> - remove description for common property '#thermal-sensor-cells';
> - refine 'fsl,tmu-calibration' format in example.
> ---
> .../devicetree/bindings/thermal/qoriq-thermal.txt | 71 -------------
> .../devicetree/bindings/thermal/qoriq-thermal.yaml | 112 +++++++++++++++++++++
> 2 files changed, 112 insertions(+), 71 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
> create mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
[...]
> diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
> new file mode 100644
> index 0000000..c5df999
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
> @@ -0,0 +1,112 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
> +
> +maintainers:
> + - Hongtao Jia <hongtao.jia@freescale.com>
This email is bouncing. Should be @nxp.com?
Rob
^ permalink raw reply
* Re: [PATCH RESEND v2 0/6] mips: Add DT bindings for MIPS CDMM and MIPS GIC
From: Thomas Bogendoerfer @ 2020-06-01 16:56 UTC (permalink / raw)
To: Serge Semin
Cc: Marc Zyngier, Serge Semin, Thomas Gleixner, Greg Kroah-Hartman,
Alexey Malahov, Paul Burton, Rob Herring, Arnd Bergmann,
Jason Cooper, Rafael J. Wysocki, Daniel Lezcano, James Hogan,
linux-mips, devicetree, linux-kernel
In-Reply-To: <20200601152449.2okwqaqw4262nedu@mobilestation>
On Mon, Jun 01, 2020 at 06:24:49PM +0300, Serge Semin wrote:
> Hello Marc,
>
> On Mon, Jun 01, 2020 at 01:31:27PM +0100, Marc Zyngier wrote:
> > On 2020-06-01 13:21, Serge Semin wrote:
> >
> > [...]
> >
> > > Since Paul isn't looking after the MIPS arch code anymore, Ralf hasn't
> > > been seen maintaining MIPS for a long time, Thomas is only responsible
> > > for the next part of it:
> > > F: Documentation/devicetree/bindings/mips/
> > > F: Documentation/mips/
> > > F: arch/mips/
> > > F: drivers/platform/mips/
> > > the MIPS-specific drivers like:
> > > F: drivers/bus/mips_cdmm.c
> > > F: drivers/irqchip/irq-mips-cpu.c
> > > F: drivers/irqchip/irq-mips-gic.c
> > > F: drivers/clocksource/mips-gic-timer.c
> > > F: drivers/cpuidle/cpuidle-cps.c
> > > seem to be left for the subsystems maintainers to support. So if you
> > > don't
> > > mind or unless there is a better alternative, I can help with looking
> > > after them to ease the maintainers review burden and since I'll be
> > > working
> > > on our MIPS-based SoC drivers integrating into the mainline kernel repo
> > > anyway. If you don't like this idea, please just decline the last
> > > patch in the series.
> >
>
> > Given how deeply integrated the MIPS GIC is in the architecture, I'd
> > really like Thomas to co-maintain it, or at the very least give his
> > blessing on you being the dedicated point of contact for MIPS GIC
> > stuff.
>
> I don't mind either way. First option might be even better. Thomas,
> what do you think?
sure, I'm happy to be your co-maintainer.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCHv1 00/19] Improve SBS battery support
From: Sebastian Reichel @ 2020-06-01 17:05 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Rob Herring, Greg Kroah-Hartman, Rafael J . Wysocki, linux-pm,
devicetree, linux-kernel, kernel, 'Linux Samsung SOC'
In-Reply-To: <15933a91-dd89-1f94-c2f2-79be4395f4c1@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 4774 bytes --]
Hi Marek,
On Mon, Jun 01, 2020 at 12:40:27PM +0200, Marek Szyprowski wrote:
> On 13.05.2020 20:55, Sebastian Reichel wrote:
> > This patchset improves support for SBS compliant batteries. Due to
> > the changes, the battery now exposes 32 power supply properties and
> > (un)plugging it generates a backtrace containing the following message
> > without the first patch in this series:
> >
> > ---------------------------
> > WARNING: CPU: 0 PID: 20 at lib/kobject_uevent.c:659 add_uevent_var+0xd4/0x104
> > add_uevent_var: too many keys
> > ---------------------------
> >
> > For references this is what an SBS battery status looks like after
> > the patch series has been applied:
> >
> > cat /sys/class/power_supply/sbs-0-000b/uevent
> > POWER_SUPPLY_NAME=sbs-0-000b
> > POWER_SUPPLY_TYPE=Battery
> > POWER_SUPPLY_STATUS=Discharging
> > POWER_SUPPLY_CAPACITY_LEVEL=Normal
> > POWER_SUPPLY_HEALTH=Good
> > POWER_SUPPLY_PRESENT=1
> > POWER_SUPPLY_TECHNOLOGY=Li-ion
> > POWER_SUPPLY_CYCLE_COUNT=12
> > POWER_SUPPLY_VOLTAGE_NOW=11441000
> > POWER_SUPPLY_CURRENT_NOW=-26000
> > POWER_SUPPLY_CURRENT_AVG=-24000
> > POWER_SUPPLY_CAPACITY=76
> > POWER_SUPPLY_CAPACITY_ERROR_MARGIN=1
> > POWER_SUPPLY_TEMP=198
> > POWER_SUPPLY_TIME_TO_EMPTY_AVG=438600
> > POWER_SUPPLY_TIME_TO_FULL_AVG=3932100
> > POWER_SUPPLY_SERIAL_NUMBER=0000
> > POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000
> > POWER_SUPPLY_VOLTAGE_MAX_DESIGN=10800000
> > POWER_SUPPLY_ENERGY_NOW=31090000
> > POWER_SUPPLY_ENERGY_FULL=42450000
> > POWER_SUPPLY_ENERGY_FULL_DESIGN=41040000
> > POWER_SUPPLY_CHARGE_NOW=2924000
> > POWER_SUPPLY_CHARGE_FULL=3898000
> > POWER_SUPPLY_CHARGE_FULL_DESIGN=3800000
> > POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=3000000
> > POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=12300000
> > POWER_SUPPLY_MANUFACTURE_YEAR=2017
> > POWER_SUPPLY_MANUFACTURE_MONTH=7
> > POWER_SUPPLY_MANUFACTURE_DAY=3
> > POWER_SUPPLY_MANUFACTURER=UR18650A
> > POWER_SUPPLY_MODEL_NAME=GEHC
>
> This patch landed in linux-next dated 20200529. Sadly it causes a
> regression on Samsung Exynos-based Chromebooks (Exynos5250 Snow,
> Exynos5420 Peach-Pi and Exynos5800 Peach-Pit). System boots to
> userspace, but then, when udev populates /dev, booting hangs:
>
> [ 4.435167] VFS: Mounted root (ext4 filesystem) readonly on device
> 179:51.
> [ 4.457477] devtmpfs: mounted
> [ 4.460235] Freeing unused kernel memory: 1024K
> [ 4.464022] Run /sbin/init as init process
> INIT: version 2.88 booting
> [info] Using makefile-style concurrent boot in runlevel S.
> [ 5.102096] random: crng init done
> [....] Starting the hotplug events dispatcher: systemd-udevdstarting
> version 236
> [ ok .
> [....] Synthesizing the initial hotplug events...[ ok done.
> [....] Waiting for /dev to be fully populated...[ 34.409914]
> TPS65090_RAILSDCDC1: disabling
> [ 34.412977] TPS65090_RAILSDCDC2: disabling
> [ 34.417021] TPS65090_RAILSDCDC3: disabling
> [ 34.423848] TPS65090_RAILSLDO1: disabling
> [ 34.429068] TPS65090_RAILSLDO2: disabling
:(
log does not look useful either.
> Bisect between v5.7-rc1 and next-20200529 pointed me to the first bad
> commit: [c4b12a2f3f3de670f6be5e96092a2cab0b877f1a] power: supply:
> sbs-battery: simplify read_read_string_data.
ok. I tested this on an to-be-upstreamed i.MX6 based system
and arch/arm/boot/dts/imx53-ppd.dts. I think the difference
is, that i2c-exynos5 does not expose I2C_FUNC_SMBUS_READ_BLOCK_DATA.
I hoped all systems using SBS battery support this, but now
I see I2C_FUNC_SMBUS_EMUL only supports writing block data.
Looks like I need to add another patch implementing that
using the old code with added PEC support.
In any case that should only return -ENODEV for the property
(and uevent), but not break boot. So something fishy is going
on.
> However reverting it in linux-next doesn't fix the issue, so the
> next commits are also relevant to this issue.
The next patch, which adds PEC support depends on the simplification
of sbs_read_string_data. The old, open coded variant will result in
PEC failure for string properties (which should not stop boot either
of course). Can you try reverting both?
If that helps I will revert those two instead of dropping the whole
series for this merge window.
> Let me know how can I help debugging it.
I suspect, that this is userspace endlessly retrying reading the
battery uevent when an error is returned. Could you check this?
Should be easy to see by adding some printfs.
That would mean a faulty battery could stall complete boot without
a useful error message, which is bad and needs to be fixed.
Sorry for the inconvience and thanks for your report,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] check: Add 10bit/slave i2c reg flags support
From: Rob Herring @ 2020-06-01 17:08 UTC (permalink / raw)
To: Wolfram Sang
Cc: Serge Semin, Devicetree Compiler, Serge Semin, Alexey Malahov,
Thomas Bogendoerfer, Jarkko Nikula, Andy Shevchenko, Frank Rowand,
devicetree, Linux I2C, linux-kernel@vger.kernel.org
In-Reply-To: <20200530093152.GA1038@ninjato>
On Sat, May 30, 2020 at 3:32 AM Wolfram Sang <wsa@the-dreams.de> wrote:
>
>
> > + addr = reg & 0x3FFFFFFFU;
> > + snprintf(unit_addr, sizeof(unit_addr), "%x", addr);
>
> Hmm, this hardcoded value will not work if we ever need to add another
> bit. I hope this will never happen, though.
I had this concern and requested the first time this was submitted
(and abandoned) to just mask out the top byte. However, Joel's version
of this fix[1] does some actual checks on 10-bit addressing, so I've
dropped that request.
> > + if ((reg & (1U << 31)) && addr > 0x3ff)
>
> Same here with bit 31. I haven't checked DTC but can't we import the
> header with the defines into the project? Or is this then a circular
> dependency?
Easier to just duplicate the define here which Joel's patches do.
Rob
[1] https://www.spinics.net/lists/devicetree-compiler/msg03196.html
^ permalink raw reply
* Re: [PATCH RESEND v2 0/6] mips: Add DT bindings for MIPS CDMM and MIPS GIC
From: Serge Semin @ 2020-06-01 17:13 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Serge Semin, Marc Zyngier, Thomas Gleixner, Greg Kroah-Hartman,
Alexey Malahov, Paul Burton, Rob Herring, Arnd Bergmann,
Jason Cooper, Rafael J. Wysocki, Daniel Lezcano, James Hogan,
linux-mips, devicetree, linux-kernel
In-Reply-To: <20200601165646.GA12402@alpha.franken.de>
On Mon, Jun 01, 2020 at 06:56:46PM +0200, Thomas Bogendoerfer wrote:
> On Mon, Jun 01, 2020 at 06:24:49PM +0300, Serge Semin wrote:
> > Hello Marc,
> >
> > On Mon, Jun 01, 2020 at 01:31:27PM +0100, Marc Zyngier wrote:
> > > On 2020-06-01 13:21, Serge Semin wrote:
> > >
> > > [...]
> > >
> > > > Since Paul isn't looking after the MIPS arch code anymore, Ralf hasn't
> > > > been seen maintaining MIPS for a long time, Thomas is only responsible
> > > > for the next part of it:
> > > > F: Documentation/devicetree/bindings/mips/
> > > > F: Documentation/mips/
> > > > F: arch/mips/
> > > > F: drivers/platform/mips/
> > > > the MIPS-specific drivers like:
> > > > F: drivers/bus/mips_cdmm.c
> > > > F: drivers/irqchip/irq-mips-cpu.c
> > > > F: drivers/irqchip/irq-mips-gic.c
> > > > F: drivers/clocksource/mips-gic-timer.c
> > > > F: drivers/cpuidle/cpuidle-cps.c
> > > > seem to be left for the subsystems maintainers to support. So if you
> > > > don't
> > > > mind or unless there is a better alternative, I can help with looking
> > > > after them to ease the maintainers review burden and since I'll be
> > > > working
> > > > on our MIPS-based SoC drivers integrating into the mainline kernel repo
> > > > anyway. If you don't like this idea, please just decline the last
> > > > patch in the series.
> > >
> >
> > > Given how deeply integrated the MIPS GIC is in the architecture, I'd
> > > really like Thomas to co-maintain it, or at the very least give his
> > > blessing on you being the dedicated point of contact for MIPS GIC
> > > stuff.
> >
> > I don't mind either way. First option might be even better. Thomas,
> > what do you think?
>
> sure, I'm happy to be your co-maintainer.
>
Great! As soon as we finish a discussion regarding the files-list ordering
raised around the last patch in the series, I'll resend the patchset with you
added to the list of the MIPS core drivers maintainers.
-Sergey
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [RFC v1 2/3] drivers: nvmem: Add driver for QTI qfprom-efuse support
From: Doug Anderson @ 2020-06-01 18:08 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Ravi Kumar Bokka (Temp), Rob Herring, LKML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rajendra Nayak, Sai Prakash Ranjan, dhavalp, mturney, sparate,
c_rbokka, mkurumel
In-Reply-To: <1211660e-f1b0-0636-2dcf-1bc765118de3@linaro.org>
Hi,
On Mon, Jun 1, 2020 at 2:25 AM Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
>
>
>
> On 26/05/2020 23:31, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, May 22, 2020 at 4:18 AM Srinivas Kandagatla
> > <srinivas.kandagatla@linaro.org> wrote:
> >>
> >> On 21/05/2020 22:28, Doug Anderson wrote:
> >>> Hi,
> >>>
> >>> On Thu, May 21, 2020 at 8:56 AM Srinivas Kandagatla
> >>> <srinivas.kandagatla@linaro.org> wrote:
> >>>>
> >>>> On 21/05/2020 16:10, Doug Anderson wrote:
> >>>>>> On 20/05/2020 23:48, Doug Anderson wrote:
> >>>>>>>> Is this only applicable for corrected address space?
> >>>>>>> I guess I was proposing a two dts-node / two drive approach here.
> >>>>>>>
> >>>>>>> dts node #1:just covers the memory range for accessing the FEC-corrected data
> >>>>>>> driver #1: read-only and reads the FEC-corrected data
> >>>>>>>
> >>>>>>> dts node #2: covers the memory range that's_not_ the FEC-corrected
> >>>>>>> memory range.
> >>>>>>> driver #2: read-write. reading reads uncorrected data
> >>>>>>>
> >>>>>>> Does that seem sane?
> >>>>>> I see your point but it does not make sense to have two node for same thing.
> >>>>> OK, so that sounds as if we want to go with the proposal where we
> >>>>> "deprecate the old driver and/or bindings and say that there really
> >>>>> should just be one node and one driver".
> >>>>>
> >>>>> Would this be acceptable to you?
> >>>>>
> >>>>> 1. Officially mark the old bindings as deprecated.
> >>>>
> >>>> Possibly Yes for some reasons below!
> >>>>
> >>>>>
> >>>>> 2. Leave the old driver there to support the old deprecated bindings,
> >>>>> at least until everyone can be transferred over. There seem to be
> >>>>> quite a few existing users of "qcom,qfprom" and we're supposed to make
> >>>>> an attempt at keeping the old device trees working, at least for a
> >>>>> little while. Once everyone is transferred over we could decide to
> >>>>> delete the old driver.
> >>>> we could consider "qcom,qfrom" to be only passing corrected address
> >>>> space. Till we transition users to new bindings!
> >>>>
> >>>>>
> >>>> Yes.
> >>>>
> >>>>> 3. We will have a totally new driver here.
> >>>> No, we should still be using the same driver. But the exiting driver
> >>>> seems to incorrect and is need of fixing.
> >>>>
> >>>> Having a look at the memory map for old SoCs like msm8996 and msm8916
> >>>> shows that memory map that was passed to qfprom driver is corrected
> >>>> address space. Writes will not obviously work!
> >>>>
> >>>> This should also be true with sdm845 or sc7180
> >>>>
> >>>> That needs to be fixed first!
> >>>
> >>> OK, so to summarize:
> >>>
> >>
> >>> 1. We will have one driver: "drivers/nvmem/qfprom.c"
> >>
> >> Yes, we should one driver for this because we are dealing with exactly
> >> same IP.
> >>
> >>>
> >>> 2. If the driver detects that its reg is pointing to the corrected
> >>> address space then it should operate in read-only mode. Maybe it can
> >>> do this based on the compatible string being just "qcom,qfprom" or
> >>> maybe it can do this based on the size of the "reg".
> >>
> >> I found out that there is a version register at offset of 0x6000 which
> >> can give MAJOR, MINOR and STEP numbers.
> >>
> >> So we could still potentially continue using "qcom,qfprom"
> >
> > OK, sounds good. I think it's still good practice to include both the
> > SoC specific and the generic. Even if the driver never does anything
> > with the SoC-specific compatible string it doesn't hurt to have it
> > there. Thus, we'd want:
> >
> > compatible = "qcom,msm8996-qfprom", "qcom,qfprom"
> >
> > The driver itself would never need to refer to the SoC-specific name
> > but that does give us more flexibility.
> >
> >
> >> The address space can be split into 3 resources, which is inline with
> >> Specs as well
> >>
> >> 1. Raw address space ("raw")
> >> 2. Configuration address space ("conf" or "core")
> >> 3. Corrected address space ("corrected")
> >
> > Sure, this is OK with me then. Originally Ravi had 3 ranges but then
> > he was (in the driver) treating it as one range. As long as the
> > driver truly treats it as 3 ranges I have no problem doing it like
> > this.
> >
> > In general, over the years, there has been a push to keep
> > implementation details out of the dts and rely more on the "of_match"
> > table to add SoC-specific details. This becomes really important when
> > 1 year down the road you realize that you need one more random
> > property or address range to fix some bug and then you need to figure
> > out how to try to keep old "dts" files compatible. It's not a
> > hard-and-fast rule, though.
>
> Am not 100% sure if "qcom,fuse-blow-frequency" is something integration
> specific or SoC Specific, My idea was that this will give more
> flexibility in future. As adding new SoC Support does not need driver
> changes.
>
> Having said that, Am okay either way!
Yeah, it's always a balance. I guess the question is: why do we think
driver changes are worse than dts changes? The value still needs to
be somewhere and having it in the driver isn't a terrible place.
> Incase we go compatible way, I would like to see compatible strings
> having proper IP versions to have ip version rather than SoC names.
>
> Having SoC names in compatible string means both driver and bindings
> need update for every new SoC which can be overhead very soon!
Almost certainly the compatible strings should have SoC names in them.
Yes it means a binding update every time a new SoC comes up but that
is just how device tree works. Presumably there's enough chatter on
this that Rob H has totally tuned it out at this point in time, but
there are many other instances of this.
NOTE: just because we have the SoC name in the compatible string
_doesn't_ mean that the driver has to change. You already said that
the IP version can be detected earlier in this thread, right? You
said:
I found out that there is a version register at offset of 0x6000 which
can give MAJOR, MINOR and STEP numbers.
So how about this:
a) Compatible contains "SoC" version and the generic "qcom,qfrom", so:
compatible = "qcom,sdm845-qfprom", "qcom,qfrom"
b) Bindings will need to be updated for every new SoC, but that's
normal and should be a trivial patch to just add a new SoC to the
list.
c) If the driver can be made to make its decisions about frequencies /
timings completely by MAJOR/MINOR/STEP numbers then it can use those
in its decision and it will never need to use the SoC-specific
compatible string. The SoC-specific compatible string will only be
present as a fallback "oops we have to workaround a bug that we didn't
know about".
> Rob can help review once we have v2 bindings out!
Sounds good. If you're still not convinced by my arguments we can see
if we can get Rob to clarify once we have a v2. :-)
> >> Exiting qfprom entries or read-only qfprom will have "corrected"
> >> address space which can be the only resource provided by device tree
> >> entries.
> >> Other two entries("raw" and "conf") are optional.
> >>
> >> qfprom: qfprom@780000 {
> >> compatible = "qcom,qfprom";
> >> reg = <0 0x00780000 0 0x8ff>,
> >> <0 0x00782000 0 0x100>,
> >> <0 0x00784000 0 0x8ff>;
> >> reg-names = "raw", "conf", "corrected";
> >>
> >> vcc-supply = <&vreg_xyz>;
> >>
> >> clocks = <&gcc GCC_SEC_CTRL_CLK_SRC>;
> >> clock-names = "secclk";
> >>
> >> assigned-clocks = <&gcc GCC_SEC_CTRL_CLK_SRC>;
> >> assigned-clock-rates = <19200000>;
> >>
> >> qcom,fuse-blow-frequency = <4800000>
> >>
> >> #address-cells = <1>;
> >> #size-cells = <1>;
> >>
> >> qusb2p_hstx_trim: hstx-trim-primary@25b {
> >> reg = <0x25b 0x1>;
> >> bits = <1 3>;
> >> };
> >> };
> >>
> >> Regarding clk rate setting, the default rate can be set using
> >> assigned-clock-rates property, however the blow frequency can go as new
> >> binding.
> >> regarding voltage range for regulator, it should come as part of board
> >> specific voltage regulator node. In worst case we can discuss on adding
> >> new bindings for allowing specific range.
> >
> > I'd up to you (and Rob H, who probably will wait for the next rev of
> > the binding before chiming in) but the "qcom,fuse-blow-frequency" is
> > the type of property that feels better in the driver and achieved from
> > the of_match table. Then you don't need to worry about adding it to
> > the bindings. Voltage (if needed) would be similar, but I would hope
> > we don't need it.
> >
> >
> >> for Older SoCs: we still continue to use old style with just one
> >> resource corresponding to corrected by default.
> >>
> >> qfprom: qfprom@784000 {
> >> compatible = "qcom,qfprom";
> >> reg = <0 0x00784000 0 0x8ff>;
> >> #address-cells = <1>;
> >> #size-cells = <1>;
> >>
> >> qusb2p_hstx_trim: hstx-trim-primary@1eb {
> >> reg = <0x1eb 0x1>;
> >> bits = <1 4>;
> >> };
> >>
> >> qusb2s_hstx_trim: hstx-trim-secondary@1eb {
> >> reg = <0x1eb 0x2>;
> >> bits = <6 4>;
> >> };
> >> };
> >>
> >>
> >> I see the patch as adding write support to qfprom, rather than adding
> >> new driver or new SoC support.
> >>
> >> This in summary should give us good direction for this patch!
> >>
> >> Correct me if I miss understood something here!
> >
> > Sounds sane to me.
>
> Cool! lets see how v2 will endup like!
>
> --srini
> >
> >
> > -Doug
> >
^ permalink raw reply
* [RFC PATCH -next] MAINTAINERS: Update F: and X: entry ordering (was Re: [PATCH v2 6/6] MAINTAINERS: Add maintainers for MIPS core drivers)
From: Joe Perches @ 2020-06-01 18:22 UTC (permalink / raw)
To: Andy Shevchenko, Serge Semin, Andrew Morton, Linus Torvalds
Cc: Serge Semin, Thomas Bogendoerfer, Thomas Gleixner,
Greg Kroah-Hartman, Alexey Malahov, Paul Burton, Rob Herring,
Arnd Bergmann, Jason Cooper, Marc Zyngier, Rafael J. Wysocki,
Daniel Lezcano, James Hogan, linux-mips, devicetree,
Linux Kernel Mailing List
In-Reply-To: <CAHp75Vej9gRAVspzfruciQ7weFunNBtj8GxbgBCVWtGwk5_ntQ@mail.gmail.com>
On Mon, 2020-06-01 at 19:04 +0300, Andy Shevchenko wrote:
> On Mon, Jun 1, 2020 at 6:52 PM Serge Semin <Sergey.Semin@baikalelectronics.ru> wrote:
> > On Mon, Jun 01, 2020 at 06:30:22PM +0300, Andy Shevchenko wrote:
> > > On Mon, Jun 1, 2020 at 6:19 PM Serge Semin <Sergey.Semin@baikalelectronics.ru> wrote:
> > > > On Mon, Jun 01, 2020 at 04:56:21PM +0300, Andy Shevchenko wrote:
> > > > > On Mon, Jun 1, 2020 at 3:26 PM Serge Semin <Sergey.Semin@baikalelectronics.ru> wrote:
> > > > > > Add myself as a maintainer of MIPS CPU and GIC IRQchip, MIPS GIC timer
> > > > > > and MIPS CPS CPUidle drivers.
> > > > > ...
> > > > > > +MIPS CORE DRIVERS
> > > > > > +M: Serge Semin <fancer.lancer@gmail.com>
> > > > > > +L: linux-mips@vger.kernel.org
> > > > > > +S: Supported
> > > > > > +F: drivers/bus/mips_cdmm.c
> > > > > > +F: drivers/irqchip/irq-mips-cpu.c
> > > > > > +F: drivers/irqchip/irq-mips-gic.c
> > > > > > +F: drivers/clocksource/mips-gic-timer.c
> > > > > > +F: drivers/cpuidle/cpuidle-cps.c
> > > > >
> > > > > I think nowadays checkpatch.pl warns on wrong ordering in this data base.
[]
> > Next time I won't forget that then. BTW the notes at the top of the MAINTAINERS
> > file don't explicitly say about the files-list order. Only about the
> > whole maintainers list entries order. Seeing the rest of the sub-entries like
> > L:, M:, etc. aren't ordered then it's probably better to have an explicit
> > statement, that files should be alphabetically listed, especially when
> > checkpatch.pl starts warning about that.
>
> Joe, what do you think?
Fine by me. Maybe something like the below.
Another thing might be to intermix the F and X entries so that
exclusions are more obviously against the F: entries.
There aren't many MAINTAINERS lines changed when the modified
parse-maintainers is run, but I think it reads better.
It doesn't seem the last major reordering with parse-maintainers
caused any significant issue for anyone.
I think having Linus run scripts/parse-maintainers.pl just before
every release or every few releases would make this issue go away.
---
MAINTAINERS | 1 +
scripts/checkpatch.pl | 17 +++++++----------
scripts/parse-maintainers.pl | 5 ++---
3 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b045b70e54df..4b53119504ff 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -118,6 +118,7 @@ Descriptions of section entries and preferred order
F: net/
X: net/ipv6/
matches all files in and below net excluding net/ipv6/
+ F: and X: entries are intermixed in case sensitive alphabetic order
N: Files and directories *Regex* patterns.
N: [^a-z]tegra all files whose path contains tegra
(not including files like integrator)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index dd750241958b..499c85be0b2f 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3099,16 +3099,13 @@ sub process {
if ($curindex < 0) {
WARN("MAINTAINERS_STYLE",
"Unknown MAINTAINERS entry type: '$cur'\n" . $herecurr);
- } else {
- if ($previndex >= 0 && $curindex < $previndex) {
- WARN("MAINTAINERS_STYLE",
- "Misordered MAINTAINERS entry - list '$cur:' before '$prev:'\n" . $hereprev);
- } elsif ((($prev eq 'F' && $cur eq 'F') ||
- ($prev eq 'X' && $cur eq 'X')) &&
- ($prevval cmp $curval) > 0) {
- WARN("MAINTAINERS_STYLE",
- "Misordered MAINTAINERS entry - list file patterns in alphabetic order\n" . $hereprev);
- }
+ } elsif ($previndex >= 0 && $curindex < $previndex && !($prev =~ /[FX]/ && $cur =~ /[FX]/)) {
+ WARN("MAINTAINERS_STYLE",
+ "Misordered MAINTAINERS entry - list '$cur:' before '$prev:'\n" . $hereprev);
+ } elsif ((($prev =~ /[FX]/ && $cur =~ /[FX]/) &&
+ ($prevval cmp $curval) > 0)) {
+ WARN("MAINTAINERS_STYLE",
+ "Misordered MAINTAINERS entry - list F and X file patterns in alphabetic order\n" . $hereprev);
}
}
}
diff --git a/scripts/parse-maintainers.pl b/scripts/parse-maintainers.pl
index 2ca4eb3f190d..8d2247a596f0 100755
--- a/scripts/parse-maintainers.pl
+++ b/scripts/parse-maintainers.pl
@@ -84,9 +84,8 @@ sub by_pattern($$) {
$a_index = 1000 if ($a_index == -1);
$b_index = 1000 if ($b_index == -1);
- if (($a1 =~ /^F$/ && $b1 =~ /^F$/) ||
- ($a1 =~ /^X$/ && $b1 =~ /^X$/)) {
- return $a cmp $b;
+ if (($a1 =~ /^[FX]$/ && $b1 =~ /^[FX]$/)) {
+ return substr($a, 1) cmp substr($b, 1);
}
if ($a_index < $b_index) {
^ permalink raw reply related
* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Tomasz Figa @ 2020-06-01 18:18 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Sakari Ailus, Rob Herring, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Mark Rutland,
Nicolas Boichat, Matthias Brugger, Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Sj Huang,
Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男)
In-Reply-To: <1590978816.8804.523.camel@mhfsdcap03>
On Mon, Jun 1, 2020 at 4:35 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
>
> Hi Tomasz,
>
> On Fri, 2020-05-29 at 15:43 +0200, Tomasz Figa wrote:
> > On Thu, May 28, 2020 at 10:06 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > >
> > > Hi Sakari,
> > >
> > > On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote:
> > > > Hi Dongchun,
> > > >
> > > > On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote:
> > > > > Hi Sakari, Rob,
> > > > >
> > > > > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote:
> > > > > > Hi Rob, Dongchun,
> > > > > >
> > > > > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote:
> > > > > > > > > > + properties:
> > > > > > > > > > + endpoint:
> > > > > > > > > > + type: object
> > > > > > > > > > + additionalProperties: false
> > > > > > > > > > +
> > > > > > > > > > + properties:
> > > > > > > >
> > > > > > > > Actually I wonder whether we need to declare 'clock-lanes' here?
> > > > > > >
> > > > > > > Yes, if you are using it.
> > > > > >
> > > > > > Dongchun, can you confirm the chip has a single data and a single clock
> > > > > > lane and that it does not support lane reordering?
> > > > > >
> > > > >
> > > > > From the datasheet, 'MIPI inside the OV02A10 provides one single
> > > > > uni-directional clock lane and one bi-directional data lane solution for
> > > > > communication links between components inside a mobile device.
> > > > > The data lane has full support for HS(uni-directional) and
> > > > > LP(bi-directional) data transfer mode.'
> > > > >
> > > > > The sensor doesn't support lane reordering, so 'clock-lanes' property
> > > > > would not be added in next release.
> > > > >
> > > > > > So if there's nothing to convey to the driver, also the data-lanes should
> > > > > > be removed IMO.
> > > > > >
> > > > >
> > > > > However, 'data-lanes' property may still be required.
> > > > > It is known that either data-lanes or clock-lanes is an array of
> > > > > physical data lane indexes. Position of an entry determines the logical
> > > > > lane number, while the value of an entry indicates physical lane, e.g.,
> > > > > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming
> > > > > the clock lane is on hardware lane 0.
> > > > >
> > > > > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not
> > > > > support lane reordering, so here we shall use 'data-lanes = <1>' as
> > > > > there is only a clock lane for OV02A10.
> > > > >
> > > > > Reminder:
> > > > > If 'data-lanes' property is not present, the driver would assume
> > > > > four-lane operation. This means for one-lane or two-lane operation, this
> > > > > property must be present and set to the right physical lane indexes.
> > > > > If the hardware does not support lane reordering, monotonically
> > > > > incremented values shall be used from 0 or 1 onwards, depending on
> > > > > whether or not there is also a clock lane.
> > > >
> > > > How can the driver use four lanes, considering the device only supports a
> > > > single lane??
> > > >
> > >
> > > I understood your meaning.
> > > If we omit the property 'data-lanes', the sensor should work still.
> > > But then what's the meaning of the existence of 'data-lanes'?
> > > If this property 'data-lanes' is always optional, then why dt-bindings
> > > provide the interface?
> > >
> > > In the meantime, if omitting 'data-lanes' for one sensor(transmitter)
> > > that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2)
> > > shall enable four-lane configuration, which may increase consumption of
> > > both power and resource in the process of IIC communication.
> >
> > Wouldn't the receiver still have the data-lanes property under its
> > endpoint node, telling it how many lanes and in which order should be
> > used?
> >
>
> The MIPI receiver(RX) shall use
> v4l2_async_notifier_add_fwnode_remote_subdev() API to parse the property
> "data-lanes" under sensor output port.
That's not true. The MIPI receiver driver parses its own port node
corresponding to the sensor. Also quoting the documentation [1]:
"An endpoint subnode of a device contains all properties needed for
_configuration of this device_ for data exchange with other device. In most
cases properties at the peer 'endpoint' nodes will be identical, however they
might need to be different when there is any signal modifications on the bus
between two devices, e.g. there are logic signal inverters on the lines."
In this case, there is such a signal modification if the sensor has a
1-lane bus and the receiver more lines, so the data-lanes properties
would be different on both sides.
[1] https://elixir.bootlin.com/linux/v5.7/source/Documentation/devicetree/bindings/media/video-interfaces.txt
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH v2 0/3] media: rockchip: Introduce driver for the camera interface on PX30
From: Tomasz Figa @ 2020-06-01 18:45 UTC (permalink / raw)
To: Maxime Chevallier, Helen Koike, Dafna Hirschfeld
Cc: Mauro Carvalho Chehab, Robin Murphy, Rob Herring, Mark Rutland,
Heiko Stuebner, Hans Verkuil, Linux Media Mailing List,
linux-devicetree,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>,,
open list:ARM/Rockchip SoC..., Linux Kernel Mailing List,
Thomas Petazzoni, Miquel Raynal, Paul Kocialkowski
In-Reply-To: <20200529130405.929429-1-maxime.chevallier@bootlin.com>
Hi Maxime,
On Fri, May 29, 2020 at 3:04 PM Maxime Chevallier
<maxime.chevallier@bootlin.com> wrote:
>
> Hello everyone,
>
> Here's a V2 of the series adding very basic support for the camera interface on
> the Rockchip PX30 SoC.
>
> Thanks to everyone that commented on the first series, your reviews were
> very helpful :)
>
> This Camera Interface is also supported on other Rockchip SoC such as
> the RK1808, RK3128, RK3288 and RK3288, but for now I've only been able to
> test it on the PX30, using a PAL format.
How does this hardware relate to the one handled by the rkisp1 driver
that is available under staging/media/rkisp1? It was written with
RK3399 in mind, but I have a loose recollection that the hardware in
RK3288 was roughly the same.
+Helen Koike +Dafna Hirschfeld working on the rkisp1 driver.
Best regards,
Tomasz
>
> This driver is mostly based on the driver found in Rockchip's BSP, that
> has been trimmed down to support the set of features that I was able to test,
> that is pretty much a very basic one-frame capture and video streaming
> with GStreamer.
>
> This first draft only supports the Parallel interface, although the
> controller has support for BT656 and CSI2.
>
> Finally, this controller has an iommu that could be used in this driver,
> but as of today I've not been able to get it to work.
>
> Any review is welcome.
>
> Thanks,
>
> Maxime
>
> --- Changes since V1 ---
>
> - Took reviews from Rob, Hans, Robin and Heiko into account :
> - Renamed the clocks in the binding
> - Fixed the DT schema compiling
> - Fixed a few typos
> - Used the clk bulk API
> - Used the reset array API
> - Changed a few helpers for more suitable ones
> - Rebased on 5.7-rc7
>
>
>
> Maxime Chevallier (3):
> media: dt-bindings: media: Document Rockchip CIF bindings
> media: rockchip: Introduce driver for Rockhip's camera interface
> arm64: dts: rockchip: Add the camera interface description of the PX30
>
> .../bindings/media/rockchip-cif.yaml | 100 ++
> arch/arm64/boot/dts/rockchip/px30.dtsi | 12 +
> drivers/media/platform/Kconfig | 13 +
> drivers/media/platform/Makefile | 1 +
> drivers/media/platform/rockchip/cif/Makefile | 3 +
> drivers/media/platform/rockchip/cif/capture.c | 1170 +++++++++++++++++
> drivers/media/platform/rockchip/cif/dev.c | 358 +++++
> drivers/media/platform/rockchip/cif/dev.h | 213 +++
> drivers/media/platform/rockchip/cif/regs.h | 256 ++++
> 9 files changed, 2126 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/rockchip-cif.yaml
> create mode 100644 drivers/media/platform/rockchip/cif/Makefile
> create mode 100644 drivers/media/platform/rockchip/cif/capture.c
> create mode 100644 drivers/media/platform/rockchip/cif/dev.c
> create mode 100644 drivers/media/platform/rockchip/cif/dev.h
> create mode 100644 drivers/media/platform/rockchip/cif/regs.h
>
> --
> 2.25.4
>
^ permalink raw reply
* Re: [V6, 2/2] media: i2c: dw9768: Add DW9768 VCM driver
From: Tomasz Figa @ 2020-06-01 18:47 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Linus Walleij, Bartosz Golaszewski, Mauro Carvalho Chehab,
Andy Shevchenko, Rob Herring, Mark Rutland, Sakari Ailus,
Nicolas Boichat, Matthias Brugger, Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男)
In-Reply-To: <1590570089.8804.453.camel@mhfsdcap03>
On Wed, May 27, 2020 at 11:03 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
>
> Hi Tomasz,
>
> On Mon, 2020-05-25 at 13:45 +0200, Tomasz Figa wrote:
> > On Fri, May 22, 2020 at 11:27 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > >
> > > Hi Tomasz,
> > >
> > > Thanks for the review. My replies are as below.
> > >
> > > On Thu, 2020-05-21 at 19:51 +0000, Tomasz Figa wrote:
> > > > Hi Dongchun, Sakari,
> > > >
> > > > On Mon, May 18, 2020 at 09:27:31PM +0800, Dongchun Zhu wrote:
> > [snip]
> > > > > + pm_runtime_enable(dev);
> > > > > + if (!pm_runtime_enabled(dev)) {
> > > > > + ret = dw9768_runtime_resume(dev);
> > > > > + if (ret < 0) {
> > > > > + dev_err(dev, "failed to power on: %d\n", ret);
> > > > > + goto entity_cleanup;
> > > > > + }
> > > > > + }
> > > > > +
> > > > > + ret = v4l2_async_register_subdev(&dw9768->sd);
> > > > > + if (ret < 0)
> > > > > + goto entity_cleanup;
> > > > > +
> > > > > + return 0;
> > > > > +
> > > > > +entity_cleanup:
> > > >
> > > > Need to power off if the code above powered on.
> > > >
> > >
> > > Thanks for the reminder.
> > > If there is something wrong with runtime PM, actuator is to be powered
> > > on via dw9768_runtime_resume() API.
> > > When actuator sub-device is powered on completely and async registered
> > > successfully, we shall power off it afterwards.
> > >
> >
> > The code above calls dw9768_runtime_resume() if
> > !pm_runtime_enabled(dev), but the clean-up code below the
> > entity_cleanup label doesn't have the corresponding
> > dw9768_runtime_suspend() call.
> >
>
> Did you mean the 'entity_cleanup' after v4l2_async_register_subdev()?
Yes.
> Actually I made some changes for OV02A V9, according to this comment.
> Could you help review that change? Thanks.
Sure, I will take a look.
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: memory: document Renesas RPC-IF bindings
From: Sergei Shtylyov @ 2020-06-01 19:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, Mason Yang, linux-spi, Chris Brandt, linux-mtd
In-Reply-To: <20200501212547.GB15294@bogus>
On 05/02/2020 12:25 AM, Rob Herring wrote:
>> Renesas Reduced Pin Count Interface (RPC-IF) allows a SPI flash or
>> HyperFlash connected to the SoC to be accessed via the external address
>> space read mode or the manual mode.
>>
>> Document the device tree bindings for the Renesas RPC-IF found in the R-Car
>> gen3 SoCs.
>>
>> Based on the original patch by Mason Yang <masonccyang@mxic.com.tw>.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
[...]
>> Index: linux/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml
>> ===================================================================
>> --- /dev/null
>> +++ linux/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml
>> @@ -0,0 +1,88 @@
[...]
>> +patternProperties:
>> + "^.*@[0-9a-f]+$":
>
> ^flash@... if you're that restrictive.
>
>> + type: object
>> + properties:
>> + compatible:
>> + oneOf:
>> + - const: cfi-flash
>> + - const: jedec,spi-nor
>
> enum is better than oneOf+const.
- enum:
- cfi-flash
- jedec,spi-nor
causes the build error you encountered while trying to merge the last time.
What was I doing wrong?
[...]
MBR, Sergei
^ 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