* Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Florian Fainelli @ 2020-05-20 16:03 UTC (permalink / raw)
To: Dan Murphy, Andrew Lunn
Cc: hkallweit1, davem, netdev, linux-kernel, devicetree
In-Reply-To: <95ab99bf-2fb5-c092-ad14-1b0a47c782a4@ti.com>
On 5/20/2020 8:56 AM, Dan Murphy wrote:
> Andrew
>
> On 5/20/20 10:36 AM, Andrew Lunn wrote:
>>>> Hi Dan
>>>>
>>>> Having it required with PHY_INTERFACE_MODE_RGMII_ID or
>>>> PHY_INTERFACE_MODE_RGMII_RXID is pretty unusual. Normally these
>>>> properties are used to fine tune the delay, if the default of 2ns does
>>>> not work.
>>> Also if the MAC phy-mode is configured with RGMII-ID and no internal
>>> delay
>>> values defined wouldn't that be counter intuitive?
>> Most PHYs don't allow the delay to be fine tuned. You just pass for
>> example PHY_INTERFACE_MODE_RGMII_ID to the PHY driver and it enables a
>> 2ns delay. That is what people expect, and is documented.
>
>> Being able to tune the delay is an optional extra, which some PHYs
>> support, but that is always above and beyond
>> PHY_INTERFACE_MODE_RGMII_ID.
>
> I am interested in knowing where that is documented. I want to RTM I
> grepped for a few different words but came up empty
>
> Since this is a tuneable phy we need to program the ID. 2ns is the
> default value
>
> Maybe I can change it from Required to Configurable or Used.
I do not think this is properly documented, it is an established
practice, but it should be clearly documented somewhere, I do not know
whether that belongs in the PHY Device Tree binding or if this belongs
to the PHY documentation.
--
Florian
^ permalink raw reply
* Re: [PATCH] i2c: pxa: implement generic i2c bus recovery
From: Wolfram Sang @ 2020-05-20 15:59 UTC (permalink / raw)
To: Russell King
Cc: linux-i2c, Andrew Lunn, devicetree, Gregory Clement, Jason Cooper,
linux-arm-kernel, Rob Herring, Sebastian Hesselbarth,
Vladimir Vid
In-Reply-To: <E1jYnlI-0002Nw-83@rmk-PC.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 279 bytes --]
On Wed, May 13, 2020 at 10:33:12AM +0100, Russell King wrote:
> Implement generic GPIO-based I2C bus recovery for the PXA I2C driver.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied to for-next, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: bcm: HR2: Fix PPI interrupt types
From: Florian Fainelli @ 2020-05-20 15:56 UTC (permalink / raw)
To: Hamish Martin, robh+dt, rjui, sbranden; +Cc: devicetree, linux-arm-kernel
In-Reply-To: <20200520043042.7281-1-hamish.martin@alliedtelesis.co.nz>
On 5/19/2020 9:30 PM, Hamish Martin wrote:
> These error messages are output when booting on a BCM HR2 system:
> GIC: PPI11 is secure or misconfigured
> GIC: PPI13 is secure or misconfigured
>
> Per ARM documentation these interrupts are triggered on a rising edge.
> See ARM Cortex A-9 MPCore Technical Reference Manual, Revision r4p1,
> Section 3.3.8 Interrupt Configuration Registers.
>
> The same issue was resolved for NSP systems in commit 5f1aa51c7a1e
> ("ARM: dts: NSP: Fix PPI interrupt types").
>
> Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Thanks Hamish, this should also have a:
Fixes: b9099ec754b5 ("ARM: dts: Add Broadcom Hurricane 2 DTS include file")
I will take care of adding it while applying, thanks!
> ---
> arch/arm/boot/dts/bcm-hr2.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm-hr2.dtsi b/arch/arm/boot/dts/bcm-hr2.dtsi
> index 6142c672811e..5e5f5ca3c86f 100644
> --- a/arch/arm/boot/dts/bcm-hr2.dtsi
> +++ b/arch/arm/boot/dts/bcm-hr2.dtsi
> @@ -75,7 +75,7 @@ a9pll: arm_clk@0 {
> timer@20200 {
> compatible = "arm,cortex-a9-global-timer";
> reg = <0x20200 0x100>;
> - interrupts = <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>;
> + interrupts = <GIC_PPI 11 IRQ_TYPE_EDGE_RISING>;
> clocks = <&periph_clk>;
> };
>
> @@ -83,7 +83,7 @@ twd-timer@20600 {
> compatible = "arm,cortex-a9-twd-timer";
> reg = <0x20600 0x20>;
> interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(1) |
> - IRQ_TYPE_LEVEL_HIGH)>;
> + IRQ_TYPE_EDGE_RISING)>;
> clocks = <&periph_clk>;
> };
>
> @@ -91,7 +91,7 @@ twd-watchdog@20620 {
> compatible = "arm,cortex-a9-twd-wdt";
> reg = <0x20620 0x20>;
> interrupts = <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) |
> - IRQ_TYPE_LEVEL_HIGH)>;
> + IRQ_TYPE_EDGE_RISING)>;
> clocks = <&periph_clk>;
> };
>
>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Dan Murphy @ 2020-05-20 15:56 UTC (permalink / raw)
To: Andrew Lunn
Cc: f.fainelli, hkallweit1, davem, netdev, linux-kernel, devicetree
In-Reply-To: <20200520153631.GH652285@lunn.ch>
Andrew
On 5/20/20 10:36 AM, Andrew Lunn wrote:
>>> Hi Dan
>>>
>>> Having it required with PHY_INTERFACE_MODE_RGMII_ID or
>>> PHY_INTERFACE_MODE_RGMII_RXID is pretty unusual. Normally these
>>> properties are used to fine tune the delay, if the default of 2ns does
>>> not work.
>> Also if the MAC phy-mode is configured with RGMII-ID and no internal delay
>> values defined wouldn't that be counter intuitive?
> Most PHYs don't allow the delay to be fine tuned. You just pass for
> example PHY_INTERFACE_MODE_RGMII_ID to the PHY driver and it enables a
> 2ns delay. That is what people expect, and is documented.
> Being able to tune the delay is an optional extra, which some PHYs
> support, but that is always above and beyond
> PHY_INTERFACE_MODE_RGMII_ID.
I am interested in knowing where that is documented. I want to RTM I
grepped for a few different words but came up empty
Since this is a tuneable phy we need to program the ID. 2ns is the
default value
Maybe I can change it from Required to Configurable or Used.
Dan
> Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 2/4] net: phy: dp83869: Set opmode from straps
From: Florian Fainelli @ 2020-05-20 15:49 UTC (permalink / raw)
To: Dan Murphy, andrew, hkallweit1, davem; +Cc: netdev, linux-kernel, devicetree
In-Reply-To: <20200520121835.31190-3-dmurphy@ti.com>
On 5/20/2020 5:18 AM, Dan Murphy wrote:
> If the op-mode for the device is not set in the device tree then set
> the strapped op-mode and store it for later configuration.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH v8 3/5] ARM: dts: add Protonic VT7 board
From: Oleksij Rempel @ 2020-05-20 15:41 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: Oleksij Rempel, Rob Herring, Robin van der Gracht, David Jander,
devicetree, Fabio Estevam, linux-arm-kernel, linux-kernel,
NXP Linux Team, Pengutronix Kernel Team
In-Reply-To: <20200520154116.12909-1-o.rempel@pengutronix.de>
The Protonic VT7 is a mid-class ISObus Virtual Terminal with a 7 inch
touchscreen display.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Robin van der Gracht <robin@protonic.nl>
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-prtvt7.dts | 411 ++++++++++++++++++++++++++++
2 files changed, 412 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-prtvt7.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8ce744f1cbfc9..66ee89e7929f9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -450,6 +450,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+ imx6dl-prtvt7.dtb \
imx6dl-rex-basic.dtb \
imx6dl-riotboard.dtb \
imx6dl-sabreauto.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts b/arch/arm/boot/dts/imx6dl-prtvt7.dts
new file mode 100644
index 0000000000000..083eb72f5fc3d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-prtvt7.dts
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2016 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-prti6q.dtsi"
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/sound/fsl-imx-audmux.h>
+
+/ {
+ model = "Protonic VT7";
+ compatible = "prt,prtvt7", "fsl,imx6dl";
+
+ memory@10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0x20000000>;
+ };
+
+ backlight_lcd: backlight-lcd {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight>;
+ pwms = <&pwm1 0 500000>;
+ brightness-levels = <0 20 81 248 1000>;
+ default-brightness-level = <20>;
+ num-interpolated-steps = <21>;
+ power-supply = <®_bl_12v0>;
+ enable-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ esc {
+ label = "GPIO Key ESC";
+ linux,code = <KEY_ESC>;
+ gpios = <&gpio_pca 0 GPIO_ACTIVE_LOW>;
+ };
+
+ up {
+ label = "GPIO Key UP";
+ linux,code = <KEY_UP>;
+ gpios = <&gpio_pca 1 GPIO_ACTIVE_LOW>;
+ };
+
+ down {
+ label = "GPIO Key DOWN";
+ linux,code = <KEY_DOWN>;
+ gpios = <&gpio_pca 4 GPIO_ACTIVE_LOW>;
+ };
+
+ enter {
+ label = "GPIO Key Enter";
+ linux,code = <KEY_ENTER>;
+ gpios = <&gpio_pca 3 GPIO_ACTIVE_LOW>;
+ };
+
+ cycle {
+ label = "GPIO Key CYCLE";
+ linux,code = <KEY_CYCLEWINDOWS>;
+ gpios = <&gpio_pca 2 GPIO_ACTIVE_LOW>;
+ };
+
+ f1 {
+ label = "GPIO Key F1";
+ linux,code = <KEY_F1>;
+ gpios = <&gpio_pca 14 GPIO_ACTIVE_LOW>;
+ };
+
+ f2 {
+ label = "GPIO Key F2";
+ linux,code = <KEY_F2>;
+ gpios = <&gpio_pca 13 GPIO_ACTIVE_LOW>;
+ };
+
+ f3 {
+ label = "GPIO Key F3";
+ linux,code = <KEY_F3>;
+ gpios = <&gpio_pca 12 GPIO_ACTIVE_LOW>;
+ };
+
+ f4 {
+ label = "GPIO Key F4";
+ linux,code = <KEY_F4>;
+ gpios = <&gpio_pca 11 GPIO_ACTIVE_LOW>;
+ };
+
+ f5 {
+ label = "GPIO Key F5";
+ linux,code = <KEY_F5>;
+ gpios = <&gpio_pca 10 GPIO_ACTIVE_LOW>;
+ };
+
+ f6 {
+ label = "GPIO Key F6";
+ linux,code = <KEY_F6>;
+ gpios = <&gpio_pca 5 GPIO_ACTIVE_LOW>;
+ };
+
+ f7 {
+ label = "GPIO Key F7";
+ linux,code = <KEY_F7>;
+ gpios = <&gpio_pca 6 GPIO_ACTIVE_LOW>;
+ };
+
+ f8 {
+ label = "GPIO Key F8";
+ linux,code = <KEY_F8>;
+ gpios = <&gpio_pca 7 GPIO_ACTIVE_LOW>;
+ };
+
+ f9 {
+ label = "GPIO Key F9";
+ linux,code = <KEY_F9>;
+ gpios = <&gpio_pca 8 GPIO_ACTIVE_LOW>;
+ };
+
+ f10 {
+ label = "GPIO Key F10";
+ linux,code = <KEY_F10>;
+ gpios = <&gpio_pca 9 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-debug0 {
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ reg_bl_12v0: regulator-bl-12v0 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_bl_12v0>;
+ regulator-name = "bl-12v0";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ gpio = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_1v8: regulator-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "prti6q-sgtl5000";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Line", "Line In Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "External Speaker";
+ simple-audio-card,routing =
+ "MIC_IN", "Microphone Jack",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "External Speaker", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <&ssi1>;
+ system-clock-frequency = <0>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&sgtl5000>;
+ bitclock-master;
+ frame-master;
+ };
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>;
+ status = "okay";
+
+ mux_ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN 0
+ IMX_AUDMUX_V2_PTCR_TFSEL(2) 0
+ IMX_AUDMUX_V2_PTCR_TCSEL(2) 0
+ IMX_AUDMUX_V2_PTCR_TFSDIR 0
+ IMX_AUDMUX_V2_PTCR_TCLKDIR IMX_AUDMUX_V2_PDCR_RXDSEL(2)
+ >;
+ };
+
+ mux_pins3 {
+ fsl,audmux-port = <2>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN IMX_AUDMUX_V2_PDCR_RXDSEL(0)
+ 0 IMX_AUDMUX_V2_PDCR_TXRXEN
+ >;
+ };
+};
+
+&can1 {
+ pinctrl-0 = <&pinctrl_can1 &pinctrl_can1phy>;
+};
+
+&clks {
+ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL5_VIDEO_DIV>;
+};
+
+&ecspi2 {
+ cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi2>;
+ status = "okay";
+};
+
+&i2c1 {
+ sgtl5000: codec@a {
+ compatible = "fsl,sgtl5000";
+ reg = <0xa>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_codec>;
+ #sound-dai-cells = <0>;
+ clocks = <&clks 201>;
+ VDDA-supply = <®_3v3>;
+ VDDIO-supply = <®_3v3>;
+ VDDD-supply = <®_1v8>;
+ };
+};
+
+&i2c3 {
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+
+ gpio_pca: gpio@74 {
+ compatible = "nxp,pca9539";
+ reg = <0x74>;
+ interrupts-extended = <&gpio4 5 IRQ_TYPE_LEVEL_LOW>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+};
+
+&ipu1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
+ status = "okay";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&snvs_pwrkey {
+ status = "okay";
+};
+
+&ssi1 {
+ #sound-dai-cells = <0>;
+ fsl,mode = "i2s-slave";
+ status = "okay";
+};
+
+&usbh1 {
+ status = "disabled";
+};
+
+&vpu {
+ status = "disabled";
+};
+
+&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_MCLK__CCM_CLKO1 0x030b0
+ MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x130b0
+ MX6QDL_PAD_CSI0_DAT4__AUD3_TXC 0x130b0
+ MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x110b0
+ MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0
+ >;
+ };
+
+ pinctrl_backlight: backlightgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT7__GPIO4_IO28 0x1b0b0
+ >;
+ };
+
+ pinctrl_can1phy: can1phy {
+ fsl,pins = <
+ /* CAN1_SR */
+ MX6QDL_PAD_KEY_COL3__GPIO4_IO12 0x13070
+ /* CAN1_TERM */
+ MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
+ >;
+ };
+
+ pinctrl_codec: codecgrp {
+ fsl,pins = <
+ /* AUDIO_nRESET */
+ MX6QDL_PAD_CSI0_VSYNC__GPIO5_IO21 0x1f0b0
+ >;
+ };
+
+ pinctrl_ecspi2: ecspi2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1
+ MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1
+ MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1
+ MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x000b1
+ >;
+ };
+
+ pinctrl_ipu1_csi0: ipu1csi0grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x1b0b0
+ MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x1b0b0
+ /* ITU656_nRESET */
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
+ /* ITU656_nPDN */
+ MX6QDL_PAD_CSI0_DATA_EN__GPIO5_IO20 0x1b0b0
+ >;
+ };
+
+ pinctrl_ipu1_disp: ipudisp1grp {
+ fsl,pins = <
+ MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0xb0
+ MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0xb0
+
+ MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0xb0
+ MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0xb0
+ MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0xb0
+ MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0xb0
+ MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0xb0
+ MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0xb0
+ MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0xb0
+ MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0xb0
+
+ MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0xb0
+ MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0xb0
+ MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0xb0
+ MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0xb0
+ MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0xb0
+ MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0xb0
+ MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0xb0
+ MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0xb0
+
+ MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0xb0
+ MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0xb0
+ MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0xb0
+ MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0xb0
+ MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0xb0
+ MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0xb0
+ MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0xb0
+ MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0xb0
+ >;
+ };
+
+ pinctrl_leds: ledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_9__PWM1_OUT 0x1b0b0
+ >;
+ };
+
+ pinctrl_reg_bl_12v0: 12blgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x1b0b0
+ >;
+ };
+
+ pinctrl_tsc: tscgrp {
+
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D20__GPIO3_IO20 0x1b0b0
+ MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
+ >;
+ };
+};
--
2.26.2
^ permalink raw reply related
* [PATCH v8 1/5] ARM: dts: add Protonic PRTI6Q board
From: Oleksij Rempel @ 2020-05-20 15:41 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: Oleksij Rempel, Rob Herring, David Jander, devicetree,
Fabio Estevam, linux-arm-kernel, linux-kernel, NXP Linux Team,
Pengutronix Kernel Team
In-Reply-To: <20200520154116.12909-1-o.rempel@pengutronix.de>
Protonic PRTI6Q is a development board and a base class for different
specific customer application boards based on the i.MX6 family of SoCs,
developed by Protonic Holland.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-prti6q.dts | 541 ++++++++++++++++++++++++++
arch/arm/boot/dts/imx6qdl-prti6q.dtsi | 165 ++++++++
3 files changed, 707 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-prti6q.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-prti6q.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e8dd992013973..206a36a50575e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -538,6 +538,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-pico-nymph.dtb \
imx6q-pico-pi.dtb \
imx6q-pistachio.dtb \
+ imx6q-prti6q.dtb \
imx6q-rex-pro.dtb \
imx6q-sabreauto.dtb \
imx6q-sabrelite.dtb \
diff --git a/arch/arm/boot/dts/imx6q-prti6q.dts b/arch/arm/boot/dts/imx6q-prti6q.dts
new file mode 100644
index 0000000000000..d8ea9a3f415a8
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-prti6q.dts
@@ -0,0 +1,541 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-prti6q.dtsi"
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/sound/fsl-imx-audmux.h>
+
+/ {
+ model = "Protonic PRTI6Q board";
+ compatible = "prt,prti6q", "fsl,imx6q";
+
+ memory@10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0xf0000000>;
+ };
+
+ backlight_lcd: backlight-lcd {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight>;
+ pwms = <&pwm1 0 5000000>;
+ brightness-levels = <0 16 64 255>;
+ num-interpolated-steps = <16>;
+ default-brightness-level = <16>;
+ power-supply = <®_3v3>;
+ enable-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+ };
+
+ can_osc: can-osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-debug0 {
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-debug1 {
+ function = LED_FUNCTION_SD;
+ gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "disk-activity";
+ };
+ };
+
+ panel {
+ compatible = "kyo,tcg121xglp";
+ backlight = <&backlight_lcd>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
+
+ reg_1v8: regulator-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reg_wifi: regulator-wifi {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wifi_npd>;
+ enable-active-high;
+ gpio = <&gpio1 26 GPIO_ACTIVE_HIGH>;
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-name = "regulator-WL12xx";
+ startup-delay-us = <70000>;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "prti6q-sgtl5000";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Line", "Line In Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "External Speaker";
+ simple-audio-card,routing =
+ "MIC_IN", "Microphone Jack",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "External Speaker", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <&ssi1>;
+ system-clock-frequency = <0>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&sgtl5000>;
+ bitclock-master;
+ frame-master;
+ };
+ };
+
+ sound-spdif {
+ compatible = "fsl,imx-audio-spdif";
+ model = "imx-spdif";
+ spdif-controller = <&spdif>;
+ spdif-in;
+ spdif-out;
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>;
+ status = "okay";
+
+ mux_ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN 0
+ IMX_AUDMUX_V2_PTCR_TFSEL(2) 0
+ IMX_AUDMUX_V2_PTCR_TCSEL(2) 0
+ IMX_AUDMUX_V2_PTCR_TFSDIR 0
+ IMX_AUDMUX_V2_PTCR_TCLKDIR IMX_AUDMUX_V2_PDCR_RXDSEL(2)
+ >;
+ };
+
+ mux_pins3 {
+ fsl,audmux-port = <2>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN IMX_AUDMUX_V2_PDCR_RXDSEL(0)
+ 0 IMX_AUDMUX_V2_PDCR_TXRXEN
+ >;
+ };
+};
+
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can2>;
+ status = "okay";
+};
+
+&ecspi1 {
+ cs-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ };
+};
+
+&ecspi2 {
+ cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>, <&gpio4 25 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>;
+ status = "okay";
+
+ can@0 {
+ compatible = "microchip,mcp2515";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can3>;
+ clocks = <&can_osc>;
+ interrupts-extended = <&gpio3 20 IRQ_TYPE_LEVEL_LOW>;
+ spi-max-frequency = <5000000>;
+ };
+
+ adc@1 {
+ compatible = "ti,adc128s052";
+ reg = <1>;
+ spi-max-frequency = <2000000>;
+ vref-supply = <®_3v3>;
+ };
+};
+
+&ecspi3 {
+ cs-gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3>;
+ status = "okay";
+};
+
+&can1 {
+ pinctrl-0 = <&pinctrl_can1>;
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rgmii-id";
+ phy-handle = <&rgmii_phy>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Microchip KSZ9031RNX PHY */
+ rgmii_phy: ethernet-phy@0 {
+ reg = <0>;
+ interrupts-extended = <&gpio1 28 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <300>;
+ };
+ };
+};
+
+&hdmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi>;
+ ddc-i2c-bus = <&i2c2>;
+ status = "okay";
+};
+
+&i2c1 {
+ sgtl5000: audio-codec@a {
+ compatible = "fsl,sgtl5000";
+ reg = <0xa>;
+ #sound-dai-cells = <0>;
+ clocks = <&clks 201>;
+ VDDA-supply = <®_3v3>;
+ VDDIO-supply = <®_3v3>;
+ VDDD-supply = <®_1v8>;
+ };
+};
+
+/* DDC */
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&i2c3 {
+ adc@49 {
+ compatible = "ti,ads1015";
+ reg = <0x49>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* can2_l */
+ channel@4 {
+ reg = <4>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can2_h */
+ channel@5 {
+ reg = <5>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can1_l */
+ channel@6 {
+ reg = <6>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can1_h */
+ channel@7 {
+ reg = <7>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+ };
+};
+
+&pcie {
+ status = "okay";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel@0 {
+ status = "okay";
+
+ port@4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
+
+&sata {
+ status = "okay";
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&spdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spdif>;
+ status = "okay";
+};
+
+&ssi1 {
+ #sound-dai-cells = <0>;
+ fsl,mode = "ac97-slave";
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&uart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>;
+ status = "okay";
+};
+
+&usbotg {
+ pinctrl-0 = <&pinctrl_usbotg &pinctrl_usbotg_id>;
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ non-removable;
+ vmmc-supply = <®_wifi>;
+ cap-power-off-card;
+ keep-power-in-suspend;
+ status = "okay";
+
+ wifi {
+ compatible = "ti,wl1271";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wifi>;
+ interrupts-extended = <&gpio1 30 IRQ_TYPE_LEVEL_HIGH>;
+ ref-clock-frequency = "38400000";
+ tcxo-clock-frequency = "19200000";
+ };
+};
+
+&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_MCLK__CCM_CLKO1 0x030b0
+ MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x130b0
+ MX6QDL_PAD_CSI0_DAT4__AUD3_TXC 0x130b0
+ MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x110b0
+ MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0
+ >;
+ };
+
+ pinctrl_backlight: backlightgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT7__GPIO4_IO28 0x1b0b0
+ >;
+ };
+
+ pinctrl_can2: can2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x80000000
+ MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x80000000
+ >;
+ };
+
+ pinctrl_can3: can3grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D20__GPIO3_IO20 0x1b0b1
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1
+ MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1
+ MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1
+ /* CS */
+ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x000b1
+ >;
+ };
+
+ pinctrl_ecspi2: ecspi2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1
+ MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1
+ MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1
+ MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x000b1
+ >;
+ };
+
+ pinctrl_ecspi2_cs: ecspi2csgrp {
+ fsl,pins = <
+ /* ADC128S022 CS */
+ MX6QDL_PAD_DISP0_DAT4__GPIO4_IO25 0x1b0b1
+ >;
+ };
+
+ pinctrl_ecspi3: ecspi3grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x100b1
+ MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x100b1
+ MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x100b1
+ MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x000b1
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b030
+ MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b030
+ MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b030
+ MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b030
+ MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b030
+ MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b030
+ MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x10030
+ MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x10030
+ MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x10030
+ MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x10030
+ MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x10030
+ MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x10030
+ MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x10030
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x10030
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x10030
+
+ /* Phy reset */
+ MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x1b0b0
+ MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28 0x1b0b1
+ >;
+ };
+
+ pinctrl_hdmi: hdmigrp {
+ fsl,pins = <
+ /* NOTE: DDC is done via I2C2, so DON'T
+ * configure DDC pins for HDMI!
+ */
+ MX6QDL_PAD_EIM_A25__HDMI_TX_CEC_LINE 0x1f8b0
+ >;
+ };
+
+ /* DDC */
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_leds: ledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
+ MX6QDL_PAD_GPIO_9__GPIO1_IO09 0x1b0b0
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT8__PWM1_OUT 0x1b0b0
+ >;
+ };
+
+ pinctrl_spdif: spdifgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_16__SPDIF_IN 0x1b0b0
+ MX6QDL_PAD_GPIO_19__SPDIF_OUT 0x1b0b0
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D26__UART2_RX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D27__UART2_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D28__UART2_DTE_CTS_B 0x1b0b1
+ MX6QDL_PAD_EIM_D29__UART2_DTE_RTS_B 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL1__UART5_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW1__UART5_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg_id: usbotgidgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID 0x1f058
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170b9
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100b9
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170b9
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170b9
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170b9
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x170b9
+ >;
+ };
+
+ pinctrl_wifi: wifigrp {
+ fsl,pins = <
+ /* WL12xx IRQ */
+ MX6QDL_PAD_ENET_TXD0__GPIO1_IO30 0x10880
+ >;
+ };
+
+ pinctrl_wifi_npd: wifinpd {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_RXD1__GPIO1_IO26 0x1b8b0
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6qdl-prti6q.dtsi b/arch/arm/boot/dts/imx6qdl-prti6q.dtsi
new file mode 100644
index 0000000000000..b9ac70b9a4513
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-prti6q.dtsi
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+ chosen {
+ stdout-path = &uart4;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_usb_h1_vbus: regulator-h1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "h1-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ reg_usb_otg_vbus: regulator-otg-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "otg-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+&can1 {
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+
+ temperature-sensor@70 {
+ compatible = "ti,tmp103";
+ reg = <0x70>;
+ };
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
+&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
+ phy_type = "utmi";
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ phy_type = "utmi";
+ dr_mode = "host";
+ disable-over-current;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_can1: can1grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x80000000
+ MX6QDL_PAD_KEY_COL2__FLEXCAN1_TX 0x80000000
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001f8b1
+ MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001f8b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x170f9
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x100f9
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170f9
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170f9
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170f9
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170f9
+ MX6QDL_PAD_GPIO_1__GPIO1_IO01 0x1b0b0
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17099
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10099
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17099
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17099
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17099
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17099
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17099
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17099
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17099
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17099
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__USB_OTG_OC 0x1b0b0
+ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0
+ >;
+ };
+};
--
2.26.2
^ permalink raw reply related
* [PATCH v8 0/5] mainline Protonic boards
From: Oleksij Rempel @ 2020-05-20 15:41 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: Oleksij Rempel, devicetree, Fabio Estevam, linux-arm-kernel,
linux-kernel, NXP Linux Team, Pengutronix Kernel Team
changes v8:
- resend correct changes
changes v7:
- VT7: reorder node alphabetically
- VT7: rename "reg_12v_bl: regulator-bl-12v" to "reg_bl_12v0: regulator-bl-12v0"
- VT7: remove panel and TS nodes. This drivers are currently not
mainline.
- prti6q.dtsi: move reg_1v8 to prti6q.dts
- prti6q.dtsi: remove pinctrl from the can1 node. It is done on almost
every board file.
changes v6:
- move fsl.yaml changes to separate patch
- remove partitions, they are provided by the bootloader
- update flash compatible
- rename can3 to can
- fix fsl,mode
- fix interrupt in the wlan node on PRTI6Q
changes v5:
- PRTI6Q: remove status from the pwm-backlight node
- drop the vendor-prefixes patch, it is already taken by Rob
- add Reviewed-by: Rob Herring <robh@kernel.org>
changes v4:
- VT7: fix typo
changes v3:
- move compatible to the start of node
- move status to the end
- use generic names in compatible
- refactor dts/dtsi
- use alphabet order for pinctrl and phandels
- remove unused or currently not supported nodes
changes v2:
- squash PRTI6Q patches
Oleksij Rempel (5):
ARM: dts: add Protonic PRTI6Q board
ARM: dts: add Protonic WD2 board
ARM: dts: add Protonic VT7 board
ARM: dts: add Protonic RVT board
dt-bindings: arm: fsl: add different Protonic boards
.../devicetree/bindings/arm/fsl.yaml | 4 +
arch/arm/boot/dts/Makefile | 4 +
arch/arm/boot/dts/imx6dl-prtrvt.dts | 182 ++++++
arch/arm/boot/dts/imx6dl-prtvt7.dts | 411 +++++++++++++
arch/arm/boot/dts/imx6q-prti6q.dts | 541 ++++++++++++++++++
arch/arm/boot/dts/imx6q-prtwd2.dts | 188 ++++++
arch/arm/boot/dts/imx6qdl-prti6q.dtsi | 165 ++++++
7 files changed, 1495 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-prtrvt.dts
create mode 100644 arch/arm/boot/dts/imx6dl-prtvt7.dts
create mode 100644 arch/arm/boot/dts/imx6q-prti6q.dts
create mode 100644 arch/arm/boot/dts/imx6q-prtwd2.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-prti6q.dtsi
--
2.26.2
^ permalink raw reply
* [PATCH v8 2/5] ARM: dts: add Protonic WD2 board
From: Oleksij Rempel @ 2020-05-20 15:41 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: Oleksij Rempel, Rob Herring, David Jander, devicetree,
Fabio Estevam, linux-arm-kernel, linux-kernel, NXP Linux Team,
Pengutronix Kernel Team
In-Reply-To: <20200520154116.12909-1-o.rempel@pengutronix.de>
Add support for the Protonic WD2 board, which is an internal development
platform for low-cost agricultural Virtual Terminals based on COTS tablets
and web applications.
It inherits from the PRTI6Q base class.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-prtwd2.dts | 188 +++++++++++++++++++++++++++++
2 files changed, 189 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-prtwd2.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 206a36a50575e..8ce744f1cbfc9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -539,6 +539,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-pico-pi.dtb \
imx6q-pistachio.dtb \
imx6q-prti6q.dtb \
+ imx6q-prtwd2.dtb \
imx6q-rex-pro.dtb \
imx6q-sabreauto.dtb \
imx6q-sabrelite.dtb \
diff --git a/arch/arm/boot/dts/imx6q-prtwd2.dts b/arch/arm/boot/dts/imx6q-prtwd2.dts
new file mode 100644
index 0000000000000..fd9f457a273e2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-prtwd2.dts
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2018 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-prti6q.dtsi"
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "Protonic WD2 board";
+ compatible = "prt,prtwd2", "fsl,imx6q";
+
+ memory@10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0x20000000>;
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x20000000>;
+ };
+
+ usdhc2_wifi_pwrseq: usdhc2_wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wifi_npd>;
+ reset-gpios = <&gpio6 10 GPIO_ACTIVE_LOW>;
+ };
+
+ /* PRTWD2 rev 1 bitbang I2C for Ethernet Switch */
+ i2c@4 {
+ compatible = "i2c-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ sda-gpios = <&gpio1 22 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ scl-gpios = <&gpio1 31 GPIO_ACTIVE_HIGH>;
+ i2c-gpio,delay-us = <20>; /* ~10 kHz */
+ i2c-gpio,scl-output-only;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+};
+
+&can1 {
+ pinctrl-0 = <&pinctrl_can1 &pinctrl_can1phy>;
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rmii";
+ clocks = <&clks IMX6QDL_CLK_ENET>,
+ <&clks IMX6QDL_CLK_ENET>;
+ clock-names = "ipg", "ahb";
+ status = "okay";
+
+ fixed-link {
+ speed = <100>;
+ pause;
+ full-duplex;
+ };
+};
+
+&i2c3 {
+ adc@49 {
+ compatible = "ti,ads1015";
+ reg = <0x49>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* V in */
+ channel@4 {
+ reg = <4>;
+ ti,gain = <1>;
+ ti,datarate = <3>;
+ };
+
+ /* I charge */
+ channel@5 {
+ reg = <5>;
+ ti,gain = <1>;
+ ti,datarate = <3>;
+ };
+
+ /* V bus */
+ channel@6 {
+ reg = <6>;
+ ti,gain = <1>;
+ ti,datarate = <3>;
+ };
+
+ /* nc */
+ channel@7 {
+ reg = <7>;
+ ti,gain = <1>;
+ ti,datarate = <3>;
+ };
+ };
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ non-removable;
+ no-1-8-v;
+ non-removable;
+ mmc-pwrseq = <&usdhc2_wifi_pwrseq>;
+ pm-ignore-notify;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ wifi@1 {
+ compatible = "brcm,bcm4329-fmac";
+ reg = <1>;
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_eth_chg>;
+
+ pinctrl_can1phy: can1phy {
+ fsl,pins = <
+ /* CAN1_SR */
+ MX6QDL_PAD_KEY_COL3__GPIO4_IO12 0x13070
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ /* MX6QDL_ENET_PINGRP4 */
+ MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER 0x130b0
+ MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
+ MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
+
+ MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x1b0b0
+ /* Phy reset */
+ MX6QDL_PAD_CSI0_DAT4__GPIO5_IO22 0x1b0b0
+ /* nINTRP */
+ MX6QDL_PAD_CSI0_DAT5__GPIO5_IO23 0x1b0b0
+
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x10030
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x10030
+ >;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_MDIO__GPIO1_IO22 0x1f8b0
+ MX6QDL_PAD_ENET_MDC__GPIO1_IO31 0x1f8b0
+ >;
+ };
+
+ pinctrl_usb_eth_chg: usbethchggrp {
+ fsl,pins = <
+ /* USB charging control */
+ MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x130b0
+ MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x130b0
+ MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x130b0
+ MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x130b0
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170b9
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100b9
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170b9
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170b9
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170b9
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x170b9
+ >;
+ };
+
+ pinctrl_wifi_npd: wifinpd {
+ fsl,pins = <
+ /* WL_REG_ON */
+ MX6QDL_PAD_NANDF_RB0__GPIO6_IO10 0x13069
+ >;
+ };
+};
--
2.26.2
^ permalink raw reply related
* [PATCH v8 4/5] ARM: dts: add Protonic RVT board
From: Oleksij Rempel @ 2020-05-20 15:41 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: Oleksij Rempel, Rob Herring, David Jander, devicetree,
Fabio Estevam, linux-arm-kernel, linux-kernel, NXP Linux Team,
Pengutronix Kernel Team
In-Reply-To: <20200520154116.12909-1-o.rempel@pengutronix.de>
Protonic RVT is an internal development platform for a wireless ISObus
Virtual Terminal based on COTS tablets, and the predecessor of the WD2
platform.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-prtrvt.dts | 182 ++++++++++++++++++++++++++++
2 files changed, 183 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-prtrvt.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 66ee89e7929f9..89842a034e4ba 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -450,6 +450,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+ imx6dl-prtrvt.dtb \
imx6dl-prtvt7.dtb \
imx6dl-rex-basic.dtb \
imx6dl-riotboard.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-prtrvt.dts b/arch/arm/boot/dts/imx6dl-prtrvt.dts
new file mode 100644
index 0000000000000..b7721e52a463a
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-prtrvt.dts
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-prti6q.dtsi"
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "Protonic RVT board";
+ compatible = "prt,prtrvt", "fsl,imx6dl";
+
+ memory@10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0x10000000>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-debug0 {
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
+
+&can1 {
+ pinctrl-0 = <&pinctrl_can1 &pinctrl_can1phy>;
+};
+
+&ecspi1 {
+ cs-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
+
+&ecspi3 {
+ cs-gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3>;
+ status = "okay";
+
+ nfc@0 {
+ compatible = "ti,trf7970a";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_nfc>;
+ spi-max-frequency = <2000000>;
+ interrupts-extended = <&gpio5 14 IRQ_TYPE_LEVEL_LOW>;
+ ti,enable-gpios = <&gpio5 12 GPIO_ACTIVE_LOW>,
+ <&gpio5 11 GPIO_ACTIVE_LOW>;
+ vin-supply = <®_3v3>;
+ vin-voltage-override = <3100000>;
+ autosuspend-delay = <30000>;
+ irq-status-read-quirk;
+ en2-rf-quirk;
+ t5t-rmb-extra-byte-quirk;
+ status = "okay";
+ };
+};
+
+&i2c3 {
+ adc@49 {
+ compatible = "ti,ads1015";
+ reg = <0x49>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* nc */
+ channel@4 {
+ reg = <4>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* nc */
+ channel@5 {
+ reg = <5>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can1_l */
+ channel@6 {
+ reg = <6>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can1_h */
+ channel@7 {
+ reg = <7>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+ };
+
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&pcie {
+ status = "okay";
+};
+
+&usbh1 {
+ status = "disabled";
+};
+
+&vpu {
+ status = "disabled";
+};
+
+&iomuxc {
+ pinctrl_can1phy: can1phy {
+ fsl,pins = <
+ /* CAN1_SR */
+ MX6QDL_PAD_KEY_COL3__GPIO4_IO12 0x13070
+ /* CAN1_TERM */
+ MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1
+ MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1
+ MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1
+ /* CS */
+ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x000b1
+ >;
+ };
+
+ pinctrl_ecspi3: ecspi3grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x100b1
+ MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x100b1
+ MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x100b1
+ MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x000b1
+ >;
+ };
+
+ pinctrl_leds: ledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
+ >;
+ };
+
+ pinctrl_nfc: nfcgrp {
+ fsl,pins = <
+ /* NFC_ASK_OOK */
+ MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09 0x100b1
+ /* NFC_PWR_EN */
+ MX6QDL_PAD_DISP0_DAT16__GPIO5_IO10 0x100b1
+ /* NFC_EN2 */
+ MX6QDL_PAD_DISP0_DAT17__GPIO5_IO11 0x100b1
+ /* NFC_EN */
+ MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12 0x100b1
+ /* NFC_MOD */
+ MX6QDL_PAD_DISP0_DAT19__GPIO5_IO13 0x100b1
+ /* NFC_IRQ */
+ MX6QDL_PAD_DISP0_DAT20__GPIO5_IO14 0x100b1
+ >;
+ };
+};
--
2.26.2
^ permalink raw reply related
* [PATCH v8 5/5] dt-bindings: arm: fsl: add different Protonic boards
From: Oleksij Rempel @ 2020-05-20 15:41 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: Oleksij Rempel, devicetree, Fabio Estevam, linux-arm-kernel,
linux-kernel, NXP Linux Team, Pengutronix Kernel Team
In-Reply-To: <20200520154116.12909-1-o.rempel@pengutronix.de>
Add Protonic PRTI6Q, WD2, RVT, VT7 boards.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index cd3fbe7e39487..a1657505b3357 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -119,6 +119,8 @@ properties:
- fsl,imx6q-sabreauto
- fsl,imx6q-sabrelite
- fsl,imx6q-sabresd
+ - prt,prti6q # Protonic PRTI6Q board
+ - prt,prtwd2 # Protonic WD2 board
- technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf
- technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit
- technexion,imx6q-pico-nymph # TechNexion i.MX6Q Pico-Nymph
@@ -170,6 +172,8 @@ properties:
- emtrion,emcon-mx6-avari # emCON-MX6S or emCON-MX6DL SoM on Avari Base
- fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board
- fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board
+ - prt,prtrvt # Protonic RVT board
+ - prt,prtvt7 # Protonic VT7 board
- technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf
- technexion,imx6dl-pico-hobbit # TechNexion i.MX6DL Pico-Hobbit
- technexion,imx6dl-pico-nymph # TechNexion i.MX6DL Pico-Nymph
--
2.26.2
^ permalink raw reply related
* Re: [TEGRA194_CPUFREQ Patch 1/3] firmware: tegra: adding function to get BPMP data
From: Thierry Reding @ 2020-05-20 15:38 UTC (permalink / raw)
To: Rob Herring
Cc: Viresh Kumar, Rafael J. Wysocki, Mikko Perttunen, Sumit Gupta,
Catalin Marinas, Will Deacon, Jon Hunter, Timo Alho,
open list:THERMAL, linux-tegra,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel@vger.kernel.org, bbasu, Mikko Perttunen, devicetree
In-Reply-To: <CAL_Jsq+rMYAZ=ub0U7qdHSsWgbQugodhvigFCxrFm49HwrCmAQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7097 bytes --]
On Wed, May 20, 2020 at 08:43:03AM -0600, Rob Herring wrote:
> On Tue, Apr 7, 2020 at 4:05 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Wed, Dec 04, 2019 at 03:21:38PM +0530, Viresh Kumar wrote:
> > > On 04-12-19, 10:33, Thierry Reding wrote:
> > > > Yeah, the code that registers this device is in drivers/base/cpu.c in
> > > > register_cpu(). It even retrieves the device tree node for the CPU from
> > > > device tree and stores it in cpu->dev.of_node, so we should be able to
> > > > just pass &cpu->dev to tegra_bpmp_get() in order to retrieve a reference
> > > > to the BPMP.
> > > >
> > > > That said, I'm wondering if perhaps we could just add a compatible
> > > > string to the /cpus node for cases like this where we don't have an
> > > > actual device representing the CPU complex. There are a number of CPU
> > > > frequency drivers that register dummy devices just so that they have
> > > > something to bind a driver to.
> > > >
> > > > If we allow the /cpus node to represent the CPU complex (if no other
> > > > "device" does that yet), we can add a compatible string and have the
> > > > cpufreq driver match on that.
> > > >
> > > > Of course this would be slightly difficult to retrofit into existing
> > > > drivers because they'd need to remain backwards compatible with existing
> > > > device trees. But it would allow future drivers to do this a little more
> > > > elegantly. For some SoCs this may not matter, but especially once you
> > > > start depending on additional resources this would come in handy.
> > > >
> > > > Adding Rob and the device tree mailing list for feedback on this idea.
> > >
> > > Took some time to find this thread, but something around this was
> > > suggested by Rafael earlier.
> > >
> > > https://lore.kernel.org/lkml/8139001.Q4eV8YG1Il@vostro.rjw.lan/
> >
> > I gave this a try and came up with the following:
> >
> > --- >8 ---
> > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > index f4ede86e32b4..e4462f95f0b3 100644
> > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > @@ -1764,6 +1764,9 @@ bpmp_thermal: thermal {
> > };
> >
> > cpus {
> > + compatible = "nvidia,tegra194-ccplex";
> > + nvidia,bpmp = <&bpmp>;
>
> Is there more than 1 bpmp? If not you don't need this. Just lookup the
> node by compatible.
There no SoCs currently than need to differentiate between multiple
BPMPs, so yes, it would be possible to look up the node by compatible.
But we also used to assume that PCs would only ever come with a single
GPU or audio card and that's always caused a lot of work to clean up
when it turned out to no longer be true.
Also, we already have a couple of devices referencing the BPMP by
phandle like this, so having this in a CCPLEX node would keep things
consistent.
One of the reasons why we initially did it this way was also so that we
could make the dependencies explicit within device tree. If we look up
by compatible string, then the driver is the only one with the knowledge
about where to get at it. If we have the explicit reference we at least
have a chance of determining the dependency by just looking at the
device tree.
> > +
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > --- >8 ---
> >
> > Now I can do something rougly like this, although I have a more complete
> > patch locally that also gets rid of all the global variables because we
> > now actually have a struct platform_device that we can anchor everything
> > at:
> >
> > --- >8 ---
> > static const struct of_device_id tegra194_cpufreq_of_match[] = {
> > { .compatible = "nvidia,tegra194-ccplex", },
> > { /* sentinel */ }
> > };
> > MODULE_DEVICE_TABLE(of, tegra194_cpufreq_of_match);
> >
> > static struct platform_driver tegra194_ccplex_driver = {
> > .driver = {
> > .name = "tegra194-cpufreq",
> > .of_match_table = tegra194_cpufreq_of_match,
> > },
> > .probe = tegra194_cpufreq_probe,
> > .remove = tegra194_cpufreq_remove,
> > };
> > module_platform_driver(tegra194_ccplex_driver);
> > --- >8 ---
> >
> > I don't think that's exactly what Rafael (Cc'ed) had in mind, since the
> > above thread seems to have mostly talked about binding a driver to each
> > individual CPU.
> >
> > But this seems a lot better than having to instantiate a device from
> > scratch just so that a driver can bind to it and it allows additional
> > properties to be associated with the CCPLEX device.
>
> What additional properties? A continual stream of properties added 1
> by 1 would negatively affect my opinion of this.
I don't expect there would be many. I think there's an earlier
generation of Tegra that requires a regulator and I can imagine that's
pretty common. But other than that I would expect this to be a fairly
narrow set of properties.
> > Rob, any thoughts on this from a device tree point of view? The /cpus
> > bindings don't mention the compatible property, but there doesn't seem
> > to be anything in the bindings that would prohibit its use.
>
> What happens when you have more than one cpu related driver in
> addition to cpufreq? You may still have to end up creating child
> platform devices and then gained very little.
That's only if you absolutely want to stick with the "one driver per
subsystem" model. I personally think that's completely obsolete these
days. If you have a CPU complex device that can do both CPU frequency
scaling and put the CPU into idle states, for example, then there is
really no reason to artificially split that into two separate drivers
just to match the subsystems that we have.
Most subsystems that I've come across work just fine if a single driver
registers with multiple subsystems.
I also know that some people like it better when things are nicely split
up into multiple drivers. But I really don't see how that simplifies
things. In fact in my opinion that makes things only more complicated
because you have additional boilerplate and then you need to be extra
careful about how these different drivers are ordered, and you need to
take extra precautions when sharing things like clocks and register
regions.
> You could solve this without DT changes. You can bind on node names.
> The driver probe can then check the parent compatible and return if
> not matching. I'm not sure if you could get module auto loading to
> work in that case. It would have to be based on the root compatible
> (rather than the driver match table) and be able to load multiple
> matching modules.
That sounds like it would get very complicated for something this
simple. Having a compatible string in /cpus seemed like the most logical
option because it would basically just work out of the box and the same
way we're used to from other devices.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Andrew Lunn @ 2020-05-20 15:36 UTC (permalink / raw)
To: Dan Murphy
Cc: f.fainelli, hkallweit1, davem, netdev, linux-kernel, devicetree
In-Reply-To: <770e42bb-a5d7-fb3e-3fc1-b6f97a9aeb83@ti.com>
> > Hi Dan
> >
> > Having it required with PHY_INTERFACE_MODE_RGMII_ID or
> > PHY_INTERFACE_MODE_RGMII_RXID is pretty unusual. Normally these
> > properties are used to fine tune the delay, if the default of 2ns does
> > not work.
>
> Also if the MAC phy-mode is configured with RGMII-ID and no internal delay
> values defined wouldn't that be counter intuitive?
Most PHYs don't allow the delay to be fine tuned. You just pass for
example PHY_INTERFACE_MODE_RGMII_ID to the PHY driver and it enables a
2ns delay. That is what people expect, and is documented.
Being able to tune the delay is an optional extra, which some PHYs
support, but that is always above and beyond
PHY_INTERFACE_MODE_RGMII_ID.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Dan Murphy @ 2020-05-20 15:30 UTC (permalink / raw)
To: Andrew Lunn
Cc: f.fainelli, hkallweit1, davem, netdev, linux-kernel, devicetree
In-Reply-To: <770e42bb-a5d7-fb3e-3fc1-b6f97a9aeb83@ti.com>
Andrew
On 5/20/20 10:28 AM, Dan Murphy wrote:
> Andrew
>
> On 5/20/20 8:56 AM, Andrew Lunn wrote:
>> On Wed, May 20, 2020 at 07:18:34AM -0500, Dan Murphy wrote:
>>> Add the internal delay values into the header and update the binding
>>> with the internal delay properties.
>>>
>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>> ---
>>> .../devicetree/bindings/net/ti,dp83869.yaml | 16 ++++++++++++++++
>>> include/dt-bindings/net/ti-dp83869.h | 18
>>> ++++++++++++++++++
>>> 2 files changed, 34 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml
>>> b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
>>> index 5b69ef03bbf7..344015ab9081 100644
>>> --- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml
>>> +++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
>>> @@ -64,6 +64,20 @@ properties:
>>> Operational mode for the PHY. If this is not set then the
>>> operational
>>> mode is set by the straps. see dt-bindings/net/ti-dp83869.h
>>> for values
>>> + ti,rx-internal-delay:
>>> + $ref: /schemas/types.yaml#definitions/uint32
>>> + description: |
>>> + RGMII Receive Clock Delay - see dt-bindings/net/ti-dp83869.h
>>> + for applicable values. Required only if interface type is
>>> + PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_RXID.
>> Hi Dan
>>
>> Having it required with PHY_INTERFACE_MODE_RGMII_ID or
>> PHY_INTERFACE_MODE_RGMII_RXID is pretty unusual. Normally these
>> properties are used to fine tune the delay, if the default of 2ns does
>> not work.
>
> Also if the MAC phy-mode is configured with RGMII-ID and no internal
> delay values defined wouldn't that be counter intuitive?
>
> The driver will error out if the RGMII-ID is used and there was no
> internal delay defined for either rx or tx making either one required.
>
> The MAC node needs to indicate to use the internal delay for RGMII
> other wise the driver should ignore the internal delay programming as
> these internal delays are not applicable to SGMII or MII modes. The
> RGMII mode can be used if the default 2ns delay is acceptable.
>
> Thus why we are documenting in the binding when the internal delay is
> required as putting these under "required" is not correct.
>
> Dan
>
This is also the same for the DP83867 PHY as that PHY and the 83869 have
a few identical features like internal delay, WoL and downshifting.
Dan
>>
>> Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Dan Murphy @ 2020-05-20 15:28 UTC (permalink / raw)
To: Andrew Lunn
Cc: f.fainelli, hkallweit1, davem, netdev, linux-kernel, devicetree
In-Reply-To: <20200520135624.GC652285@lunn.ch>
Andrew
On 5/20/20 8:56 AM, Andrew Lunn wrote:
> On Wed, May 20, 2020 at 07:18:34AM -0500, Dan Murphy wrote:
>> Add the internal delay values into the header and update the binding
>> with the internal delay properties.
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>> .../devicetree/bindings/net/ti,dp83869.yaml | 16 ++++++++++++++++
>> include/dt-bindings/net/ti-dp83869.h | 18 ++++++++++++++++++
>> 2 files changed, 34 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
>> index 5b69ef03bbf7..344015ab9081 100644
>> --- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml
>> +++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
>> @@ -64,6 +64,20 @@ properties:
>> Operational mode for the PHY. If this is not set then the operational
>> mode is set by the straps. see dt-bindings/net/ti-dp83869.h for values
>>
>> + ti,rx-internal-delay:
>> + $ref: /schemas/types.yaml#definitions/uint32
>> + description: |
>> + RGMII Receive Clock Delay - see dt-bindings/net/ti-dp83869.h
>> + for applicable values. Required only if interface type is
>> + PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_RXID.
> Hi Dan
>
> Having it required with PHY_INTERFACE_MODE_RGMII_ID or
> PHY_INTERFACE_MODE_RGMII_RXID is pretty unusual. Normally these
> properties are used to fine tune the delay, if the default of 2ns does
> not work.
Also if the MAC phy-mode is configured with RGMII-ID and no internal
delay values defined wouldn't that be counter intuitive?
The driver will error out if the RGMII-ID is used and there was no
internal delay defined for either rx or tx making either one required.
The MAC node needs to indicate to use the internal delay for RGMII other
wise the driver should ignore the internal delay programming as these
internal delays are not applicable to SGMII or MII modes. The RGMII
mode can be used if the default 2ns delay is acceptable.
Thus why we are documenting in the binding when the internal delay is
required as putting these under "required" is not correct.
Dan
>
> Andrew
^ permalink raw reply
* Re: [PATCH V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier for userspace
From: Rob Herring @ 2020-05-20 15:23 UTC (permalink / raw)
To: Will Deacon
Cc: Joakim Zhang, John Garry, Mark Rutland, Shawn Guo, NXP Linux Team,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, linux-kernel@vger.kernel.org
In-Reply-To: <20200520073304.GA23534@willie-the-truck>
On Wed, May 20, 2020 at 1:33 AM Will Deacon <will@kernel.org> wrote:
>
> On Tue, May 19, 2020 at 12:51:25PM -0600, Rob Herring wrote:
> > On Tue, May 12, 2020 at 03:31:13PM +0800, Joakim Zhang wrote:
> > > +static ssize_t ddr_perf_identifier_show(struct device *dev,
> > > + struct device_attribute *attr,
> > > + char *page)
> > > +{
> > > + struct ddr_pmu *pmu = dev_get_drvdata(dev);
> > > +
> > > + return sprintf(page, "%s\n", pmu->devtype_data->identifier);
> >
> > Why do we need yet another way to identify the SoC from userspace?
>
> I also really dislike this. What's the preferred way to identify the SoC
> from userspace?
/proc/cpuinfo? ;)
For an non-firmware specific case, I'd say soc_device should be. I'd
guess ACPI systems don't use it and for them it's dmidecode typically.
The other problem I have with soc_device is it is optional.
> It's needed so that the perf userspace tool can describe
> perf events that are supported for the PMU, as this isn't probe-able
> directly from the hardware. We have the same issue with the SMMUv3 PMCG [1],
> and so we need to solve the problem for both DT and ACPI.
>
> Will
>
> [1] https://lore.kernel.org/r/1587120634-19666-1-git-send-email-john.garry@huawei.com
At a minimum, it seems like 'identifier' should be moved into the perf
core if that's an attr we want to keep.
Rob
^ permalink raw reply
* Re: [PATCH v7 0/5] mainline Protonic boards
From: Oleksij Rempel @ 2020-05-20 15:19 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: devicetree, Fabio Estevam, linux-arm-kernel, linux-kernel,
NXP Linux Team, Pengutronix Kernel Team
In-Reply-To: <20200520092937.15797-1-o.rempel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2638 bytes --]
Please ignore this version, i used wrong commit hash to format-patch.
On Wed, May 20, 2020 at 11:29:32AM +0200, Oleksij Rempel wrote:
> changes v7:
> - VT7: reorder node alphabetically
> - VT7: rename "reg_12v_bl: regulator-bl-12v" to "reg_bl_12v0: regulator-bl-12v0"
> - VT7: remove panel and TS nodes. This drivers are currently not
> mainline.
> - prti6q.dtsi: move reg_1v8 to prti6q.dts
> - prti6q.dtsi: remove pinctrl from the can1 node. It is done on almost
> every board file.
>
> changes v6:
> - move fsl.yaml changes to separate patch
> - remove partitions, they are provided by the bootloader
> - update flash compatible
> - rename can3 to can
> - fix fsl,mode
> - fix interrupt in the wlan node on PRTI6Q
>
> changes v5:
> - PRTI6Q: remove status from the pwm-backlight node
> - drop the vendor-prefixes patch, it is already taken by Rob
> - add Reviewed-by: Rob Herring <robh@kernel.org>
>
> changes v4:
> - VT7: fix typo
>
> changes v3:
> - move compatible to the start of node
> - move status to the end
> - use generic names in compatible
> - refactor dts/dtsi
> - use alphabet order for pinctrl and phandels
> - remove unused or currently not supported nodes
>
> changes v2:
> - squash PRTI6Q patches
>
> Oleksij Rempel (5):
> ARM: dts: add Protonic PRTI6Q board
> ARM: dts: add Protonic WD2 board
> ARM: dts: add Protonic VT7 board
> ARM: dts: add Protonic RVT board
> dt-bindings: arm: fsl: add different Protonic boards
>
> .../devicetree/bindings/arm/fsl.yaml | 4 +
> arch/arm/boot/dts/Makefile | 4 +
> arch/arm/boot/dts/imx6dl-prtrvt.dts | 182 ++++++
> arch/arm/boot/dts/imx6dl-prtvt7.dts | 472 ++++++++++++++++
> arch/arm/boot/dts/imx6q-prti6q.dts | 529 ++++++++++++++++++
> arch/arm/boot/dts/imx6q-prtwd2.dts | 188 +++++++
> arch/arm/boot/dts/imx6qdl-prti6q.dtsi | 174 ++++++
> 7 files changed, 1553 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-prtrvt.dts
> create mode 100644 arch/arm/boot/dts/imx6dl-prtvt7.dts
> create mode 100644 arch/arm/boot/dts/imx6q-prti6q.dts
> create mode 100644 arch/arm/boot/dts/imx6q-prtwd2.dts
> create mode 100644 arch/arm/boot/dts/imx6qdl-prti6q.dtsi
>
> --
> 2.26.2
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 2/2] arm64: tegra: Make the RTC a wakeup source on Jetson Nano and TX1
From: Jon Hunter @ 2020-05-20 15:13 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter; +Cc: devicetree, linux-tegra
In-Reply-To: <20200520151318.15493-1-jonathanh@nvidia.com>
The RTC found on the MAX77620 PMIC can be used as a wakeup source on
Jetson Nano and TX1, which is useful to wake the system from suspend
at a given time.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi | 3 ++-
arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi b/arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi
index f87d2437d11c..cc6ed45a2b48 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi
@@ -38,7 +38,8 @@
pmic: pmic@3c {
compatible = "maxim,max77620";
reg = <0x3c>;
- interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&tegra_pmc>;
+ interrupts = <51 IRQ_TYPE_LEVEL_LOW>;
#interrupt-cells = <2>;
interrupt-controller;
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
index 374ce58b2b38..9bc52fdb393c 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
@@ -149,7 +149,8 @@
pmic: pmic@3c {
compatible = "maxim,max77620";
reg = <0x3c>;
- interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&tegra_pmc>;
+ interrupts = <51 IRQ_TYPE_LEVEL_LOW>;
#interrupt-cells = <2>;
interrupt-controller;
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] soc/tegra: pmc: Enable PMIC wake event on Tegra210
From: Jon Hunter @ 2020-05-20 15:13 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter; +Cc: devicetree, linux-tegra
The PMIC wake event can be used to bring the system out of suspend based
on certain events happening on the PMIC (such as an RTC alarm).
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
drivers/soc/tegra/pmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 8169737c3252..42cf37a0556b 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -3063,6 +3063,7 @@ static const struct pinctrl_pin_desc tegra210_pin_descs[] = {
static const struct tegra_wake_event tegra210_wake_events[] = {
TEGRA_WAKE_IRQ("rtc", 16, 2),
+ TEGRA_WAKE_IRQ("pmu", 51, 86),
};
static const struct tegra_pmc_soc tegra210_pmc_soc = {
--
2.17.1
^ permalink raw reply related
* Re: [PATCH V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier for userspace
From: Rob Herring @ 2020-05-20 15:10 UTC (permalink / raw)
To: Joakim Zhang
Cc: john.garry@huawei.com, will@kernel.org, mark.rutland@arm.com,
shawnguo@kernel.org, dl-linux-imx,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DB8PR04MB6795A3C57F2B02632D591183E6B60@DB8PR04MB6795.eurprd04.prod.outlook.com>
On Tue, May 19, 2020 at 8:56 PM Joakim Zhang <qiangqing.zhang@nxp.com> wrote:
>
>
> > -----Original Message-----
> > From: Rob Herring <robh@kernel.org>
> > Sent: 2020年5月20日 2:51
> > To: Joakim Zhang <qiangqing.zhang@nxp.com>
> > Cc: john.garry@huawei.com; will@kernel.org; mark.rutland@arm.com;
> > shawnguo@kernel.org; dl-linux-imx <linux-imx@nxp.com>;
> > linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier
> > for userspace
> >
> > On Tue, May 12, 2020 at 03:31:13PM +0800, Joakim Zhang wrote:
> > > The DDR Perf for i.MX8 is a system PMU whose axi id would different
> > > from SoC to SoC. Need expose system PMU identifier for userspace which
> > > refer to /sys/bus/event_source/devices/<PMU DEVICE>/identifier.
> >
> > Why not just expose the AXI ID if that's what's different?
>
> Hi Rob,
>
> Each master has their own AXI ID, such as USB, GPU, VPU etc, it is various from different SoCs. We want to add system PMU support in perf tool, so we want to expose something from perf driver to identify each SoC.
> When we know which SoC it is, we can get each master AXI ID. If this patch can be accepted, /sys/bus/event_source/devices/<PMU DEVICE>/identifier could be a common interface for all system PMUs.
>
> I will change to add a property to identify SoC, to see if it is better. Thanks.
Isn't that what you have already with this patch? My point is you can
already read /proc/device-tree/compatible, read the PMU compatible, or
have an SoC device which exposes SoC info.
Rob
^ permalink raw reply
* Re: [PATCH v3 1/2] arm64: dts: add qe node to ls1043ardb
From: Shawn Guo @ 2020-05-20 15:01 UTC (permalink / raw)
To: Qiang Zhao; +Cc: leoyang.li, devicetree, linux-kernel
In-Reply-To: <20200520040221.10536-1-qiang.zhao@nxp.com>
On Wed, May 20, 2020 at 12:02:20PM +0800, Qiang Zhao wrote:
> From: Zhao Qiang <qiang.zhao@nxp.com>
>
> Add qe node to fsl-ls1043a.dtsi and fsl-ls1043a-rdb.dts
>
> Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
Applied both, thanks.
^ permalink raw reply
* Re: [PATCH 01/12] OPP: Allow required-opps even if the device doesn't have power-domains
From: Matthias Brugger @ 2020-05-20 14:54 UTC (permalink / raw)
To: Andrew-sh.Cheng, MyungJoo Ham, Kyungmin Park, Chanwoo Choi,
Rob Herring, Mark Rutland, Rafael J . Wysocki, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown
Cc: linux-pm, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, srv_heupstream, Saravana Kannan
In-Reply-To: <20200520034307.20435-2-andrew-sh.cheng@mediatek.com>
On 20/05/2020 05:42, Andrew-sh.Cheng wrote:
> From: Saravana Kannan <saravanak@google.com>
>
> A Device-A can have a (minimum) performance requirement on another
> Device-B to be able to function correctly. This performance requirement
> on Device-B can also change based on the current performance level of
> Device-A.
>
> The existing required-opps feature fits well to describe this need. So,
> instead of limiting required-opps to point to only PM-domain devices,
> allow it to point to any device.
>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
Please check all patches, they are missing your
Signed-off-by
Regards,
Matthias
> ---
> drivers/opp/core.c | 2 +-
> drivers/opp/of.c | 11 -----------
> 2 files changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index ba43e6a3dc0a..51403c1f2481 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -755,7 +755,7 @@ static int _set_required_opps(struct device *dev,
> return 0;
>
> /* Single genpd case */
> - if (!genpd_virt_devs) {
> + if (!genpd_virt_devs && required_opp_tables[0]->is_genpd) {
> pstate = likely(opp) ? opp->required_opps[0]->pstate : 0;
> ret = dev_pm_genpd_set_performance_state(dev, pstate);
> if (ret) {
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index 9cd8f0adacae..6d33de668a7b 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -195,17 +195,6 @@ static void _opp_table_alloc_required_tables(struct opp_table *opp_table,
>
> if (IS_ERR(required_opp_tables[i]))
> goto free_required_tables;
> -
> - /*
> - * We only support genpd's OPPs in the "required-opps" for now,
> - * as we don't know how much about other cases. Error out if the
> - * required OPP doesn't belong to a genpd.
> - */
> - if (!required_opp_tables[i]->is_genpd) {
> - dev_err(dev, "required-opp doesn't belong to genpd: %pOF\n",
> - required_np);
> - goto free_required_tables;
> - }
> }
>
> goto put_np;
>
^ permalink raw reply
* Re: [PATCH 00/12] Add cpufreq and cci devfreq for mt8183, and SVS support
From: Matthias Brugger @ 2020-05-20 14:53 UTC (permalink / raw)
To: andrew-sh.cheng, Chanwoo Choi
Cc: MyungJoo Ham, Kyungmin Park, Rob Herring, Mark Rutland,
Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Liam Girdwood, Mark Brown, linux-pm, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, srv_heupstream
In-Reply-To: <1589958625.23971.2.camel@mtksdaap41>
On 20/05/2020 09:10, andrew-sh.cheng wrote:
> On Wed, 2020-05-20 at 15:24 +0900, Chanwoo Choi wrote:
>> Hi,
>>
>> On 5/20/20 2:36 PM, andrew-sh.cheng wrote:
>>> On Wed, 2020-05-20 at 13:10 +0900, Chanwoo Choi wrote:
>>>> Hi Andrew,
>>>>
>>>> Could you explain the base commit of these patches?
>>>> When I tried to apply them to v5.7-rc1 for testing,
>>>> the merge conflict occurs.
>>>>
>>>> Thanks,
>>
>>>> Chanwoo Choi
>>>
>>> Hi Chanwoo Choi,
>>>
>>> My base commit is
>>> commit 8f3d9f354286745c751374f5f1fcafee6b3f3136
>>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>>> Date: Sun Apr 12 12:35:55 2020 -0700
>>>
>>> Linux 5.7-rc1
>>>
>>> Could you show me the conflict error?
>>
>>
>> When I tried to apply first patch with 'git am',
>> the merge conflict occurred.
>>
>> git am \[PATCH\ 01_12\]\ OPP\:\ Allow\ required-opps\ even\ if\ the\ device\ doesn\'t\ have\ power-domains.eml
>> Applying: OPP: Allow required-opps even if the device doesn't have power-domains
>> error: patch failed: drivers/opp/core.c:755
>> error: drivers/opp/core.c: patch does not apply
>> error: patch failed: drivers/opp/of.c:195
>> error: drivers/opp/of.c: patch does not apply
>> Patch failed at 0001 OPP: Allow required-opps even if the device doesn't have power-domains
>> Use 'git am --show-current-patch' to see the failed patch
>> When you have resolved this problem, run "git am --continue".
>> If you prefer to skip this patch, run "git am --skip" instead.
>> To restore the original branch and stop patching, run "git am --abort".
>>
>> Regards,
>> Chanwoo Choi
>
> Hi Chanwoo,
>
> I just make a new folder to get code and check.
> Below is my command list.
> Please help check the different with you.
> 505 repo init -u http://gerrit.mediatek.inc:8080/cros-kernel/manifest
> -b upstream
> 506 repo sync -j8
> 507 repo start kern-dev --all
> 508 git remote add main
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 509 git remote add main
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 510 ls
> 511 cd kernel/mediatek/
> 512 git remote add main
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 513 git fetch main
> 514 git checkout v5.7-rc1
> 515 git am
> Add-cpufreq-and-cci-devfreq-for-mt8183-and-SVS-support.patch
> 516 history
>
For reference I just tried with b4.sh [1]:
# b4.sh am -l -o /tmp -n patch 1589958625.23971.2.camel@mtksdaap41
# git am -3 -s /tmp/patch.mbx
Applies without conflicts.
Regards,
Matthias
[1] https://git.kernel.org/pub/scm/utils/b4/b4.git
^ permalink raw reply
* Re: [TEGRA194_CPUFREQ Patch 1/3] firmware: tegra: adding function to get BPMP data
From: Rob Herring @ 2020-05-20 14:43 UTC (permalink / raw)
To: Thierry Reding
Cc: Viresh Kumar, Rafael J. Wysocki, Mikko Perttunen, Sumit Gupta,
Catalin Marinas, Will Deacon, Jon Hunter, Timo Alho,
open list:THERMAL, linux-tegra,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel@vger.kernel.org, bbasu, Mikko Perttunen, devicetree
In-Reply-To: <20200407100520.GA1720957@ulmo>
On Tue, Apr 7, 2020 at 4:05 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Wed, Dec 04, 2019 at 03:21:38PM +0530, Viresh Kumar wrote:
> > On 04-12-19, 10:33, Thierry Reding wrote:
> > > Yeah, the code that registers this device is in drivers/base/cpu.c in
> > > register_cpu(). It even retrieves the device tree node for the CPU from
> > > device tree and stores it in cpu->dev.of_node, so we should be able to
> > > just pass &cpu->dev to tegra_bpmp_get() in order to retrieve a reference
> > > to the BPMP.
> > >
> > > That said, I'm wondering if perhaps we could just add a compatible
> > > string to the /cpus node for cases like this where we don't have an
> > > actual device representing the CPU complex. There are a number of CPU
> > > frequency drivers that register dummy devices just so that they have
> > > something to bind a driver to.
> > >
> > > If we allow the /cpus node to represent the CPU complex (if no other
> > > "device" does that yet), we can add a compatible string and have the
> > > cpufreq driver match on that.
> > >
> > > Of course this would be slightly difficult to retrofit into existing
> > > drivers because they'd need to remain backwards compatible with existing
> > > device trees. But it would allow future drivers to do this a little more
> > > elegantly. For some SoCs this may not matter, but especially once you
> > > start depending on additional resources this would come in handy.
> > >
> > > Adding Rob and the device tree mailing list for feedback on this idea.
> >
> > Took some time to find this thread, but something around this was
> > suggested by Rafael earlier.
> >
> > https://lore.kernel.org/lkml/8139001.Q4eV8YG1Il@vostro.rjw.lan/
>
> I gave this a try and came up with the following:
>
> --- >8 ---
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> index f4ede86e32b4..e4462f95f0b3 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -1764,6 +1764,9 @@ bpmp_thermal: thermal {
> };
>
> cpus {
> + compatible = "nvidia,tegra194-ccplex";
> + nvidia,bpmp = <&bpmp>;
Is there more than 1 bpmp? If not you don't need this. Just lookup the
node by compatible.
> +
> #address-cells = <1>;
> #size-cells = <0>;
>
> --- >8 ---
>
> Now I can do something rougly like this, although I have a more complete
> patch locally that also gets rid of all the global variables because we
> now actually have a struct platform_device that we can anchor everything
> at:
>
> --- >8 ---
> static const struct of_device_id tegra194_cpufreq_of_match[] = {
> { .compatible = "nvidia,tegra194-ccplex", },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, tegra194_cpufreq_of_match);
>
> static struct platform_driver tegra194_ccplex_driver = {
> .driver = {
> .name = "tegra194-cpufreq",
> .of_match_table = tegra194_cpufreq_of_match,
> },
> .probe = tegra194_cpufreq_probe,
> .remove = tegra194_cpufreq_remove,
> };
> module_platform_driver(tegra194_ccplex_driver);
> --- >8 ---
>
> I don't think that's exactly what Rafael (Cc'ed) had in mind, since the
> above thread seems to have mostly talked about binding a driver to each
> individual CPU.
>
> But this seems a lot better than having to instantiate a device from
> scratch just so that a driver can bind to it and it allows additional
> properties to be associated with the CCPLEX device.
What additional properties? A continual stream of properties added 1
by 1 would negatively affect my opinion of this.
> Rob, any thoughts on this from a device tree point of view? The /cpus
> bindings don't mention the compatible property, but there doesn't seem
> to be anything in the bindings that would prohibit its use.
What happens when you have more than one cpu related driver in
addition to cpufreq? You may still have to end up creating child
platform devices and then gained very little.
You could solve this without DT changes. You can bind on node names.
The driver probe can then check the parent compatible and return if
not matching. I'm not sure if you could get module auto loading to
work in that case. It would have to be based on the root compatible
(rather than the driver match table) and be able to load multiple
matching modules.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: memory: document Renesas RPC-IF bindings
From: Sergei Shtylyov @ 2020-05-20 14:38 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, Mason Yang, linux-spi, Chris Brandt, linux-mtd
In-Reply-To: <20200501212547.GB15294@bogus>
On 02.05.2020 0:25, 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>
>>
>> ---
>> Changes in version 2:
>> - rewrote the bindings in YAML.
>>
>> Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml | 88 ++++++++++
>
> Not where we normally put SPI flash controllers...
RPC-IF is not exactly SPI flash controller, it's bimodal.
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