* [PATCH 3/3] arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
From: Gilles Talis @ 2024-03-28 20:23 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel
Cc: conor+dt, krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex,
Gilles Talis
In-Reply-To: <20240328202320.187596-1-gilles.talis@gmail.com>
The Emcraft Systems NavQ+ kit is a mobile robotics platform
based on NXP i.MX8 MPlus SoC.
The following interfaces and devices are enabled:
- eMMC
- Gigabit Ethernet
- RTC
- SD-Card
- UART console
Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../arm64/boot/dts/freescale/imx8mp-navqp.dts | 435 ++++++++++++++++++
2 files changed, 436 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 045250d0a040..bf99864c0bc4 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -166,6 +166,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-pdk3.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-icore-mx8mp-edimm2.2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-msc-sm2s-ep1.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-navqp.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-phyboard-pollux-rdk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-hdmi.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-lt6.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts b/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
new file mode 100644
index 000000000000..8182e71008f8
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
@@ -0,0 +1,435 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2021 Emcraft Systems
+ * Copyright 2024 Gilles Talis <gilles.talis@gmail.com>
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "imx8mp.dtsi"
+
+/ {
+ model = "Emcraft Systems i.MX8MPlus NavQ+ Kit";
+ compatible = "emcraft,imx8mp-navqp", "fsl,imx8mp";
+
+ chosen {
+ stdout-path = &uart2;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_led>;
+
+ status {
+ label = "status";
+ gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ regulator-name = "VSD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ startup-delay-us = <100>;
+ off-on-delay-us = <12000>;
+ };
+};
+
+&A53_0 {
+ cpu-supply = <&buck2>;
+};
+
+&A53_1 {
+ cpu-supply = <&buck2>;
+};
+
+&A53_2 {
+ cpu-supply = <&buck2>;
+};
+
+&A53_3 {
+ cpu-supply = <&buck2>;
+};
+
+&eqos {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eqos>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <1000>;
+ reset-deassert-us = <10000>;
+ qca,disable-smarteee;
+ qca,disable-hibernation-mode;
+ vddio-supply = <&vddio>;
+
+ vddio: vddio-regulator {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ pmic@25 {
+ compatible = "nxp,pca9450c";
+ reg = <0x25>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ nxp,dvs-run-voltage = <950000>;
+ nxp,dvs-standby-voltage = <850000>;
+ };
+
+ BUCK4 {
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ BUCK5 {
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO2 {
+ regulator-name = "LDO2";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1150000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO3 {
+ regulator-name = "LDO3";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO5 {
+ regulator-name = "LDO5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&i2c3 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+};
+
+&i2c4 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ status = "okay";
+
+ rtc@53 {
+ compatible = "nxp,pcf2131";
+ reg = <0x53>;
+ };
+};
+
+&uart2 {
+ /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+/* SD Card */
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ bus-width = <4>;
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc3 {
+ assigned-clocks = <&clk IMX8MP_CLK_USDHC3>;
+ assigned-clock-rates = <400000000>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_eqos: eqosgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_ENET_MDC__ENET_QOS_MDC 0x3
+ MX8MP_IOMUXC_ENET_MDIO__ENET_QOS_MDIO 0x3
+ MX8MP_IOMUXC_ENET_RD0__ENET_QOS_RGMII_RD0 0x91
+ MX8MP_IOMUXC_ENET_RD1__ENET_QOS_RGMII_RD1 0x91
+ MX8MP_IOMUXC_ENET_RD2__ENET_QOS_RGMII_RD2 0x91
+ MX8MP_IOMUXC_ENET_RD3__ENET_QOS_RGMII_RD3 0x91
+ MX8MP_IOMUXC_ENET_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x91
+ MX8MP_IOMUXC_ENET_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x91
+ MX8MP_IOMUXC_ENET_TD0__ENET_QOS_RGMII_TD0 0x1f
+ MX8MP_IOMUXC_ENET_TD1__ENET_QOS_RGMII_TD1 0x1f
+ MX8MP_IOMUXC_ENET_TD2__ENET_QOS_RGMII_TD2 0x1f
+ MX8MP_IOMUXC_ENET_TD3__ENET_QOS_RGMII_TD3 0x1f
+ MX8MP_IOMUXC_ENET_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x1f
+ MX8MP_IOMUXC_ENET_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x1f
+ MX8MP_IOMUXC_SAI2_RXC__GPIO4_IO22 0x110
+ >;
+ };
+
+ pinctrl_gpio_led: gpioledgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_READY_B__GPIO3_IO16 0x19
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL 0x400001c3
+ MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001c3
+ MX8MP_IOMUXC_I2C2_SDA__I2C2_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C3_SCL__I2C3_SCL 0x400001c3
+ MX8MP_IOMUXC_I2C3_SDA__I2C3_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C4_SCL__I2C4_SCL 0x400001c3
+ MX8MP_IOMUXC_I2C4_SDA__I2C4_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c6: i2c6grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_UART4_RXD__I2C6_SCL 0x400001c3
+ MX8MP_IOMUXC_UART4_TXD__I2C6_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_pmic: pmicirq {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ >;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_RESET_B__GPIO2_IO19 0x41
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x49
+ MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x49
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x190
+ MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d0
+ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d0
+ MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d0
+ MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d0
+ MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d0
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2grp-100mhz {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x194
+ MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d4
+ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d4
+ MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d4
+ MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d4
+ MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d4
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2grp-200mhz {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x196
+ MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d6
+ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d6
+ MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d6
+ MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d6
+ MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d6
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2grp-gpio {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CD_B__GPIO2_IO12 0x1c4
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x190
+ MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d0
+ MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d0
+ MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d0
+ MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d0
+ MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d0
+ MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d0
+ MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d0
+ MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d0
+ MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d0
+ MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x190
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3grp-100mhz {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x194
+ MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d4
+ MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d4
+ MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d4
+ MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d4
+ MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d4
+ MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d4
+ MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d4
+ MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d4
+ MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d4
+ MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x194
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3grp-200mhz {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x196
+ MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d6
+ MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d6
+ MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d6
+ MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d6
+ MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d6
+ MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d6
+ MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d6
+ MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d6
+ MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d6
+ MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x196
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO02__WDOG1_WDOG_B 0xc6
+ >;
+ };
+};
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 17/19] Input: ambakmi - drop owner assignment
From: Dmitry Torokhov @ 2024-03-28 20:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-17-4517b091385b@linaro.org>
On Tue, Mar 26, 2024 at 09:23:47PM +0100, Krzysztof Kozlowski wrote:
> Amba bus core already sets owner, so driver does not need to.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Thanks.
--
Dmitry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 1/1] dt-bindings: net: starfive,jh7110-dwmac: Add StarFive JH8100 support
From: Rob Herring @ 2024-03-28 20:42 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Tan Chun Hau, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Emil Renner Berthing, Krzysztof Kozlowski,
Conor Dooley, Maxime Coquelin, Alexandre Torgue, Simon Horman,
Bartosz Golaszewski, Andrew Halaney, Jisheng Zhang,
Uwe Kleine-König, Russell King, Ley Foon Tan, Jee Heng Sia,
netdev, devicetree, linux-kernel, linux-stm32, linux-arm-kernel,
linux-riscv
In-Reply-To: <31ac366d-bfa6-4c99-a04d-ab9fb029da7e@linaro.org>
On Wed, Mar 27, 2024 at 08:54:30AM +0100, Krzysztof Kozlowski wrote:
> On 27/03/2024 02:57, Tan Chun Hau wrote:
> > Add StarFive JH8100 dwmac support.
> > The JH8100 dwmac shares the same driver code as the JH7110 dwmac
> > and has only one reset signal.
> >
> > Please refer to below:
> >
> > JH8100: reset-names = "stmmaceth";
> > JH7110: reset-names = "stmmaceth", "ahb";
> > JH7100: reset-names = "ahb";
> >
> > Example usage of JH8100 in the device tree:
> >
> > gmac0: ethernet@16030000 {
> > compatible = "starfive,jh8100-dwmac",
> > "starfive,jh7110-dwmac",
> > "snps,dwmac-5.20";
> > ...
> > };
> >
> > Signed-off-by: Tan Chun Hau <chunhau.tan@starfivetech.com>
> > ---
> > .../devicetree/bindings/net/snps,dwmac.yaml | 1 +
> > .../bindings/net/starfive,jh7110-dwmac.yaml | 29 +++++++++++++++----
> > 2 files changed, 25 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > index 6b0341a8e0ea..a6d596b7dcf4 100644
> > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > @@ -97,6 +97,7 @@ properties:
> > - snps,dwxgmac-2.10
> > - starfive,jh7100-dwmac
> > - starfive,jh7110-dwmac
> > + - starfive,jh8100-dwmac
>
> I think that's not needed. You have there already your fallback.
>
> >
> > reg:
> > minItems: 1
> > diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > index 0d1962980f57..5805a58c55d1 100644
> > --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > @@ -18,6 +18,7 @@ select:
> > enum:
> > - starfive,jh7100-dwmac
> > - starfive,jh7110-dwmac
> > + - starfive,jh8100-dwmac
>
> Same here, even more obvious.
Agreed.
>
> > required:
> > - compatible
> >
> > @@ -30,6 +31,10 @@ properties:
> > - items:
> > - const: starfive,jh7110-dwmac
> > - const: snps,dwmac-5.20
> > + - items:
> > + - const: starfive,jh8100-dwmac
> > + - const: starfive,jh7110-dwmac
> > + - const: snps,dwmac-5.20
> >
> > reg:
> > maxItems: 1
> > @@ -116,11 +121,25 @@ allOf:
> > minItems: 3
> > maxItems: 3
> >
> > - resets:
> > - minItems: 2
> > -
> > - reset-names:
> > - minItems: 2
> > + if:
>
> I would personally avoid nesting if within if. It gets unreadable.
> Although Rob did not comment on this one, so I guess it is fine.
I normally agree, but here I suggested it as it looked to be the
simplest option.
With the 2 other comments addressed,
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
From: Andrew Lunn @ 2024-03-28 20:42 UTC (permalink / raw)
To: Gilles Talis
Cc: devicetree, imx, linux-arm-kernel, conor+dt,
krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex
In-Reply-To: <20240328202320.187596-4-gilles.talis@gmail.com>
> +&eqos {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_eqos>;
> + phy-mode = "rgmii-id";
> + phy-handle = <ðphy0>;
> + status = "okay";
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <1000>;
> + reset-deassert-us = <10000>;
> + qca,disable-smarteee;
> + qca,disable-hibernation-mode;
> + vddio-supply = <&vddio>;
> +
> + vddio: vddio-regulator {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
Please could you explain what this last node is doing.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 18/23] dt-bindings: media: imx258: Add alternate compatible strings
From: Rob Herring @ 2024-03-28 20:46 UTC (permalink / raw)
To: Luigi311
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <76f999a7-55e0-4676-aa75-8fcd466e046b@luigi311.com>
On Thu, Mar 28, 2024 at 01:16:22PM -0600, Luigi311 wrote:
> On 3/28/24 12:55, Rob Herring wrote:
> > On Wed, Mar 27, 2024 at 05:17:04PM -0600, git@luigi311.com wrote:
> >> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
> >>
> >> There are a number of variants of the imx258 modules that can not
> >> be differentiated at runtime, so add compatible strings for them.
> >> But you are only adding 1 variant.
>
> I can not speak for Dave but as to why this was added here but looking
> at the imx296 yaml that has something similar where there are multiple
> variants that may not be detectable at run time but does not include
> similar verbiage in the main description. Should I drop this from the
> description so it matches the imx296?
Just change "add compatible strings for them" to "add compatible string
for the PDAF variant" or something.
>
> >
> >>
> >> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> >> Signed-off-by: Luigi311 <git@luigi311.com>
> >> ---
> >> .../devicetree/bindings/media/i2c/sony,imx258.yaml | 6 +++++-
> >> 1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> >> index bee61a443b23..c7856de15ba3 100644
> >> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> >> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> >> @@ -14,10 +14,14 @@ description: |-
> >> type stacked image sensor with a square pixel array of size 4208 x 3120. It
> >> is programmable through I2C interface. Image data is sent through MIPI
> >> CSI-2.
> >> + There are a number of variants of the sensor which cannot be detected at
> >> + runtime, so multiple compatible strings are required to differentiate these.
> >
> > That's more reasoning/why for the patch than description of the h/w.
> >
> >> properties:
> >> compatible:
> >> - const: sony,imx258
> >> + - enum:
> >> + - sony,imx258
> >> + - sony,imx258-pdaf
> >
> > How do I know which one to use? Please define what PDAF means somewhere
> > as well as perhaps what the original/default variant is or isn't.
>
> Would it make sense to change the properties to include a description like so
>
> properties:
> compatible:
> enum:
> - sony,imx258
> - sony,imx258-pdaf
> description:
> The IMX258 sensor exists in two different models, a standard variant
> (IMX258) and a variant with phase detection autofocus (IMX258-PDAF).
> The camera module does not expose the model through registers, so the
> exact model needs to be specified.
Looks fine, but I'd move this to the top-level 'description'.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx7s-warp: Pass OV2680 link-frequencies
From: Rob Herring @ 2024-03-28 21:01 UTC (permalink / raw)
To: Fabio Estevam
Cc: Fabio Estevam, linux-arm-kernel, sakari.ailus, stable, hdegoede,
devicetree, shawnguo, conor+dt, krzysztof.kozlowski+dt
In-Reply-To: <20240328151954.2517368-1-festevam@gmail.com>
On Thu, 28 Mar 2024 12:19:54 -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
>
> Since commit 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint
> property verification") the ov2680 no longer probes on a imx7s-warp7:
>
> ov2680 1-0036: error -EINVAL: supported link freq 330000000 not found
> ov2680 1-0036: probe with driver ov2680 failed with error -22
>
> Fix it by passing the required 'link-frequencies' property as
> recommended by:
>
> https://www.kernel.org/doc/html/v6.9-rc1/driver-api/media/camera-sensor.html#handling-clocks
>
> Cc: stable@vger.kernel.org
> Fixes: 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification")
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
> arch/arm/boot/dts/nxp/imx/imx7s-warp.dts | 1 +
> 1 file changed, 1 insertion(+)
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y nxp/imx/imx7s-warp.dtb' for 20240328151954.2517368-1-festevam@gmail.com:
arch/arm/boot/dts/nxp/imx/imx7s-warp.dtb: camera@36: port:endpoint: Unevaluated properties are not allowed ('clock-lanes', 'data-lanes', 'link-frequencies' were unexpected)
from schema $id: http://devicetree.org/schemas/media/i2c/ovti,ov2680.yaml#
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] Add support for Emcraft Systems NavQ+ kit
From: Rob Herring @ 2024-03-28 21:01 UTC (permalink / raw)
To: Gilles Talis
Cc: shawnguo, linux-arm-kernel, festevam, devicetree, conor+dt, imx,
alex, krzysztof.kozlowski+dt
In-Reply-To: <20240328202320.187596-1-gilles.talis@gmail.com>
On Thu, 28 Mar 2024 16:23:17 -0400, Gilles Talis wrote:
> Hello
>
> This series adds a device tree file for the Emcraft Systems NavQ+ kit [1]
>
> The first patch adds a new vendor prefix for Emcraft Systems
> The second one adds the board to the arm/fsl.yaml DT bindings.
> Last patch adds device tree file for the kit.
>
> [1] https://www.emcraft.com/products/1222
>
>
> Gilles Talis (3):
> dt-bindings: vendor-prefixes: Add Emcraft Systems
> dt-bindings: arm: Add Emcraft Systems i.MX8M Plus NavQ+ Kit
> arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
>
> .../devicetree/bindings/arm/fsl.yaml | 1 +
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> .../arm64/boot/dts/freescale/imx8mp-navqp.dts | 435 ++++++++++++++++++
> 4 files changed, 439 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
>
>
> base-commit: 4cece764965020c22cff7665b18a012006359095
> --
> 2.39.2
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y freescale/imx8mp-navqp.dtb' for 20240328202320.187596-1-gilles.talis@gmail.com:
arch/arm64/boot/dts/freescale/imx8mp-navqp.dtb: pinctrl@30330000: 'pmicirq', 'usdhc2grp-100mhz', 'usdhc2grp-200mhz', 'usdhc2grp-gpio', 'usdhc3grp-100mhz', 'usdhc3grp-200mhz' do not match any of the regexes: 'grp$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/pinctrl/fsl,imx8m-pinctrl.yaml#
arch/arm64/boot/dts/freescale/imx8mp-navqp.dtb: pinctrl@30330000: usdhc2grp-gpio: {'fsl,pins': [[188, 796, 0, 5, 0, 452]], 'phandle': [[51]]} is not of type 'array'
from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml#
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: ti: Add BeagleY-AI
From: Rob Herring @ 2024-03-28 21:01 UTC (permalink / raw)
To: Robert Nelson
Cc: Jared McArthur, Jason Kridner, linux-arm-kernel, devicetree,
Nishanth Menon, Deepak Khatri, linux-kernel
In-Reply-To: <20240328191205.82295-1-robertcnelson@gmail.com>
On Thu, 28 Mar 2024 14:12:04 -0500, Robert Nelson wrote:
> This board is based on ti,j722s
>
> https://beagley-ai.org/
> https://openbeagle.org/beagley-ai/beagley-ai
>
> Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
> CC: Rob Herring <robh@kernel.org>
> CC: Nishanth Menon <nm@ti.com>
> CC: Jared McArthur <j-mcarthur@ti.com>
> CC: Jason Kridner <jkridner@beagleboard.org>
> CC: Deepak Khatri <lorforlinux@beagleboard.org>
> ---
> Documentation/devicetree/bindings/arm/ti/k3.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y ti/k3-j722s-beagley-ai.dtb' for 20240328191205.82295-1-robertcnelson@gmail.com:
arch/arm64/boot/dts/ti/k3-j722s-beagley-ai.dtb: pinctrl@f4000: 'vdd-3v3-sd-pins-default' does not match any of the regexes: '-pins(-[0-9]+)?$|-pin$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/pinctrl/pinctrl-single.yaml#
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 18/23] dt-bindings: media: imx258: Add alternate compatible strings
From: Luigi311 @ 2024-03-28 21:02 UTC (permalink / raw)
To: Rob Herring
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240328204657.GA314523-robh@kernel.org>
On 3/28/24 14:46, Rob Herring wrote:
> On Thu, Mar 28, 2024 at 01:16:22PM -0600, Luigi311 wrote:
>> On 3/28/24 12:55, Rob Herring wrote:
>>> On Wed, Mar 27, 2024 at 05:17:04PM -0600, git@luigi311.com wrote:
>>>> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>>>>
>>>> There are a number of variants of the imx258 modules that can not
>>>> be differentiated at runtime, so add compatible strings for them.
>>>> But you are only adding 1 variant.
>>
>> I can not speak for Dave but as to why this was added here but looking
>> at the imx296 yaml that has something similar where there are multiple
>> variants that may not be detectable at run time but does not include
>> similar verbiage in the main description. Should I drop this from the
>> description so it matches the imx296?
>
> Just change "add compatible strings for them" to "add compatible string
> for the PDAF variant" or something.
>
Ohh i see what you mean now, this is in reference to the commit message,
it was throwing me off because the imx258 description had almost the
exact same wording. Yes that makes sense, ill change the commit
message to specify PDAF.
>>
>>>
>>>>
>>>> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
>>>> Signed-off-by: Luigi311 <git@luigi311.com>
>>>> ---
>>>> .../devicetree/bindings/media/i2c/sony,imx258.yaml | 6 +++++-
>>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>>>> index bee61a443b23..c7856de15ba3 100644
>>>> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>>>> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>>>> @@ -14,10 +14,14 @@ description: |-
>>>> type stacked image sensor with a square pixel array of size 4208 x 3120. It
>>>> is programmable through I2C interface. Image data is sent through MIPI
>>>> CSI-2.
>>>> + There are a number of variants of the sensor which cannot be detected at
>>>> + runtime, so multiple compatible strings are required to differentiate these.
>>>
>>> That's more reasoning/why for the patch than description of the h/w.
>>>
>>>> properties:
>>>> compatible:
>>>> - const: sony,imx258
>>>> + - enum:
>>>> + - sony,imx258
>>>> + - sony,imx258-pdaf
>>>
>>> How do I know which one to use? Please define what PDAF means somewhere
>>> as well as perhaps what the original/default variant is or isn't.
>>
>> Would it make sense to change the properties to include a description like so
>>
>> properties:
>> compatible:
>> enum:
>> - sony,imx258
>> - sony,imx258-pdaf
>> description:
>> The IMX258 sensor exists in two different models, a standard variant
>> (IMX258) and a variant with phase detection autofocus (IMX258-PDAF).
>> The camera module does not expose the model through registers, so the
>> exact model needs to be specified.
>
> Looks fine, but I'd move this to the top-level 'description'.
>
> Rob
Perfect ill move this to the top level description and remove that small section
that Dave added
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 02/18] pinctrl: pinctrl-single: move suspend()/resume() callbacks to noirq
From: Linus Walleij @ 2024-03-28 21:07 UTC (permalink / raw)
To: Thomas Richard
Cc: Bartosz Golaszewski, Andy Shevchenko, Tony Lindgren,
Haojian Zhuang, Vignesh R, Aaro Koskinen, Janusz Krzysztofik,
Andi Shyti, Peter Rosin, Vinod Koul, Kishon Vijay Abraham I,
Philipp Zabel, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Bjorn Helgaas, linux-gpio, linux-kernel,
linux-arm-kernel, linux-omap, linux-i2c, linux-phy, linux-pci,
gregory.clement, theo.lebrun, thomas.petazzoni, u-kumar1,
Andy Shevchenko
In-Reply-To: <20240102-j7200-pcie-s2r-v4-2-6f1f53390c85@bootlin.com>
On Mon, Mar 4, 2024 at 4:36 PM Thomas Richard
<thomas.richard@bootlin.com> wrote:
> The goal is to extend the active period of pinctrl.
> Some devices may need active pinctrl after suspend() and/or before
> resume().
> So move suspend()/resume() to suspend_noirq()/resume_noirq() in order to
> have active pinctrl until suspend_noirq() (included), and from
> resume_noirq() (included).
>
> The deprecated API has been removed to use the new one (dev_pm_ops struct).
>
> No need to check the pointer returned by dev_get_drvdata(), as
> platform_set_drvdata() is called during the probe.
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
Since this patch looks independent from the rest I ripped it out of the
patch series and applied it to the pinctrl tree for kernel v6.10.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 22/23] drivers: media: i2c: imx258: Add support for powerdown gpio
From: Luigi311 @ 2024-03-28 21:11 UTC (permalink / raw)
To: Rob Herring
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, Ondrej Jirman
In-Reply-To: <20240328204841.GA318468-robh@kernel.org>
On 3/28/24 14:48, Rob Herring wrote:
> On Wed, Mar 27, 2024 at 05:17:08PM -0600, git@luigi311.com wrote:
>> From: Luigi311 <git@luigi311.com>
>>
>> On some boards powerdown signal needs to be deasserted for this
>> sensor to be enabled.
>>
>> Signed-off-by: Ondrej Jirman <megi@xff.cz>
>> ---
>> .../devicetree/bindings/media/i2c/sony,imx258.yaml | 4 ++++
>
> Bindings should be a separate patch.
>
Ok ill create separate patch for adding in the binding and then
a follow up patch with the other half that actually adds it to
the driver
>> drivers/media/i2c/imx258.c | 13 +++++++++++++
>> 2 files changed, 17 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>> index c7856de15ba3..0414085bf22f 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>> @@ -35,6 +35,10 @@ properties:
>> reg:
>> maxItems: 1
>>
>> + powerdown-gpios:
>> + description: |-
>
> Don't need '|-' if no formatting>
Done
>> + Reference to the GPIO connected to the PWDN pin, if any.
>> +
>> reset-gpios:
>> description: |-
>> Reference to the GPIO connected to the XCLR pin, if any.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 3/4] of: reserved_mem: Use the unflatten_devicetree APIs to scan reserved mem. nodes
From: Oreoluwa Babatunde @ 2024-03-28 21:15 UTC (permalink / raw)
To: catalin.marinas, will, robh+dt, frowand.list, vgupta, arnd, olof,
soc, guoren, monstr, palmer, aou, dinguyen, chenhuacai, tsbogend,
jonas, stefan.kristiansson, shorne, mpe, ysato, dalias, glaubitz,
richard, anton.ivanov, johannes, chris, jcmvbkbc
Cc: linux-arm-kernel, linux-kernel, devicetree, linux-arm-msm, kernel,
Oreoluwa Babatunde
In-Reply-To: <20240328211543.191876-1-quic_obabatun@quicinc.com>
The unflatten_devicetree APIs have been setup and are available to be
used by the time the fdt_init_reserved_mem() function is called.
Since the unflatten_devicetree APIs are a more efficient way of scanning
through the DT nodes, switch to using these APIs to facilitate the rest
of the reserved memory processing.
Signed-off-by: Oreoluwa Babatunde <quic_obabatun@quicinc.com>
---
drivers/of/of_reserved_mem.c | 77 +++++++++++++++++++++------------
include/linux/of_reserved_mem.h | 2 +-
kernel/dma/coherent.c | 8 ++--
kernel/dma/contiguous.c | 8 ++--
kernel/dma/swiotlb.c | 10 ++---
5 files changed, 64 insertions(+), 41 deletions(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 0aba366eba59..68d1f4cca4bb 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -99,7 +99,7 @@ static void __init alloc_reserved_mem_array(void)
/*
* fdt_reserved_mem_save_node() - save fdt node for second pass initialization
*/
-static void __init fdt_reserved_mem_save_node(unsigned long node, const char *uname,
+static void __init fdt_reserved_mem_save_node(struct device_node *node, const char *uname,
phys_addr_t base, phys_addr_t size)
{
struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
@@ -109,7 +109,7 @@ static void __init fdt_reserved_mem_save_node(unsigned long node, const char *un
return;
}
- rmem->fdt_node = node;
+ rmem->dev_node = node;
rmem->name = uname;
rmem->base = base;
rmem->size = size;
@@ -178,11 +178,11 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
}
/*
- * __reserved_mem_check_root() - check if #size-cells, #address-cells provided
+ * __fdt_reserved_mem_check_root() - check if #size-cells, #address-cells provided
* in /reserved-memory matches the values supported by the current implementation,
* also check if ranges property has been provided
*/
-static int __init __reserved_mem_check_root(unsigned long node)
+static int __init __fdt_reserved_mem_check_root(unsigned long node)
{
const __be32 *prop;
@@ -200,6 +200,29 @@ static int __init __reserved_mem_check_root(unsigned long node)
return 0;
}
+/*
+ * __dt_reserved_mem_check_root() - check if #size-cells, #address-cells provided
+ * in /reserved-memory matches the values supported by the current implementation,
+ * also check if ranges property has been provided
+ */
+static int __init __dt_reserved_mem_check_root(struct device_node *node)
+{
+ const __be32 *prop;
+
+ prop = of_get_property(node, "#size-cells", NULL);
+ if (!prop || be32_to_cpup(prop) != dt_root_size_cells)
+ return -EINVAL;
+
+ prop = of_get_property(node, "#address-cells", NULL);
+ if (!prop || be32_to_cpup(prop) != dt_root_addr_cells)
+ return -EINVAL;
+
+ prop = of_get_property(node, "ranges", NULL);
+ if (!prop)
+ return -EINVAL;
+ return 0;
+}
+
/**
* fdt_scan_reserved_mem_reg_nodes() - Store info for the "reg" defined
* reserved memory regions.
@@ -213,33 +236,38 @@ static int __init __reserved_mem_check_root(unsigned long node)
static void __init fdt_scan_reserved_mem_reg_nodes(void)
{
int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
- const void *fdt = initial_boot_params;
+ struct device_node *node, *child;
phys_addr_t base, size;
const __be32 *prop;
- int node, child;
int len;
- node = fdt_path_offset(fdt, "/reserved-memory");
- if (node < 0) {
+ node = of_find_node_by_path("/reserved-memory");
+ if (!node) {
pr_info("Reserved memory: No reserved-memory node in the DT\n");
return;
}
- if (__reserved_mem_check_root(node)) {
+ if (__dt_reserved_mem_check_root(node)) {
pr_err("Reserved memory: unsupported node format, ignoring\n");
return;
}
- fdt_for_each_subnode(child, fdt, node) {
+ for_each_child_of_node(node, child) {
const char *uname;
+ struct reserved_mem *rmem;
- prop = of_get_flat_dt_prop(child, "reg", &len);
- if (!prop)
+ if (!of_device_is_available(child))
continue;
- if (!of_fdt_device_is_available(fdt, child))
+
+ prop = of_get_property(child, "reg", &len);
+ if (!prop) {
+ rmem = of_reserved_mem_lookup(child);
+ if (rmem)
+ rmem->dev_node = child;
continue;
+ }
- uname = fdt_get_name(fdt, child, NULL);
+ uname = of_node_full_name(child);
if (len && len % t_len != 0) {
pr_err("Reserved memory: invalid reg property in '%s', skipping node.\n",
uname);
@@ -269,7 +297,7 @@ int __init fdt_scan_reserved_mem(void)
if (node < 0)
return -ENODEV;
- if (__reserved_mem_check_root(node) != 0) {
+ if (__fdt_reserved_mem_check_root(node) != 0) {
pr_err("Reserved memory: unsupported node format, ignoring\n");
return -EINVAL;
}
@@ -447,7 +475,7 @@ static int __init __reserved_mem_alloc_size(unsigned long node, const char *unam
uname, (unsigned long)(size / SZ_1M));
return -ENOMEM;
}
- fdt_reserved_mem_save_node(node, uname, base, size);
+ fdt_reserved_mem_save_node(NULL, uname, base, size);
return 0;
}
@@ -467,7 +495,7 @@ static int __init __reserved_mem_init_node(struct reserved_mem *rmem)
reservedmem_of_init_fn initfn = i->data;
const char *compat = i->compatible;
- if (!of_flat_dt_is_compatible(rmem->fdt_node, compat))
+ if (!of_device_is_compatible(rmem->dev_node, compat))
continue;
ret = initfn(rmem);
@@ -500,11 +528,6 @@ static int __init __rmem_cmp(const void *a, const void *b)
if (ra->size > rb->size)
return 1;
- if (ra->fdt_node < rb->fdt_node)
- return -1;
- if (ra->fdt_node > rb->fdt_node)
- return 1;
-
return 0;
}
@@ -551,16 +574,16 @@ void __init fdt_init_reserved_mem(void)
for (i = 0; i < reserved_mem_count; i++) {
struct reserved_mem *rmem = &reserved_mem[i];
- unsigned long node = rmem->fdt_node;
+ struct device_node *node = rmem->dev_node;
int len;
const __be32 *prop;
int err = 0;
bool nomap;
- nomap = of_get_flat_dt_prop(node, "no-map", NULL) != NULL;
- prop = of_get_flat_dt_prop(node, "phandle", &len);
+ nomap = of_get_property(node, "no-map", NULL) != NULL;
+ prop = of_get_property(node, "phandle", &len);
if (!prop)
- prop = of_get_flat_dt_prop(node, "linux,phandle", &len);
+ prop = of_get_property(node, "linux,phandle", &len);
if (prop)
rmem->phandle = of_read_number(prop, len/4);
@@ -574,7 +597,7 @@ void __init fdt_init_reserved_mem(void)
} else {
phys_addr_t end = rmem->base + rmem->size - 1;
bool reusable =
- (of_get_flat_dt_prop(node, "reusable", NULL)) != NULL;
+ (of_get_property(node, "reusable", NULL)) != NULL;
pr_info("%pa..%pa (%lu KiB) %s %s %s\n",
&rmem->base, &end, (unsigned long)(rmem->size / SZ_1K),
diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
index 4de2a24cadc9..b6107a18d170 100644
--- a/include/linux/of_reserved_mem.h
+++ b/include/linux/of_reserved_mem.h
@@ -10,7 +10,7 @@ struct reserved_mem_ops;
struct reserved_mem {
const char *name;
- unsigned long fdt_node;
+ struct device_node *dev_node;
unsigned long phandle;
const struct reserved_mem_ops *ops;
phys_addr_t base;
diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c
index ff5683a57f77..0db0aae83102 100644
--- a/kernel/dma/coherent.c
+++ b/kernel/dma/coherent.c
@@ -362,20 +362,20 @@ static const struct reserved_mem_ops rmem_dma_ops = {
static int __init rmem_dma_setup(struct reserved_mem *rmem)
{
- unsigned long node = rmem->fdt_node;
+ struct device_node *node = rmem->dev_node;
- if (of_get_flat_dt_prop(node, "reusable", NULL))
+ if (of_get_property(node, "reusable", NULL))
return -EINVAL;
#ifdef CONFIG_ARM
- if (!of_get_flat_dt_prop(node, "no-map", NULL)) {
+ if (!of_get_property(node, "no-map", NULL)) {
pr_err("Reserved memory: regions without no-map are not yet supported\n");
return -EINVAL;
}
#endif
#ifdef CONFIG_DMA_GLOBAL_POOL
- if (of_get_flat_dt_prop(node, "linux,dma-default", NULL)) {
+ if (of_get_property(node, "linux,dma-default", NULL)) {
WARN(dma_reserved_default_memory,
"Reserved memory: region for default DMA coherent area is redefined\n");
dma_reserved_default_memory = rmem;
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 055da410ac71..22507f7d74d9 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -456,8 +456,8 @@ static const struct reserved_mem_ops rmem_cma_ops = {
static int __init rmem_cma_setup(struct reserved_mem *rmem)
{
- unsigned long node = rmem->fdt_node;
- bool default_cma = of_get_flat_dt_prop(node, "linux,cma-default", NULL);
+ struct device_node *node = rmem->dev_node;
+ bool default_cma = of_get_property(node, "linux,cma-default", NULL);
struct cma *cma;
int err;
@@ -467,8 +467,8 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
return -EBUSY;
}
- if (!of_get_flat_dt_prop(node, "reusable", NULL) ||
- of_get_flat_dt_prop(node, "no-map", NULL))
+ if (!of_get_property(node, "reusable", NULL) ||
+ of_get_property(node, "no-map", NULL))
return -EINVAL;
if (!IS_ALIGNED(rmem->base | rmem->size, CMA_MIN_ALIGNMENT_BYTES)) {
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 86fe172b5958..22cf195f652c 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -1799,12 +1799,12 @@ static const struct reserved_mem_ops rmem_swiotlb_ops = {
static int __init rmem_swiotlb_setup(struct reserved_mem *rmem)
{
- unsigned long node = rmem->fdt_node;
+ struct device_node *node = rmem->dev_node;
- if (of_get_flat_dt_prop(node, "reusable", NULL) ||
- of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
- of_get_flat_dt_prop(node, "linux,dma-default", NULL) ||
- of_get_flat_dt_prop(node, "no-map", NULL))
+ if (of_get_property(node, "reusable", NULL) ||
+ of_get_property(node, "linux,cma-default", NULL) ||
+ of_get_property(node, "linux,dma-default", NULL) ||
+ of_get_property(node, "no-map", NULL))
return -EINVAL;
rmem->ops = &rmem_swiotlb_ops;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 4/4] of: reserved_mem: Rename fdt_* functions to refelct use of unflatten_devicetree APIs
From: Oreoluwa Babatunde @ 2024-03-28 21:15 UTC (permalink / raw)
To: catalin.marinas, will, robh+dt, frowand.list, vgupta, arnd, olof,
soc, guoren, monstr, palmer, aou, dinguyen, chenhuacai, tsbogend,
jonas, stefan.kristiansson, shorne, mpe, ysato, dalias, glaubitz,
richard, anton.ivanov, johannes, chris, jcmvbkbc
Cc: linux-arm-kernel, linux-kernel, devicetree, linux-arm-msm, kernel,
Oreoluwa Babatunde
In-Reply-To: <20240328211543.191876-1-quic_obabatun@quicinc.com>
Rename the relevant fdt_* functions to a new naming scheme, dt_*, to
reflect the use of the unflatten_devicetree APIs to scan through the
reserved memory regions defined in the DT.
Signed-off-by: Oreoluwa Babatunde <quic_obabatun@quicinc.com>
---
drivers/of/fdt.c | 2 +-
drivers/of/of_private.h | 2 +-
drivers/of/of_reserved_mem.c | 22 +++++++++++-----------
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 527e6bc1c096..7e1baf443286 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1259,7 +1259,7 @@ void __init unflatten_device_tree(void)
unittest_unflatten_overlay_base();
/* initialize the reserved memory regions */
- fdt_init_reserved_mem();
+ dt_init_reserved_mem();
}
/**
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 9ea250b80657..75726feac881 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -177,7 +177,7 @@ static inline struct device_node *__of_get_dma_parent(const struct device_node *
#endif
int fdt_scan_reserved_mem(void);
-void fdt_init_reserved_mem(void);
+void dt_init_reserved_mem(void);
bool of_fdt_device_is_available(const void *blob, unsigned long node);
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 68d1f4cca4bb..3ae5918a0024 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -97,10 +97,10 @@ static void __init alloc_reserved_mem_array(void)
}
/*
- * fdt_reserved_mem_save_node() - save fdt node for second pass initialization
+ * dt_reserved_mem_save_node() - save the device_node for second pass initialization
*/
-static void __init fdt_reserved_mem_save_node(struct device_node *node, const char *uname,
- phys_addr_t base, phys_addr_t size)
+static void __init dt_reserved_mem_save_node(struct device_node *node, const char *uname,
+ phys_addr_t base, phys_addr_t size)
{
struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
@@ -224,16 +224,16 @@ static int __init __dt_reserved_mem_check_root(struct device_node *node)
}
/**
- * fdt_scan_reserved_mem_reg_nodes() - Store info for the "reg" defined
+ * dt_scan_reserved_mem_reg_nodes() - Store info for the "reg" defined
* reserved memory regions.
*
* This function is used to scan through the DT and store the
* information for the reserved memory regions that are defined using
* the "reg" property. The region node number, name, base address, and
* size are all stored in the reserved_mem array by calling the
- * fdt_reserved_mem_save_node() function.
+ * dt_reserved_mem_save_node() function.
*/
-static void __init fdt_scan_reserved_mem_reg_nodes(void)
+static void __init dt_scan_reserved_mem_reg_nodes(void)
{
int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
struct device_node *node, *child;
@@ -277,7 +277,7 @@ static void __init fdt_scan_reserved_mem_reg_nodes(void)
size = dt_mem_next_cell(dt_root_size_cells, &prop);
if (size)
- fdt_reserved_mem_save_node(child, uname, base, size);
+ dt_reserved_mem_save_node(child, uname, base, size);
}
}
@@ -475,7 +475,7 @@ static int __init __reserved_mem_alloc_size(unsigned long node, const char *unam
uname, (unsigned long)(size / SZ_1M));
return -ENOMEM;
}
- fdt_reserved_mem_save_node(NULL, uname, base, size);
+ dt_reserved_mem_save_node(NULL, uname, base, size);
return 0;
}
@@ -559,15 +559,15 @@ static void __init __rmem_check_for_overlap(void)
}
/**
- * fdt_init_reserved_mem() - allocate and init all saved reserved memory regions
+ * dt_init_reserved_mem() - allocate and init all saved reserved memory regions
*/
-void __init fdt_init_reserved_mem(void)
+void __init dt_init_reserved_mem(void)
{
int i;
alloc_reserved_mem_array();
- fdt_scan_reserved_mem_reg_nodes();
+ dt_scan_reserved_mem_reg_nodes();
/* check for overlapping reserved regions */
__rmem_check_for_overlap();
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 1/4] of: reserved_mem: Restruture how the reserved memory regions are processed
From: Oreoluwa Babatunde @ 2024-03-28 21:15 UTC (permalink / raw)
To: catalin.marinas, will, robh+dt, frowand.list, vgupta, arnd, olof,
soc, guoren, monstr, palmer, aou, dinguyen, chenhuacai, tsbogend,
jonas, stefan.kristiansson, shorne, mpe, ysato, dalias, glaubitz,
richard, anton.ivanov, johannes, chris, jcmvbkbc
Cc: linux-arm-kernel, linux-kernel, devicetree, linux-arm-msm, kernel,
Oreoluwa Babatunde
In-Reply-To: <20240328211543.191876-1-quic_obabatun@quicinc.com>
The current implementation processes the reserved memory regions in two
stages which are done with two separate functions within the
early_init_fdt_scan_reserved_mem() function.
Within the two stages of processing, the reserved memory regions are
broken up into two groups which are processed differently:
i) Statically-placed reserved memory regions
i.e. regions defined with a static start address and size using the
"reg" property in the DT.
ii) Dynamically-placed reserved memory regions.
i.e. regions defined by specifying a range of addresses where they can
be placed in memory using the "alloc_ranges" and "size" properties
in the DT.
Stage 1: fdt_scan_reserved_mem()
This stage of the reserved memory processing is used to scan through the
reserved memory nodes defined in the devicetree and do the following on
each of the nodes:
1) If the node represents a statically-placed reserved memory region,
i.e. it is defined using the "reg" property:
- Call memblock_reserve() or memblock_mark_nomap() as needed.
- Add the information for the reserved region to the reserved_mem
array.
eg: fdt_reserved_mem_save_node(node, name, base, size);
2) If the node represents a dynamically-placed reserved memory region,
i.e. it is defined using "alloc-ranges" and "size" properties:
- Add the information for the region to the reserved_mem array with
the starting address and size set to 0.
eg: fdt_reserved_mem_save_node(node, name, 0, 0);
Stage 2: fdt_init_reserved_mem()
This stage of the reserved memory processing is used to iterate through
the reserved_mem array which was populated in stage 1 and do the
following on each of the entries:
1) If the entry represents a statically-placed reserved memory region:
- Call the region specific init function.
2) If the entry represents a dynamically-placed reserved memory region:
- Call __reserved_mem_alloc_size() which is used to allocate memory
for the region using memblock_phys_alloc_range(), and call
memblock_mark_nomap() on the allocated region if the region is
specified as a no-map region.
- Call the region specific init function.
On architectures such as arm64, the dynamic allocation of the
reserved_mem array needs to be done after the page tables have been
setup because memblock allocated memory is not writable until then. This
means that the reserved_mem array will not be available to store any
reserved memory information until after the page tables have been setup.
It is possible to call memblock_reserve() and memblock_mark_nomap() on
the statically-placed reserved memory regions and not need to save them
to the reserved_mem array until later. This is because all the
information we need is present in the devicetree.
Dynamically-placed reserved memory regions on the other hand get
assigned a start address only at runtime, and since memblock_reserve()
and memblock_mark_nomap() need to be called before the memory mappings
are created, the allocation needs to happen before the page tables are
setup.
To make it easier to handle dynamically-placed reserved memory regions
before the page tables are setup, this patch makes changes to the steps
above to process the reserved memory regions in the following ways:
Step 1: fdt_scan_reserved_mem()
This stage of the reserved memory processing is used to scan through the
reserved memory nodes defined in the devicetree and do the following on
each of the nodes:
1) If the node represents a statically-placed reserved memory region,
i.e. it is defined using the "reg" property:
- Call memblock_reserve() or memblock_mark_nomap() as needed.
2) If the node represents a dynamically-placed reserved memory region,
i.e. it is defined using "alloc-ranges" and "size" properties:
- Call __reserved_mem_alloc_size() which will:
i) Allocate memory for the reserved memory region.
ii) Call memblock_mark_nomap() as needed.
Note: There is no need to explicitly call memblock_reserve() here
because it is already called by memblock when the memory for the
region is being allocated.
iii) Save the information for the region in the reserved_mem array.
Step 2: fdt_init_reserved_mem()
This stage of the reserved memory processing is used to:
1) Add the information for the statically-placed reserved memory into
the reserved_mem array.
2) Iterate through all the entries in the array and call the region
specific init function for each of them.
fdt_init_reserved_mem() is also now called from within the
unflatten_device_tree() function so that this step happens after the
page tables have been setup.
Signed-off-by: Oreoluwa Babatunde <quic_obabatun@quicinc.com>
---
drivers/of/fdt.c | 5 +-
drivers/of/of_private.h | 1 +
drivers/of/of_reserved_mem.c | 134 +++++++++++++++++++++++++----------
3 files changed, 100 insertions(+), 40 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index a8a04f27915b..527e6bc1c096 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -532,8 +532,6 @@ void __init early_init_fdt_scan_reserved_mem(void)
break;
memblock_reserve(base, size);
}
-
- fdt_init_reserved_mem();
}
/**
@@ -1259,6 +1257,9 @@ void __init unflatten_device_tree(void)
of_alias_scan(early_init_dt_alloc_memory_arch);
unittest_unflatten_overlay_base();
+
+ /* initialize the reserved memory regions */
+ fdt_init_reserved_mem();
}
/**
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 485483524b7f..9ea250b80657 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -9,6 +9,7 @@
*/
#define FDT_ALIGN_SIZE 8
+#define MAX_RESERVED_REGIONS 64
/**
* struct alias_prop - Alias property in 'aliases' node
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 8236ecae2953..db991de16cc0 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -27,7 +27,6 @@
#include "of_private.h"
-#define MAX_RESERVED_REGIONS 64
static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
static int reserved_mem_count;
@@ -106,7 +105,6 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
phys_addr_t base, size;
int len;
const __be32 *prop;
- int first = 1;
bool nomap;
prop = of_get_flat_dt_prop(node, "reg", &len);
@@ -134,10 +132,6 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
uname, &base, (unsigned long)(size / SZ_1M));
len -= t_len;
- if (first) {
- fdt_reserved_mem_save_node(node, uname, base, size);
- first = 0;
- }
}
return 0;
}
@@ -165,12 +159,69 @@ static int __init __reserved_mem_check_root(unsigned long node)
return 0;
}
+/**
+ * fdt_scan_reserved_mem_reg_nodes() - Store info for the "reg" defined
+ * reserved memory regions.
+ *
+ * This function is used to scan through the DT and store the
+ * information for the reserved memory regions that are defined using
+ * the "reg" property. The region node number, name, base address, and
+ * size are all stored in the reserved_mem array by calling the
+ * fdt_reserved_mem_save_node() function.
+ */
+static void __init fdt_scan_reserved_mem_reg_nodes(void)
+{
+ int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
+ const void *fdt = initial_boot_params;
+ phys_addr_t base, size;
+ const __be32 *prop;
+ int node, child;
+ int len;
+
+ node = fdt_path_offset(fdt, "/reserved-memory");
+ if (node < 0) {
+ pr_info("Reserved memory: No reserved-memory node in the DT\n");
+ return;
+ }
+
+ if (__reserved_mem_check_root(node)) {
+ pr_err("Reserved memory: unsupported node format, ignoring\n");
+ return;
+ }
+
+ fdt_for_each_subnode(child, fdt, node) {
+ const char *uname;
+
+ prop = of_get_flat_dt_prop(child, "reg", &len);
+ if (!prop)
+ continue;
+ if (!of_fdt_device_is_available(fdt, child))
+ continue;
+
+ uname = fdt_get_name(fdt, child, NULL);
+ if (len && len % t_len != 0) {
+ pr_err("Reserved memory: invalid reg property in '%s', skipping node.\n",
+ uname);
+ continue;
+ }
+ base = dt_mem_next_cell(dt_root_addr_cells, &prop);
+ size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+ if (size)
+ fdt_reserved_mem_save_node(child, uname, base, size);
+ }
+}
+
+static int __init __reserved_mem_alloc_size(unsigned long node, const char *uname);
+
/*
* fdt_scan_reserved_mem() - scan a single FDT node for reserved memory
*/
int __init fdt_scan_reserved_mem(void)
{
int node, child;
+ int dynamic_nodes_cnt = 0;
+ int dynamic_nodes[MAX_RESERVED_REGIONS];
const void *fdt = initial_boot_params;
node = fdt_path_offset(fdt, "/reserved-memory");
@@ -192,8 +243,24 @@ int __init fdt_scan_reserved_mem(void)
uname = fdt_get_name(fdt, child, NULL);
err = __reserved_mem_reserve_reg(child, uname);
- if (err == -ENOENT && of_get_flat_dt_prop(child, "size", NULL))
- fdt_reserved_mem_save_node(child, uname, 0, 0);
+ /*
+ * Save the nodes for the dynamically-placed regions
+ * into an array which will be used for allocation right
+ * after all the statically-placed regions are reserved
+ * or marked as no-map. This is done to avoid dynamically
+ * allocating from one of the statically-placed regions.
+ */
+ if (err == -ENOENT && of_get_flat_dt_prop(child, "size", NULL)) {
+ dynamic_nodes[dynamic_nodes_cnt] = child;
+ dynamic_nodes_cnt++;
+ }
+ }
+ for (int i = 0; i < dynamic_nodes_cnt; i++) {
+ const char *uname;
+
+ child = dynamic_nodes[i];
+ uname = fdt_get_name(fdt, child, NULL);
+ __reserved_mem_alloc_size(child, uname);
}
return 0;
}
@@ -253,8 +320,7 @@ static int __init __reserved_mem_alloc_in_range(phys_addr_t size,
* __reserved_mem_alloc_size() - allocate reserved memory described by
* 'size', 'alignment' and 'alloc-ranges' properties.
*/
-static int __init __reserved_mem_alloc_size(unsigned long node,
- const char *uname, phys_addr_t *res_base, phys_addr_t *res_size)
+static int __init __reserved_mem_alloc_size(unsigned long node, const char *uname)
{
int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
phys_addr_t start = 0, end = 0;
@@ -333,10 +399,7 @@ static int __init __reserved_mem_alloc_size(unsigned long node,
uname, (unsigned long)(size / SZ_1M));
return -ENOMEM;
}
-
- *res_base = base;
- *res_size = size;
-
+ fdt_reserved_mem_save_node(node, uname, base, size);
return 0;
}
@@ -431,6 +494,8 @@ void __init fdt_init_reserved_mem(void)
{
int i;
+ fdt_scan_reserved_mem_reg_nodes();
+
/* check for overlapping reserved regions */
__rmem_check_for_overlap();
@@ -449,30 +514,23 @@ void __init fdt_init_reserved_mem(void)
if (prop)
rmem->phandle = of_read_number(prop, len/4);
- if (rmem->size == 0)
- err = __reserved_mem_alloc_size(node, rmem->name,
- &rmem->base, &rmem->size);
- if (err == 0) {
- err = __reserved_mem_init_node(rmem);
- if (err != 0 && err != -ENOENT) {
- pr_info("node %s compatible matching fail\n",
- rmem->name);
- if (nomap)
- memblock_clear_nomap(rmem->base, rmem->size);
- else
- memblock_phys_free(rmem->base,
- rmem->size);
- } else {
- phys_addr_t end = rmem->base + rmem->size - 1;
- bool reusable =
- (of_get_flat_dt_prop(node, "reusable", NULL)) != NULL;
-
- pr_info("%pa..%pa (%lu KiB) %s %s %s\n",
- &rmem->base, &end, (unsigned long)(rmem->size / SZ_1K),
- nomap ? "nomap" : "map",
- reusable ? "reusable" : "non-reusable",
- rmem->name ? rmem->name : "unknown");
- }
+ err = __reserved_mem_init_node(rmem);
+ if (err != 0 && err != -ENOENT) {
+ pr_info("node %s compatible matching fail\n", rmem->name);
+ if (nomap)
+ memblock_clear_nomap(rmem->base, rmem->size);
+ else
+ memblock_phys_free(rmem->base, rmem->size);
+ } else {
+ phys_addr_t end = rmem->base + rmem->size - 1;
+ bool reusable =
+ (of_get_flat_dt_prop(node, "reusable", NULL)) != NULL;
+
+ pr_info("%pa..%pa (%lu KiB) %s %s %s\n",
+ &rmem->base, &end, (unsigned long)(rmem->size / SZ_1K),
+ nomap ? "nomap" : "map",
+ reusable ? "reusable" : "non-reusable",
+ rmem->name ? rmem->name : "unknown");
}
}
}
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 2/4] of: reserved_mem: Add code to dynamically allocate reserved_mem array
From: Oreoluwa Babatunde @ 2024-03-28 21:15 UTC (permalink / raw)
To: catalin.marinas, will, robh+dt, frowand.list, vgupta, arnd, olof,
soc, guoren, monstr, palmer, aou, dinguyen, chenhuacai, tsbogend,
jonas, stefan.kristiansson, shorne, mpe, ysato, dalias, glaubitz,
richard, anton.ivanov, johannes, chris, jcmvbkbc
Cc: linux-arm-kernel, linux-kernel, devicetree, linux-arm-msm, kernel,
Oreoluwa Babatunde
In-Reply-To: <20240328211543.191876-1-quic_obabatun@quicinc.com>
The reserved_mem array is statically allocated with a size of
MAX_RESERVED_REGIONS(64). Therefore, if the number of reserved_mem
regions exceeds this size, there will not be enough space to store
all the data.
Hence, extend the use of the static array by introducing a
dynamically allocated array based on the number of reserved memory
regions specified in the DT.
On architectures such as arm64, memblock allocated memory is not
writable until after the page tables have been setup. Hence, the
dynamic allocation of the reserved_mem array will need to be done only
after the page tables have been setup.
As a result, a temporary static array is still needed in the initial
stages to store the information of the dynamically-placed reserved
memory regions because the start address is selected only at run-time
and is not stored anywhere else.
It is not possible to wait until the reserved_mem array is allocated
because this is done after the page tables are setup and the reserved
memory regions need to be initialized before then.
After the reserved_mem array is allocated, all entries from the static
array is copied over to the new array, and the rest of the information
for the statically-placed reserved memory regions are read in from the
DT and stored in the new array as well.
Once the init process is completed, the temporary static array is
released back to the system because it is no longer needed. This is
achieved by marking it as __initdata.
Signed-off-by: Oreoluwa Babatunde <quic_obabatun@quicinc.com>
---
drivers/of/of_reserved_mem.c | 58 +++++++++++++++++++++++++++++++++---
1 file changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index db991de16cc0..0aba366eba59 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -27,7 +27,9 @@
#include "of_private.h"
-static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
+static struct reserved_mem reserved_mem_array[MAX_RESERVED_REGIONS] __initdata;
+static struct reserved_mem *reserved_mem __refdata = reserved_mem_array;
+static int total_reserved_mem_cnt = MAX_RESERVED_REGIONS;
static int reserved_mem_count;
static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
@@ -55,6 +57,45 @@ static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
return err;
}
+/*
+ * alloc_reserved_mem_array() - allocate memory for the reserved_mem
+ * array using memblock
+ *
+ * This function is used to allocate memory for the reserved_mem array
+ * according to the total number of reserved memory regions defined in
+ * the DT.
+ * After the new array is allocated, the information stored in the
+ * initial static array is copied over to this new array and the new
+ * array is used from this point on.
+ */
+static void __init alloc_reserved_mem_array(void)
+{
+ struct reserved_mem *new_array;
+ size_t alloc_size, copy_size, memset_size;
+
+ alloc_size = array_size(total_reserved_mem_cnt, sizeof(*new_array));
+ if (alloc_size == SIZE_MAX)
+ pr_err("Failed to allocate memory for reserved_mem array with err: %d", -EOVERFLOW);
+
+ new_array = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
+ if (!new_array)
+ pr_err("Failed to allocate memory for reserved_mem array with err: %d", -ENOMEM);
+
+ copy_size = array_size(reserved_mem_count, sizeof(*new_array));
+ if (copy_size == SIZE_MAX) {
+ memblock_free(new_array, alloc_size);
+ total_reserved_mem_cnt = MAX_RESERVED_REGIONS;
+ pr_err("Failed to allocate memory for reserved_mem array with err: %d", -EOVERFLOW);
+ }
+
+ memset_size = alloc_size - copy_size;
+
+ memcpy(new_array, reserved_mem, copy_size);
+ memset(new_array + reserved_mem_count, 0, memset_size);
+
+ reserved_mem = new_array;
+}
+
/*
* fdt_reserved_mem_save_node() - save fdt node for second pass initialization
*/
@@ -63,7 +104,7 @@ static void __init fdt_reserved_mem_save_node(unsigned long node, const char *un
{
struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
- if (reserved_mem_count == ARRAY_SIZE(reserved_mem)) {
+ if (reserved_mem_count == total_reserved_mem_cnt) {
pr_err("not enough space for all defined regions.\n");
return;
}
@@ -220,7 +261,7 @@ static int __init __reserved_mem_alloc_size(unsigned long node, const char *unam
int __init fdt_scan_reserved_mem(void)
{
int node, child;
- int dynamic_nodes_cnt = 0;
+ int dynamic_nodes_cnt = 0, count = 0;
int dynamic_nodes[MAX_RESERVED_REGIONS];
const void *fdt = initial_boot_params;
@@ -243,6 +284,8 @@ int __init fdt_scan_reserved_mem(void)
uname = fdt_get_name(fdt, child, NULL);
err = __reserved_mem_reserve_reg(child, uname);
+ if (!err)
+ count++;
/*
* Save the nodes for the dynamically-placed regions
* into an array which will be used for allocation right
@@ -257,11 +300,16 @@ int __init fdt_scan_reserved_mem(void)
}
for (int i = 0; i < dynamic_nodes_cnt; i++) {
const char *uname;
+ int err;
child = dynamic_nodes[i];
uname = fdt_get_name(fdt, child, NULL);
- __reserved_mem_alloc_size(child, uname);
+
+ err = __reserved_mem_alloc_size(child, uname);
+ if (!err)
+ count++;
}
+ total_reserved_mem_cnt = count++;
return 0;
}
@@ -494,6 +542,8 @@ void __init fdt_init_reserved_mem(void)
{
int i;
+ alloc_reserved_mem_array();
+
fdt_scan_reserved_mem_reg_nodes();
/* check for overlapping reserved regions */
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 0/4] Dynamic Allocation of the reserved_mem array
From: Oreoluwa Babatunde @ 2024-03-28 21:15 UTC (permalink / raw)
To: catalin.marinas, will, robh+dt, frowand.list, vgupta, arnd, olof,
soc, guoren, monstr, palmer, aou, dinguyen, chenhuacai, tsbogend,
jonas, stefan.kristiansson, shorne, mpe, ysato, dalias, glaubitz,
richard, anton.ivanov, johannes, chris, jcmvbkbc
Cc: linux-arm-kernel, linux-kernel, devicetree, linux-arm-msm, kernel,
Oreoluwa Babatunde
The reserved_mem array is used to store data for the different
reserved memory regions defined in the DT of a device. The array
stores information such as region name, node reference, start-address,
and size of the different reserved memory regions.
The array is currently statically allocated with a size of
MAX_RESERVED_REGIONS(64). This means that any system that specifies a
number of reserved memory regions greater than MAX_RESERVED_REGIONS(64)
will not have enough space to store the information for all the regions.
This can be fixed by making the reserved_mem array a dynamically sized
array which is allocated using memblock_alloc() based on the exact
number of reserved memory regions defined in the DT.
On architectures such as arm64, memblock allocated memory is not
writable until after the page tables have been setup.
This is an issue because the current implementation initializes the
reserved memory regions and stores their information in the array before
the page tables are setup. Hence, dynamically allocating the
reserved_mem array and attempting to write information to it at this
point will fail.
Therefore, the allocation of the reserved_mem array will need to be done
after the page tables have been setup, which means that the reserved
memory regions will also need to wait until after the page tables have
been setup to be stored in the array.
When processing the reserved memory regions defined in the DT, these
regions are marked as reserved by calling memblock_reserve(base, size).
Where: base = base address of the reserved region.
size = the size of the reserved memory region.
Depending on if that region is defined using the "no-map" property,
memblock_mark_nomap(base, size) is also called.
The "no-map" property is used to indicate to the operating system that a
mapping of the specified region must NOT be created. This also means
that no access (including speculative accesses) is allowed on this
region of memory except when it is coming from the device driver that
this region of memory is being reserved for.[1]
Therefore, it is important to call memblock_reserve() and
memblock_mark_nomap() on all the reserved memory regions before the
system sets up the page tables so that the system does not unknowingly
include any of the no-map reserved memory regions in the memory map.
There are two ways to define how/where a reserved memory region is
placed in memory:
i) Statically-placed reserved memory regions
i.e. regions defined with a set start address and size using the
"reg" property in the DT.
ii) Dynamically-placed reserved memory regions.
i.e. regions defined by specifying a range of addresses where they can
be placed in memory using the "alloc_ranges" and "size" properties
in the DT.
The dynamically-placed reserved memory regions get assigned a start
address only at runtime. And this needs to be done before the page
tables are setup so that memblock_reserve() and memblock_mark_nomap()
can be called on the allocated region as explained above.
Since the dynamically allocated reserved_mem array can only available
after the page tables have been setup, the information for the
dynamically-placed reserved memory regions needs to be stored somewhere
temporarily until the reserved_mem array is available.
Therefore, this series makes use of a temporary static array to store
the information of the dynamically-placed reserved memory regions until
the reserved_mem array is allocated.
Once the reserved_mem array is available, the information is copied over
from the temporary array into the reserved_mem array, and the memory for
the temporary array is freed back to the system.
The information for the statically-placed reserved memory regions does
not need to be stored in a temporary array because their starting
address is already stored in the devicetree.
Hence, the only thing that needs to be done for these regions before the
page tables are setup is to call memblock_reserve() and
memblock_mark_nomap().
Once the reserved_mem array is allocated, the information for the
statically-placed reserved memory regions is added to the array.
Note:
Because of the use of a temporary array to store the information of the
dynamically-placed reserved memory regions, there still exists a
limitation of 64 for this particular kind of reserved memory regions.
From my observation, these regions are typically small in number and
hence I expect this to not be an issue for now.
Dependency:
This series is dependent on the acceptance of the below patchset for
proper behavior on the sh architecture. The patchset has already been
sent out and is pending review from the sh maintainters.
https://lore.kernel.org/all/1707524971-146908-1-git-send-email-quic_obabatun@quicinc.com/
Patch Versions:
v5 (Current Patchset):
- Rebased changes on top of v6.9-rc1.
- Addressed minor code comments from v4.
v4:
- Move fdt_init_reserved_mem() back into the unflatten_device_tree()
function.
- Fix warnings found by Kernel test robot:
https://lore.kernel.org/all/202401281219.iIhqs1Si-lkp@intel.com/
https://lore.kernel.org/all/202401281304.tsu89Kcm-lkp@intel.com/
https://lore.kernel.org/all/202401291128.e7tdNh5x-lkp@intel.com/
v3:
https://lore.kernel.org/all/20240126235425.12233-1-quic_obabatun@quicinc.com/
- Make use of __initdata to delete the temporary static array after
dynamically allocating memory for reserved_mem array using memblock.
- Move call to fdt_init_reserved_mem() out of the
unflatten_device_tree() function and into architecture specific setup
code.
- Breaking up the changes for the individual architectures into separate
patches.
v2:
https://lore.kernel.org/all/20231204041339.9902-1-quic_obabatun@quicinc.com/
- Extend changes to all other relevant architectures by moving
fdt_init_reserved_mem() into the unflatten_device_tree() function.
- Add code to use unflatten devicetree APIs to process the reserved
memory regions.
v1:
https://lore.kernel.org/all/20231019184825.9712-1-quic_obabatun@quicinc.com/
References:
[1]
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reserved-memory/reserved-memory.yaml#L79
Oreoluwa Babatunde (4):
of: reserved_mem: Restruture how the reserved memory regions are
processed
of: reserved_mem: Add code to dynamically allocate reserved_mem array
of: reserved_mem: Use the unflatten_devicetree APIs to scan reserved
mem. nodes
of: reserved_mem: Rename fdt_* functions to refelct use of
unflatten_devicetree APIs
drivers/of/fdt.c | 5 +-
drivers/of/of_private.h | 3 +-
drivers/of/of_reserved_mem.c | 249 ++++++++++++++++++++++++--------
include/linux/of_reserved_mem.h | 2 +-
kernel/dma/coherent.c | 8 +-
kernel/dma/contiguous.c | 8 +-
kernel/dma/swiotlb.c | 10 +-
7 files changed, 209 insertions(+), 76 deletions(-)
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: vendor-prefixes: Add Emcraft Systems
From: Krzysztof Kozlowski @ 2024-03-28 22:00 UTC (permalink / raw)
To: Gilles Talis, devicetree, imx, linux-arm-kernel
Cc: conor+dt, krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex
In-Reply-To: <20240328202320.187596-2-gilles.talis@gmail.com>
On 28/03/2024 21:23, Gilles Talis wrote:
> Add an entry for Emcraft Systems (https://www.emcraft.com/)
>
> Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
This is an automated instruction, just in case, because many review tags
are being ignored. If you know the process, you can skip it (please do
not feel offended by me posting it here - no bad intentions intended).
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.
https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: arm: Add Emcraft Systems i.MX8M Plus NavQ+ Kit
From: Krzysztof Kozlowski @ 2024-03-28 22:00 UTC (permalink / raw)
To: Gilles Talis, devicetree, imx, linux-arm-kernel
Cc: conor+dt, krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex
In-Reply-To: <20240328202320.187596-3-gilles.talis@gmail.com>
On 28/03/2024 21:23, Gilles Talis wrote:
> Add DT compatible string for Emcraft NavQ+ kit based on
> the i.MX8M Plus SoC from NXP
>
> Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 22/23] drivers: media: i2c: imx258: Add support for powerdown gpio
From: Rob Herring @ 2024-03-28 20:48 UTC (permalink / raw)
To: git
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, Ondrej Jirman
In-Reply-To: <20240327231710.53188-23-git@luigi311.com>
On Wed, Mar 27, 2024 at 05:17:08PM -0600, git@luigi311.com wrote:
> From: Luigi311 <git@luigi311.com>
>
> On some boards powerdown signal needs to be deasserted for this
> sensor to be enabled.
>
> Signed-off-by: Ondrej Jirman <megi@xff.cz>
> ---
> .../devicetree/bindings/media/i2c/sony,imx258.yaml | 4 ++++
Bindings should be a separate patch.
> drivers/media/i2c/imx258.c | 13 +++++++++++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> index c7856de15ba3..0414085bf22f 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> @@ -35,6 +35,10 @@ properties:
> reg:
> maxItems: 1
>
> + powerdown-gpios:
> + description: |-
Don't need '|-' if no formatting.
> + Reference to the GPIO connected to the PWDN pin, if any.
> +
> reset-gpios:
> description: |-
> Reference to the GPIO connected to the XCLR pin, if any.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
From: Krzysztof Kozlowski @ 2024-03-28 22:04 UTC (permalink / raw)
To: Gilles Talis, devicetree, imx, linux-arm-kernel
Cc: conor+dt, krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex
In-Reply-To: <20240328202320.187596-4-gilles.talis@gmail.com>
On 28/03/2024 21:23, Gilles Talis wrote:
> The Emcraft Systems NavQ+ kit is a mobile robotics platform
> based on NXP i.MX8 MPlus SoC.
>
> The following interfaces and devices are enabled:
> - eMMC
> - Gigabit Ethernet
> - RTC
> - SD-Card
> - UART console
>
> Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> .../arm64/boot/dts/freescale/imx8mp-navqp.dts | 435 ++++++++++++++++++
> 2 files changed, 436 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 045250d0a040..bf99864c0bc4 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -166,6 +166,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-pdk3.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-icore-mx8mp-edimm2.2.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-msc-sm2s-ep1.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8mp-navqp.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-phyboard-pollux-rdk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-hdmi.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-lt6.dtb
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts b/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
> new file mode 100644
> index 000000000000..8182e71008f8
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
> @@ -0,0 +1,435 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2021 Emcraft Systems
> + * Copyright 2024 Gilles Talis <gilles.talis@gmail.com>
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include "imx8mp.dtsi"
> +
> +/ {
> + model = "Emcraft Systems i.MX8MPlus NavQ+ Kit";
> + compatible = "emcraft,imx8mp-navqp", "fsl,imx8mp";
> +
> + chosen {
> + stdout-path = &uart2;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_led>;
> +
> + status {
It does not look like you tested the DTS against bindings. Please run
`make dtbs_check W=1` (see
Documentation/devicetree/bindings/writing-schema.rst or
https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
for instructions).
> + label = "status";
Please provide color and function properties, if reasonable, and then
remove label property.
> + gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> + };
> +
...
> + pinctrl_i2c6: i2c6grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_UART4_RXD__I2C6_SCL 0x400001c3
> + MX8MP_IOMUXC_UART4_TXD__I2C6_SDA 0x400001c3
> + >;
> + };
> +
> + pinctrl_pmic: pmicirq {
> + fsl,pins = <
> + MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
> + >;
> + };
> +
> + pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_SD2_RESET_B__GPIO2_IO19 0x41
> + >;
> + };
> +
> + pinctrl_uart2: uart2grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x49
> + MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x49
> + >;
> + };
> +
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x190
> + MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d0
> + MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d0
> + MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d0
> + MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d0
> + MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d0
> + MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc1
> + >;
> + };
> +
> + pinctrl_usdhc2_100mhz: usdhc2grp-100mhz {
Hm, you upstreamed something based on downstream source. Please avoid
that. Instead take upstream, clean DTS and customize it to your needs.
Otherwise you send patch with the same issues we fixed.
Standard form letter:
It does not look like you tested the DTS against bindings. Please run
`make dtbs_check W=1` (see
Documentation/devicetree/bindings/writing-schema.rst or
https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
for instructions).
Nodes end on 'grp' I believe.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 18/18] PCI: j721e: Add suspend and resume support
From: Bjorn Helgaas @ 2024-03-28 22:07 UTC (permalink / raw)
To: Thomas Richard
Cc: Linus Walleij, Bartosz Golaszewski, Andy Shevchenko,
Tony Lindgren, Haojian Zhuang, Vignesh R, Aaro Koskinen,
Janusz Krzysztofik, Andi Shyti, Peter Rosin, Vinod Koul,
Kishon Vijay Abraham I, Philipp Zabel, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, linux-gpio,
linux-kernel, linux-arm-kernel, linux-omap, linux-i2c, linux-phy,
linux-pci, gregory.clement, theo.lebrun, thomas.petazzoni,
u-kumar1
In-Reply-To: <20240102-j7200-pcie-s2r-v4-18-6f1f53390c85@bootlin.com>
On Mon, Mar 04, 2024 at 04:36:01PM +0100, Thomas Richard wrote:
> From: Théo Lebrun <theo.lebrun@bootlin.com>
>
> Add suspend and resume support. Only the rc mode is supported.
>
> During the suspend stage PERST# is asserted, then deasserted during the
> resume stage.
> + * "Power Sequencing and Reset Signal Timings" table in
> + * PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION, REV. 3.0
> + * indicates PERST# should be deasserted after minimum of 100us
> + * once REFCLK is stable. The REFCLK to the connector in RC
> + * mode is selected while enabling the PHY. So deassert PERST#
> + * after 100 us.
Please cite current spec (r5.1 was published August 2023), section,
and parameter name. I think this is T_PERST-CLK, "REFCLK stable
before PERST# inactive", from sec 2.9.2.
> + */
> + if (pcie->reset_gpio) {
> + fsleep(100);
I'd like to see a macro used here instead of a bare number. Since
this isn't anything specific to j721e, maybe add something like
#define PCIE_T_PERST_CLK_US alongside PCIE_T_PVPERL_MS.
> + gpiod_set_value_cansleep(pcie->reset_gpio, 1);
> + }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: thermal: amlogic: add support for A1 thermal sensor
From: Conor Dooley @ 2024-03-28 22:21 UTC (permalink / raw)
To: Dmitry Rokosov
Cc: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt, kernel, rockosov, linux-amlogic,
linux-pm, linux-kernel, devicetree, linux-arm-kernel
In-Reply-To: <20240328191322.17551-2-ddrokosov@salutedevices.com>
[-- Attachment #1.1: Type: text/plain, Size: 337 bytes --]
On Thu, Mar 28, 2024 at 10:13:10PM +0300, Dmitry Rokosov wrote:
> Provide right compatible properties for Amlogic A1 Thermal Sensor
> controller. A1 family supports only one thermal node - CPU thermal
> sensor.
>
> Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
From: Fabio Estevam @ 2024-03-28 22:55 UTC (permalink / raw)
To: Gilles Talis
Cc: devicetree, imx, linux-arm-kernel, conor+dt,
krzysztof.kozlowski+dt, robh, shawnguo, alex
In-Reply-To: <20240328202320.187596-4-gilles.talis@gmail.com>
On Thu, Mar 28, 2024 at 5:23 PM Gilles Talis <gilles.talis@gmail.com> wrote:
> + pinctrl_i2c6: i2c6grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_UART4_RXD__I2C6_SCL 0x400001c3
> + MX8MP_IOMUXC_UART4_TXD__I2C6_SDA 0x400001c3
If i2c6 is not used, you can drop its pinctrl entry.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: (subset) [PATCH 0/7] sysctl: Remove sentinel elements from misc directories
From: Jens Axboe @ 2024-03-28 23:05 UTC (permalink / raw)
To: Andrew Morton, Muchun Song, Miaohe Lin, Naoya Horiguchi,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
David Howells, Jarkko Sakkinen, Kees Cook, Herbert Xu,
David S. Miller, Pavel Begunkov, Atish Patra, Anup Patel,
Will Deacon, Mark Rutland, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Joel Granados
Cc: Luis Chamberlain, linux-mm, linux-kernel, linux-fsdevel, apparmor,
linux-security-module, keyrings, linux-crypto, io-uring,
linux-riscv, linux-arm-kernel
In-Reply-To: <20240328-jag-sysctl_remset_misc-v1-0-47c1463b3af2@samsung.com>
On Thu, 28 Mar 2024 16:57:47 +0100, Joel Granados wrote:
> What?
> These commits remove the sentinel element (last empty element) from the
> sysctl arrays of all the files under the "mm/", "security/", "ipc/",
> "init/", "io_uring/", "drivers/perf/" and "crypto/" directories that
> register a sysctl array. The inclusion of [4] to mainline allows the
> removal of sentinel elements without behavioral change. This is safe
> because the sysctl registration code (register_sysctl() and friends) use
> the array size in addition to checking for a sentinel [1].
>
> [...]
Applied, thanks!
[6/7] io_uring: Remove the now superfluous sentinel elements from ctl_table array
(no commit info)
Best regards,
--
Jens Axboe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 08/23] media: i2c: imx258: Add support for 24MHz clock
From: Luigi311 @ 2024-03-28 23:03 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <11f2e7d8-fd4c-4e14-81d8-cbc2cd2442fa@luigi311.com>
On 3/28/24 11:55, Luigi311 wrote:
> On 3/28/24 02:09, Sakari Ailus wrote:
>> Hi Luigi311,
>>
>> Thank you for the patchset.
>>
>> On Wed, Mar 27, 2024 at 05:16:54PM -0600, git@luigi311.com wrote:
>>> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>>>
>>> There's no reason why only a clock of 19.2MHz is supported.
>>> Indeed this isn't even a frequency listed in the datasheet.
>>>
>>> Add support for 24MHz as well.
>>> The PLL settings result in slightly different link frequencies,
>>> so parameterise those.
>>>
>>> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
>>> Signed-off-by: Luigi311 <git@luigi311.com>
>>
>> Is Luigi311 your real name? As per
>> Documentation/process/submitting-patches.rst, anonymous (or pseudonym I'd
>> say as well) contributions are not an option.
>
> Luigi311 is not my real name but it would be a lot easier to find me if
> it was. My real name is Luis Garcia which is a super common name so its
> actually way easier to find me and all my work using my online name of
> Luigi311. I can go ahead and swap over to Luis Garcia if required but a
> name like that would provide no value in contacting/finding me since I'm
> not famous like all the other Luis Garcia's that appear on google.
>
>>
>>> ---
>>> drivers/media/i2c/imx258.c | 133 +++++++++++++++++++++++++++++--------
>>> 1 file changed, 107 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
>>> index 351add1bc5d5..6ee7de079454 100644
>>> --- a/drivers/media/i2c/imx258.c
>>> +++ b/drivers/media/i2c/imx258.c
>>> @@ -76,9 +76,6 @@
>>> #define REG_CONFIG_MIRROR_FLIP 0x03
>>> #define REG_CONFIG_FLIP_TEST_PATTERN 0x02
>>>
>>> -/* Input clock frequency in Hz */
>>> -#define IMX258_INPUT_CLOCK_FREQ 19200000
>>> -
>>> struct imx258_reg {
>>> u16 address;
>>> u8 val;
>>> @@ -115,7 +112,9 @@ struct imx258_mode {
>>> };
>>>
>>> /* 4208x3120 needs 1267Mbps/lane, 4 lanes */
>>> -static const struct imx258_reg mipi_data_rate_1267mbps[] = {
>>> +static const struct imx258_reg mipi_1267mbps_19_2mhz[] = {
>>> + { 0x0136, 0x13 },
>>> + { 0x0137, 0x33 },
>>> { 0x0301, 0x05 },
>>> { 0x0303, 0x02 },
>>> { 0x0305, 0x03 },
>>> @@ -133,7 +132,29 @@ static const struct imx258_reg mipi_data_rate_1267mbps[] = {
>>> { 0x0823, 0xCC },
>>> };
>>>
>>> -static const struct imx258_reg mipi_data_rate_640mbps[] = {
>>> +static const struct imx258_reg mipi_1272mbps_24mhz[] = {
>>> + { 0x0136, 0x18 },
>>> + { 0x0137, 0x00 },
>>> + { 0x0301, 0x05 },
>>> + { 0x0303, 0x02 },
>>> + { 0x0305, 0x04 },
>>> + { 0x0306, 0x00 },
>>> + { 0x0307, 0xD4 },
>>> + { 0x0309, 0x0A },
>>> + { 0x030B, 0x01 },
>>> + { 0x030D, 0x02 },
>>> + { 0x030E, 0x00 },
>>> + { 0x030F, 0xD8 },
>>> + { 0x0310, 0x00 },
>>> + { 0x0820, 0x13 },
>>> + { 0x0821, 0x4C },
>>> + { 0x0822, 0xCC },
>>> + { 0x0823, 0xCC },
>>> +};
>>> +
>>> +static const struct imx258_reg mipi_640mbps_19_2mhz[] = {
>>> + { 0x0136, 0x13 },
>>> + { 0x0137, 0x33 },
>>> { 0x0301, 0x05 },
>>> { 0x0303, 0x02 },
>>> { 0x0305, 0x03 },
>>> @@ -151,9 +172,27 @@ static const struct imx258_reg mipi_data_rate_640mbps[] = {
>>> { 0x0823, 0x00 },
>>> };
>>>
>>> +static const struct imx258_reg mipi_642mbps_24mhz[] = {
>>> + { 0x0136, 0x18 },
>>> + { 0x0137, 0x00 },
>>> + { 0x0301, 0x05 },
>>> + { 0x0303, 0x02 },
>>> + { 0x0305, 0x04 },
>>> + { 0x0306, 0x00 },
>>> + { 0x0307, 0x6B },
>>> + { 0x0309, 0x0A },
>>> + { 0x030B, 0x01 },
>>> + { 0x030D, 0x02 },
>>> + { 0x030E, 0x00 },
>>> + { 0x030F, 0xD8 },
>>> + { 0x0310, 0x00 },
>>> + { 0x0820, 0x0A },
>>> + { 0x0821, 0x00 },
>>> + { 0x0822, 0x00 },
>>> + { 0x0823, 0x00 },
>>> +};
>>> +
>>> static const struct imx258_reg mode_common_regs[] = {
>>> - { 0x0136, 0x13 },
>>> - { 0x0137, 0x33 },
>>> { 0x3051, 0x00 },
>>> { 0x3052, 0x00 },
>>> { 0x4E21, 0x14 },
>>> @@ -313,10 +352,6 @@ static const char * const imx258_supply_name[] = {
>>>
>>> #define IMX258_NUM_SUPPLIES ARRAY_SIZE(imx258_supply_name)
>>>
>>> -/* Configurations for supported link frequencies */
>>> -#define IMX258_LINK_FREQ_634MHZ 633600000ULL
>>> -#define IMX258_LINK_FREQ_320MHZ 320000000ULL
>>> -
>>> enum {
>>> IMX258_LINK_FREQ_1267MBPS,
>>> IMX258_LINK_FREQ_640MBPS,
>>> @@ -335,25 +370,55 @@ static u64 link_freq_to_pixel_rate(u64 f)
>>> }
>>>
>>> /* Menu items for LINK_FREQ V4L2 control */
>>> -static const s64 link_freq_menu_items[] = {
>>> +/* Configurations for supported link frequencies */
>>> +#define IMX258_LINK_FREQ_634MHZ 633600000ULL
>>> +#define IMX258_LINK_FREQ_320MHZ 320000000ULL
>>> +
>>> +static const s64 link_freq_menu_items_19_2[] = {
>>> IMX258_LINK_FREQ_634MHZ,
>>> IMX258_LINK_FREQ_320MHZ,
>>> };
>>>
>>> +/* Configurations for supported link frequencies */
>>> +#define IMX258_LINK_FREQ_636MHZ 636000000ULL
>>> +#define IMX258_LINK_FREQ_321MHZ 321000000ULL
>>
>> These values aren't used outside the array below and the macro names are
>> imprecise anyway. Could you put the numerical values to the array instead?
>
> Ok I've removed the defines and just threw the values into the array instead.
>
>>
>>> +
>>> +static const s64 link_freq_menu_items_24[] = {
>>> + IMX258_LINK_FREQ_636MHZ,
>>> + IMX258_LINK_FREQ_321MHZ,
>>> +};
>>> +
>>> /* Link frequency configs */
>>> -static const struct imx258_link_freq_config link_freq_configs[] = {
>>> +static const struct imx258_link_freq_config link_freq_configs_19_2[] = {
>>> [IMX258_LINK_FREQ_1267MBPS] = {
>>> .pixels_per_line = IMX258_PPL_DEFAULT,
>>> .reg_list = {
>>> - .num_of_regs = ARRAY_SIZE(mipi_data_rate_1267mbps),
>>> - .regs = mipi_data_rate_1267mbps,
>>> + .num_of_regs = ARRAY_SIZE(mipi_1267mbps_19_2mhz),
>>> + .regs = mipi_1267mbps_19_2mhz,
>>> }
>>> },
>>> [IMX258_LINK_FREQ_640MBPS] = {
>>> .pixels_per_line = IMX258_PPL_DEFAULT,
>>> .reg_list = {
>>> - .num_of_regs = ARRAY_SIZE(mipi_data_rate_640mbps),
>>> - .regs = mipi_data_rate_640mbps,
>>> + .num_of_regs = ARRAY_SIZE(mipi_640mbps_19_2mhz),
>>> + .regs = mipi_640mbps_19_2mhz,
>>> + }
>>> + },
>>> +};
>>> +
>>> +static const struct imx258_link_freq_config link_freq_configs_24[] = {
>>> + [IMX258_LINK_FREQ_1267MBPS] = {
>>> + .pixels_per_line = IMX258_PPL_DEFAULT,
>>> + .reg_list = {
>>> + .num_of_regs = ARRAY_SIZE(mipi_1272mbps_24mhz),
>>> + .regs = mipi_1272mbps_24mhz,
>>> + }
>>> + },
>>> + [IMX258_LINK_FREQ_640MBPS] = {
>>> + .pixels_per_line = IMX258_PPL_DEFAULT,
>>> + .reg_list = {
>>> + .num_of_regs = ARRAY_SIZE(mipi_642mbps_24mhz),
>>> + .regs = mipi_642mbps_24mhz,
>>> }
>>> },
>>> };
>>> @@ -410,6 +475,9 @@ struct imx258 {
>>> /* Current mode */
>>> const struct imx258_mode *cur_mode;
>>>
>>> + const struct imx258_link_freq_config *link_freq_configs;
>>> + const s64 *link_freq_menu_items;
>>> +
>>> /*
>>> * Mutex for serialized access:
>>> * Protect sensor module set pad format and start/stop streaming safely.
>>> @@ -713,7 +781,7 @@ static int imx258_set_pad_format(struct v4l2_subdev *sd,
>>> imx258->cur_mode = mode;
>>> __v4l2_ctrl_s_ctrl(imx258->link_freq, mode->link_freq_index);
>>>
>>> - link_freq = link_freq_menu_items[mode->link_freq_index];
>>> + link_freq = imx258->link_freq_menu_items[mode->link_freq_index];
>>> pixel_rate = link_freq_to_pixel_rate(link_freq);
>>> __v4l2_ctrl_s_ctrl_int64(imx258->pixel_rate, pixel_rate);
>>> /* Update limits and set FPS to default */
>>> @@ -727,7 +795,7 @@ static int imx258_set_pad_format(struct v4l2_subdev *sd,
>>> vblank_def);
>>> __v4l2_ctrl_s_ctrl(imx258->vblank, vblank_def);
>>> h_blank =
>>> - link_freq_configs[mode->link_freq_index].pixels_per_line
>>> + imx258->link_freq_configs[mode->link_freq_index].pixels_per_line
>>> - imx258->cur_mode->width;
>>> __v4l2_ctrl_modify_range(imx258->hblank, h_blank,
>>> h_blank, 1, h_blank);
>>> @@ -747,7 +815,7 @@ static int imx258_start_streaming(struct imx258 *imx258)
>>>
>>> /* Setup PLL */
>>> link_freq_index = imx258->cur_mode->link_freq_index;
>>> - reg_list = &link_freq_configs[link_freq_index].reg_list;
>>> + reg_list = &imx258->link_freq_configs[link_freq_index].reg_list;
>>> ret = imx258_write_regs(imx258, reg_list->regs, reg_list->num_of_regs);
>>> if (ret) {
>>> dev_err(&client->dev, "%s failed to set plls\n", __func__);
>>> @@ -946,9 +1014,9 @@ static int imx258_init_controls(struct imx258 *imx258)
>>> imx258->link_freq = v4l2_ctrl_new_int_menu(ctrl_hdlr,
>>> &imx258_ctrl_ops,
>>> V4L2_CID_LINK_FREQ,
>>> - ARRAY_SIZE(link_freq_menu_items) - 1,
>>> + ARRAY_SIZE(link_freq_menu_items_19_2) - 1,
>>> 0,
>>> - link_freq_menu_items);
>>> + imx258->link_freq_menu_items);
>>>
>>> if (imx258->link_freq)
>>> imx258->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>>> @@ -964,8 +1032,10 @@ static int imx258_init_controls(struct imx258 *imx258)
>>> if (vflip)
>>> vflip->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>>>
>>> - pixel_rate_max = link_freq_to_pixel_rate(link_freq_menu_items[0]);
>>> - pixel_rate_min = link_freq_to_pixel_rate(link_freq_menu_items[1]);
>>> + pixel_rate_max =
>>> + link_freq_to_pixel_rate(imx258->link_freq_menu_items[0]);
>>> + pixel_rate_min =
>>> + link_freq_to_pixel_rate(imx258->link_freq_menu_items[1]);
>>
>> The arrays currently have two entries so this works but it'd nice to have a
>> bit more robust way to handle differences between the two arrays. Could you
>> maintain e.g. the number of entries in the array in a struct field perhaps?
>
> Would it make more sense to do something like default to index 0 and then use
> ARRAY_SIZE to iterate through the array and do a comparison to get the min and
> max size so it would always choose the correct value no matter how many entries
> there are?
>
Actually down the patch series 15/23 set pixel_rate range to the same as the value,
changes the logic and removes those two lines all together
>>
>>> /* By default, PIXEL_RATE is read only */
>>> imx258->pixel_rate = v4l2_ctrl_new_std(ctrl_hdlr, &imx258_ctrl_ops,
>>> V4L2_CID_PIXEL_RATE,
>>> @@ -1086,8 +1156,19 @@ static int imx258_probe(struct i2c_client *client)
>>> } else {
>>> val = clk_get_rate(imx258->clk);
>>> }
>>> - if (val != IMX258_INPUT_CLOCK_FREQ) {
>>> - dev_err(&client->dev, "input clock frequency not supported\n");
>>> +
>>> + switch (val) {
>>> + case 19200000:
>>> + imx258->link_freq_configs = link_freq_configs_19_2;
>>> + imx258->link_freq_menu_items = link_freq_menu_items_19_2;
>>> + break;
>>> + case 24000000:
>>> + imx258->link_freq_configs = link_freq_configs_24;
>>> + imx258->link_freq_menu_items = link_freq_menu_items_24;
>>> + break;
>>> + default:
>>> + dev_err(&client->dev, "input clock frequency of %u not supported\n",
>>> + val);
>>> return -EINVAL;
>>> }
>>>
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox