* Re: [PATCH v4 1/7] iio: accel: adxl345: Make data_range obsolete
From: Jonathan Cameron @ 2024-03-25 20:31 UTC (permalink / raw)
To: Lothar Rubusch
Cc: lars, Michael.Hennerich, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <20240325153356.46112-2-l.rubusch@gmail.com>
On Mon, 25 Mar 2024 15:33:50 +0000
Lothar Rubusch <l.rubusch@gmail.com> wrote:
> Replace write() data_format by regmap_update_bits(), because
> bus specific pre-configuration may have happened before on
> the same register. Changes then need to be masked.
>
> Remove the data_range field from the struct adxl345_data,
> because it is not used anymore.
>
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/iio/accel/adxl345_core.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
> index 8bd30a23e..be6758015 100644
> --- a/drivers/iio/accel/adxl345_core.c
> +++ b/drivers/iio/accel/adxl345_core.c
> @@ -42,13 +42,13 @@
> #define ADXL345_DATA_FORMAT_4G 1
> #define ADXL345_DATA_FORMAT_8G 2
> #define ADXL345_DATA_FORMAT_16G 3
> +#define ADXL345_DATA_FORMAT_MSK ~((u8) BIT(6)) /* ignore spi-3wire */
I'm not keen on seeing masking of a bit we don't yet
handle done by value. Can we instead build this up by what we 'want' to
write rather than don't. Will need a few more defines perhaps to cover
the masks of SELF_TEST, INT_INVERT, FULL_RES, Justify and Range.
>
> #define ADXL345_DEVID 0xE5
>
> struct adxl345_data {
> const struct adxl345_chip_info *info;
> struct regmap *regmap;
> - u8 data_range;
> };
>
> #define ADXL345_CHANNEL(index, axis) { \
> @@ -219,14 +219,13 @@ int adxl345_core_probe(struct device *dev, struct regmap *regmap)
> data = iio_priv(indio_dev);
> data->regmap = regmap;
> /* Enable full-resolution mode */
> - data->data_range = ADXL345_DATA_FORMAT_FULL_RES;
> data->info = device_get_match_data(dev);
> if (!data->info)
> return -ENODEV;
>
> - ret = regmap_write(data->regmap, ADXL345_REG_DATA_FORMAT,
> - data->data_range);
> - if (ret < 0)
> + ret = regmap_update_bits(regmap, ADXL345_REG_DATA_FORMAT,
> + ADXL345_DATA_FORMAT_MSK, ADXL345_DATA_FORMAT_FULL_RES);
> + if (ret)
> return dev_err_probe(dev, ret, "Failed to set data range\n");
>
> indio_dev->name = data->info->name;
^ permalink raw reply
* [PATCH 1/5] dt-bindings: iio: dac: ti,dac5571: Add DAC081C081 support
From: Laurent Pinchart @ 2024-03-25 20:32 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel
Cc: Trevor Zaharichuk, Greg Lytle, Jonathan Cameron,
Lars-Peter Clausen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sean Nyekjaer, linux-iio
In-Reply-To: <20240325203245.31660-1-laurent.pinchart@ideasonboard.com>
The DAC081C081 is a TI DAC whose software interface is compatible with
the DAC5571. It is the 8-bit version of the DAC121C081, already
supported by the DAC5571 bindings. Extends the bindings to support this
chip.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
index 79da0323c327..e59db861e2eb 100644
--- a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
@@ -21,6 +21,7 @@ properties:
- ti,dac5573
- ti,dac6573
- ti,dac7573
+ - ti,dac081c081
- ti,dac121c081
reg:
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* [PATCH 0/5] arm64: dts: Add device tree source for the Au-Zone Maivin AI Vision Starter Kit
From: Laurent Pinchart @ 2024-03-25 20:32 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel
Cc: Trevor Zaharichuk, Greg Lytle, Conor Dooley, Fabio Estevam,
Jonathan Cameron, Krzysztof Kozlowski, Lars-Peter Clausen,
linux-iio, Li Yang, Pengutronix Kernel Team, Rob Herring,
Sascha Hauer, Sean Nyekjaer, Shawn Guo
Hello,
This patch series adds device tree sources for the Maivin AI Vision
Starter Kit developed by Au-Zone Technologies in collaboration with
Toradex and Vision Components ([1]).
The first two patches add a new compatible string for the DAC081C081
present on the board to the dac5571 DT bindings and driver. Patch 3/5
then adds a new vendor prefix for Au-Zone, and patch 4/5 adds the board
to the arm/fsl.yaml DT bindings. Finally, patch 5/5 adds support for the
board.
[1] https://www.toradex.com/maivin-modular-full-stack-ai-vision-system
Laurent Pinchart (5):
dt-bindings: iio: dac: ti,dac5571: Add DAC081C081 support
iio: dac: ti-dac5571: Add DAC081C081 support
dt-bindings: vendor-prefix: Add prefix for Au-Zone Technologies
dt-bindings: arm: Add Au-Zone Maivin AI Vision Starter Kit
arm64: dts: Add device tree source for the Au-Zone Maivin Starter Kit
.../devicetree/bindings/arm/fsl.yaml | 7 +
.../bindings/iio/dac/ti,dac5571.yaml | 1 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../boot/dts/freescale/imx8mp-maivin.dts | 236 ++++++++++++++++++
drivers/iio/dac/ti-dac5571.c | 3 +
6 files changed, 250 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-maivin.dts
base-commit: 4cece764965020c22cff7665b18a012006359095
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 2/5] iio: dac: ti-dac5571: Add DAC081C081 support
From: Laurent Pinchart @ 2024-03-25 20:32 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel
Cc: Trevor Zaharichuk, Greg Lytle, Jonathan Cameron,
Lars-Peter Clausen, Sean Nyekjaer, linux-iio
In-Reply-To: <20240325203245.31660-1-laurent.pinchart@ideasonboard.com>
The DAC081C081 is a TI DAC whose software interface is compatible with
the DAC5571. It is the 8-bit version of the DAC121C081, already
supported by the DAC5571 driver. Extends the driver to support this
chip.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/iio/dac/ti-dac5571.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iio/dac/ti-dac5571.c b/drivers/iio/dac/ti-dac5571.c
index efb1269a77c1..c5162b72951a 100644
--- a/drivers/iio/dac/ti-dac5571.c
+++ b/drivers/iio/dac/ti-dac5571.c
@@ -13,6 +13,7 @@
* https://www.ti.com/lit/ds/symlink/dac5573.pdf
* https://www.ti.com/lit/ds/symlink/dac6573.pdf
* https://www.ti.com/lit/ds/symlink/dac7573.pdf
+ * https://www.ti.com/lit/ds/symlink/dac081c081.pdf
* https://www.ti.com/lit/ds/symlink/dac121c081.pdf
*/
@@ -386,6 +387,7 @@ static void dac5571_remove(struct i2c_client *i2c)
}
static const struct of_device_id dac5571_of_id[] = {
+ {.compatible = "ti,dac081c081", .data = &dac5571_spec[single_8bit] },
{.compatible = "ti,dac121c081", .data = &dac5571_spec[single_12bit] },
{.compatible = "ti,dac5571", .data = &dac5571_spec[single_8bit] },
{.compatible = "ti,dac6571", .data = &dac5571_spec[single_10bit] },
@@ -401,6 +403,7 @@ static const struct of_device_id dac5571_of_id[] = {
MODULE_DEVICE_TABLE(of, dac5571_of_id);
static const struct i2c_device_id dac5571_id[] = {
+ {"dac081c081", (kernel_ulong_t)&dac5571_spec[single_8bit] },
{"dac121c081", (kernel_ulong_t)&dac5571_spec[single_12bit] },
{"dac5571", (kernel_ulong_t)&dac5571_spec[single_8bit] },
{"dac6571", (kernel_ulong_t)&dac5571_spec[single_10bit] },
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* [PATCH 3/5] dt-bindings: vendor-prefix: Add prefix for Au-Zone Technologies
From: Laurent Pinchart @ 2024-03-25 20:32 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel
Cc: Trevor Zaharichuk, Greg Lytle, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <20240325203245.31660-1-laurent.pinchart@ideasonboard.com>
Au-Zone Technologies is a company that designs and manufactures products
for AI vision applications. Add a DT vendor prefix for it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index b97d298b3eb6..fce3d80c3d34 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -180,6 +180,8 @@ patternProperties:
description: AU Optronics Corporation
"^auvidea,.*":
description: Auvidea GmbH
+ "^au-zone,.*":
+ description: Au-Zone Technologies
"^avago,.*":
description: Avago Technologies
"^avia,.*":
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* [PATCH 4/5] dt-bindings: arm: Add Au-Zone Maivin AI Vision Starter Kit
From: Laurent Pinchart @ 2024-03-25 20:32 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel
Cc: Trevor Zaharichuk, Greg Lytle, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Li Yang
In-Reply-To: <20240325203245.31660-1-laurent.pinchart@ideasonboard.com>
The Maivin board is an AI vision starter kit sold by Au-Zone
Technologies, developed in collaboration with Toradex and Vision
Components. It is based on a Toradex Verdin i.MX8MP SoM.
Add a corresponding compatible string.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 0027201e19f8..d892c4f9fda3 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1064,6 +1064,13 @@ properties:
- toradex,verdin-imx8mp-wifi # Verdin iMX8M Plus Wi-Fi / BT Modules
- const: fsl,imx8mp
+ - description: Au-Zone Technologies i.MX8MP-based boards
+ items:
+ - const: au-zone,maivin-starter-kit # Au-Zone Maivin AI Vision Starter Kit
+ - const: toradex,verdin-imx8mp-nonwifi # Verdin iMX8M Plus Module without Wi-Fi / BT
+ - const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module
+ - const: fsl,imx8mp
+
- description: Avnet (MSC Branded) Boards with SM2S i.MX8M Plus Modules
items:
- const: avnet,sm2s-imx8mp-14N0600E-ep1 # SM2S-IMX8PLUS-14N0600E on SM2-MB-EP1 Carrier Board
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: Add device tree source for the Au-Zone Maivin Starter Kit
From: Laurent Pinchart @ 2024-03-25 20:32 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel
Cc: Trevor Zaharichuk, Greg Lytle, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20240325203245.31660-1-laurent.pinchart@ideasonboard.com>
The Maivin board is an AI vision starter kit sold by Au-Zone
Technologies, developed in collaboration with Toradex and Vision
Components. It is based on a Toradex Verdin i.MX8MP SoM.
Add a device tree that covers the base set the peripherals found on the
board:
- Ethernet
- USB
- SD card slot
- CAN and serial ports (RS232 and RS485)
- DACs, EEPROMs, temperature sensor
- PCI M.2 and CSI regulators
An additional pinctrl group is included for the M.2 modem, but hasn't
been tested due to lack of compatible hardware.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../boot/dts/freescale/imx8mp-maivin.dts | 236 ++++++++++++++++++
2 files changed, 237 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-maivin.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 045250d0a040..03af8c242649 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -165,6 +165,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-pdk2.dtb
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-maivin.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-msc-sm2s-ep1.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-phyboard-pollux-rdk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-hdmi.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-maivin.dts b/arch/arm64/boot/dts/freescale/imx8mp-maivin.dts
new file mode 100644
index 000000000000..2d1c8e782465
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-maivin.dts
@@ -0,0 +1,236 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright 2021 Au-Zone Technologies
+ * Copyright 2024 Ideas on Board
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/leds/common.h>
+
+#include "imx8mp-verdin.dtsi"
+#include "imx8mp-verdin-nonwifi.dtsi"
+
+/ {
+ model = "Au-Zone Maivin AI Vision Starter Kit";
+ compatible = "au-zone,maivin-starter-kit",
+ "toradex,verdin-imx8mp-nonwifi",
+ "toradex,verdin-imx8mp",
+ "fsl,imx8mp";
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&pinctrl_sw1>;
+
+ button-0 {
+ label = "SW1";
+ linux,code = <BTN_MISC>;
+ interrupts-extended = <&gpio3 16 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&pinctrl_led>;
+
+ led-0 {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "heartbeat";
+ gpios = <&gpio3 14 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ csi_3v3: regulator-csi-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "CSI_3V3";
+ pinctrl-0 = <&pinctrl_csi_3v3>;
+ gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ startup-delay-us = <50000>; /* TODO: Determine the right value */
+ };
+
+ m2_3v3: regulator-m2-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "M2_3V3";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ pinctrl-0 = <&pinctrl_m2_3v3>;
+ gpio = <&gpio3 1 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ /* Carrier Board Supply 3V3_SW */
+ reg_3v3: regulator-3v3-sw {
+ compatible = "regulator-fixed";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "3V3_SW";
+ };
+};
+
+&eqos {
+ status = "okay";
+};
+
+/* Verdin CAN_1 */
+&flexcan1 {
+ status = "okay";
+};
+
+/* Verdin CAN_2 */
+&flexcan2 {
+ status = "okay";
+};
+
+/* Verdin I2C_2_DSI */
+&i2c2 {
+ status = "okay";
+
+ clock-frequency = <400000>;
+ scl-gpios = <&gpio5 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 17 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+
+ dac@d {
+ compatible = "ti,dac081c081";
+ reg = <0x0d>;
+ vref-supply = <&csi_3v3>;
+ };
+};
+
+/* Verdin I2C_4_CSI */
+&i2c3 {
+ status = "okay";
+
+ dac@d {
+ compatible = "ti,dac081c081";
+ reg = <0x0d>;
+ vref-supply = <&csi_3v3>;
+ };
+};
+
+/* Verdin I2C_1 */
+&i2c4 {
+ status = "okay";
+
+ temp-sensor@4b {
+ compatible = "ti,tmp102";
+ reg = <0x4b>;
+ };
+
+ /* EEPROM on the rear connector interface */
+ eeprom@54 {
+ compatible = "st,24c02", "atmel,24c02";
+ pagesize = <16>;
+ reg = <0x54>;
+ };
+};
+
+/* EEPROM on the carrier board */
+&eeprom_carrier_board {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_csi_3v3: csi-3v3-grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_DATA01__GPIO3_IO07 0x184 /* SODIMM 58 */
+ >;
+ };
+
+ gpio7grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI1_RXD1__GPIO4_IO03 0x82 /* SODIMM 220 */
+ >;
+ };
+
+ gpio8grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI1_RXC__GPIO4_IO01 0x82 /* SODIMM 222 */
+ >;
+ };
+
+ pinctrl_led: ledgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_DQS__GPIO3_IO14 0x82 /* SODIMM 66 */
+ >;
+ };
+
+ /* M.2 power off and reset */
+ pinctrl_m2: m2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_DATA00__GPIO3_IO06 0x82 /* SODIMM 56 */
+ MX8MP_IOMUXC_NAND_DATA03__GPIO3_IO09 0x82 /* SODIMM 62 */
+ >;
+ };
+
+ pinctrl_m2_3v3: m2-3v3-grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_CE0_B__GPIO3_IO01 0x82 /* SODIMM 54 */
+ >;
+ };
+
+ pinctrl_sw1: sw1grp {
+ fsl,pins = <
+ /*
+ * SW1 shortens the pin to ground when pressed, enable
+ * the internal pull-up.
+ */
+ MX8MP_IOMUXC_NAND_READY_B__GPIO3_IO16 0x1c0 /* SODIMM 64 */
+ >;
+ };
+};
+
+®_usdhc2_vmmc {
+ vin-supply = <®_3v3>;
+};
+
+/* Verdin UART_1 */
+/* Enabling RS-485 operation */
+&uart1 {
+ fsl,uart-has-rtscts;
+ linux,rs485-enabled-at-boot-time;
+};
+
+/* Verdin UART_2, for M.2 card slot */
+&uart2 {
+ status = "okay";
+};
+
+/* Verdin UART_3, used as the Linux Console */
+&uart3 {
+ status = "okay";
+};
+
+/* Verdin USB_1, USB recovery */
+&usb3_phy0 {
+ status = "okay";
+};
+
+&usb3_0 {
+ status = "okay";
+};
+
+&usb_dwc3_0 {
+ status = "okay";
+};
+
+/* Verdin USB_2, for M.2 card slot */
+&usb3_phy1 {
+ status = "okay";
+};
+
+&usb3_1 {
+ status = "okay";
+};
+
+&usb_dwc3_1 {
+ status = "okay";
+};
+
+/* Verdin SD_1, for SD card slot */
+&usdhc2 {
+ status = "okay";
+};
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* Re: [PATCH v4 2/7] iio: accel: adxl345: Group bus configuration
From: Jonathan Cameron @ 2024-03-25 20:33 UTC (permalink / raw)
To: Lothar Rubusch
Cc: lars, Michael.Hennerich, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <20240325153356.46112-3-l.rubusch@gmail.com>
On Mon, 25 Mar 2024 15:33:51 +0000
Lothar Rubusch <l.rubusch@gmail.com> wrote:
> In the probe function group bus configuration and the
> indio_dev initialization to improve readability.
>
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/iio/accel/adxl345_core.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
> index be6758015..469015e9c 100644
> --- a/drivers/iio/accel/adxl345_core.c
> +++ b/drivers/iio/accel/adxl345_core.c
> @@ -218,22 +218,23 @@ int adxl345_core_probe(struct device *dev, struct regmap *regmap)
>
> data = iio_priv(indio_dev);
> data->regmap = regmap;
> - /* Enable full-resolution mode */
The naming of the written value gives this comment away + it's obviously misplaced
after previous patch. I'd just drop the comment in patch 1.
> +
> data->info = device_get_match_data(dev);
> if (!data->info)
> return -ENODEV;
>
> - ret = regmap_update_bits(regmap, ADXL345_REG_DATA_FORMAT,
> - ADXL345_DATA_FORMAT_MSK, ADXL345_DATA_FORMAT_FULL_RES);
> - if (ret)
> - return dev_err_probe(dev, ret, "Failed to set data range\n");
> -
> indio_dev->name = data->info->name;
> indio_dev->info = &adxl345_info;
> indio_dev->modes = INDIO_DIRECT_MODE;
> indio_dev->channels = adxl345_channels;
> indio_dev->num_channels = ARRAY_SIZE(adxl345_channels);
>
> + /* Enable full-resolution mode */
> + ret = regmap_update_bits(regmap, ADXL345_REG_DATA_FORMAT,
> + ADXL345_DATA_FORMAT_MSK, ADXL345_DATA_FORMAT_FULL_RES);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to set data range\n");
> +
> /* Enable measurement mode */
> ret = adxl345_powerup(data->regmap);
> if (ret < 0)
^ permalink raw reply
* Re: [PATCH v4 5/7] iio: accel: adxl345: Pass function pointer to core
From: Jonathan Cameron @ 2024-03-25 20:34 UTC (permalink / raw)
To: Lothar Rubusch
Cc: lars, Michael.Hennerich, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <20240325153356.46112-6-l.rubusch@gmail.com>
On Mon, 25 Mar 2024 15:33:54 +0000
Lothar Rubusch <l.rubusch@gmail.com> wrote:
> Add a function pointer argument to the probe function in
> the core module to provide a way to pre-configure the bus.
>
> The passed setup function can be prepared in the bus
> specific spi or the i2c module, or NULL otherwise. It shall
> then be executed in the bus independent core module.
Wrap descriptions at 75 chars, not around 60 as you've done here.
>
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/iio/accel/adxl345.h | 3 ++-
> drivers/iio/accel/adxl345_core.c | 10 +++++++++-
> drivers/iio/accel/adxl345_i2c.c | 2 +-
> drivers/iio/accel/adxl345_spi.c | 2 +-
> 4 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/accel/adxl345.h b/drivers/iio/accel/adxl345.h
> index ee169fed4..620a2e0f0 100644
> --- a/drivers/iio/accel/adxl345.h
> +++ b/drivers/iio/accel/adxl345.h
> @@ -59,6 +59,7 @@ struct adxl345_chip_info {
> int uscale;
> };
>
> -int adxl345_core_probe(struct device *dev, struct regmap *regmap);
> +int adxl345_core_probe(struct device *dev, struct regmap *regmap,
> + int (*setup)(struct device*, struct regmap*));
>
> #endif /* _ADXL345_H_ */
> diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
> index eba9c048a..476d729bc 100644
> --- a/drivers/iio/accel/adxl345_core.c
> +++ b/drivers/iio/accel/adxl345_core.c
> @@ -168,13 +168,21 @@ static void adxl345_powerdown(void *regmap)
> regmap_write(regmap, ADXL345_REG_POWER_CTL, ADXL345_POWER_CTL_STANDBY);
> }
>
> -int adxl345_core_probe(struct device *dev, struct regmap *regmap)
> +int adxl345_core_probe(struct device *dev, struct regmap *regmap,
> + int (*setup)(struct device*, struct regmap*))
Wrap as per the header definition above. (align just after opening bracket).
> {
> struct adxl345_data *data;
> struct iio_dev *indio_dev;
> u32 regval;
> int ret;
>
> + /* Perform optional initial bus specific configuration */
> + if (setup) {
> + ret = setup(dev, regmap);
> + if (ret)
> + return ret;
> + }
> +
> ret = regmap_read(regmap, ADXL345_REG_DEVID, ®val);
> if (ret < 0)
> return dev_err_probe(dev, ret, "Error reading device ID\n");
> diff --git a/drivers/iio/accel/adxl345_i2c.c b/drivers/iio/accel/adxl345_i2c.c
> index a3084b0a8..4065b8f7c 100644
> --- a/drivers/iio/accel/adxl345_i2c.c
> +++ b/drivers/iio/accel/adxl345_i2c.c
> @@ -27,7 +27,7 @@ static int adxl345_i2c_probe(struct i2c_client *client)
> if (IS_ERR(regmap))
> return dev_err_probe(&client->dev, PTR_ERR(regmap), "Error initializing regmap\n");
>
> - return adxl345_core_probe(&client->dev, regmap);
> + return adxl345_core_probe(&client->dev, regmap, NULL);
> }
>
> static const struct adxl345_chip_info adxl345_i2c_info = {
> diff --git a/drivers/iio/accel/adxl345_spi.c b/drivers/iio/accel/adxl345_spi.c
> index 93ca349f1..1c0513bd3 100644
> --- a/drivers/iio/accel/adxl345_spi.c
> +++ b/drivers/iio/accel/adxl345_spi.c
> @@ -33,7 +33,7 @@ static int adxl345_spi_probe(struct spi_device *spi)
> if (IS_ERR(regmap))
> return dev_err_probe(&spi->dev, PTR_ERR(regmap), "Error initializing regmap\n");
>
> - return adxl345_core_probe(&spi->dev, regmap);
> + return adxl345_core_probe(&spi->dev, regmap, NULL);
> }
>
> static const struct adxl345_chip_info adxl345_spi_info = {
^ permalink raw reply
* Re: [PATCH v4 7/7] iio: accel: adxl345: Add spi-3wire option
From: Jonathan Cameron @ 2024-03-25 20:37 UTC (permalink / raw)
To: Lothar Rubusch
Cc: lars, Michael.Hennerich, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <20240325153356.46112-8-l.rubusch@gmail.com>
On Mon, 25 Mar 2024 15:33:56 +0000
Lothar Rubusch <l.rubusch@gmail.com> wrote:
> Add a setup function implementation to the spi module to enable
> spi-3wire as option when specified in the device-tree.
>
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/iio/accel/adxl345.h | 1 +
> drivers/iio/accel/adxl345_spi.c | 12 +++++++++++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/accel/adxl345.h b/drivers/iio/accel/adxl345.h
> index 620a2e0f0..55a72ca38 100644
> --- a/drivers/iio/accel/adxl345.h
> +++ b/drivers/iio/accel/adxl345.h
> @@ -36,6 +36,7 @@
> #define ADXL345_DATA_FORMAT_8G 2
> #define ADXL345_DATA_FORMAT_16G 3
> #define ADXL345_DATA_FORMAT_MSK ~((u8) BIT(6)) /* ignore spi-3wire */
> +#define ADXL345_DATA_FORMAT_SPI_3WIRE BIT(6)
If you argue in favour of keeping the MSK as negation of this bit, then
reorder these two and define FORMAT_MSK in terms of SPI_3WIRE.
Note the name of FORMAT_MASK is also an issue now you actually write the 3wire bit.
So I'd get rid of that define in favour of positive defines of all the fields that
make it up used inline as it's only accessed in one place anyway.
That avoids the need for a mask of 'not' something.
>
> #define ADXL345_DEVID 0xE5
>
> diff --git a/drivers/iio/accel/adxl345_spi.c b/drivers/iio/accel/adxl345_spi.c
> index 1c0513bd3..f145d5c1d 100644
> --- a/drivers/iio/accel/adxl345_spi.c
> +++ b/drivers/iio/accel/adxl345_spi.c
> @@ -20,6 +20,16 @@ static const struct regmap_config adxl345_spi_regmap_config = {
> .read_flag_mask = BIT(7) | BIT(6),
> };
>
> +static int adxl345_spi_setup(struct device *dev, struct regmap *regmap)
> +{
> + struct spi_device *spi = container_of(dev, struct spi_device, dev);
> +
> + if (spi->mode & SPI_3WIRE)
> + return regmap_write(regmap, ADXL345_REG_DATA_FORMAT,
> + ADXL345_DATA_FORMAT_SPI_3WIRE);
> + return 0;
> +}
> +
> static int adxl345_spi_probe(struct spi_device *spi)
> {
> struct regmap *regmap;
> @@ -33,7 +43,7 @@ static int adxl345_spi_probe(struct spi_device *spi)
> if (IS_ERR(regmap))
> return dev_err_probe(&spi->dev, PTR_ERR(regmap), "Error initializing regmap\n");
>
> - return adxl345_core_probe(&spi->dev, regmap, NULL);
> + return adxl345_core_probe(&spi->dev, regmap, adxl345_spi_setup);
> }
>
> static const struct adxl345_chip_info adxl345_spi_info = {
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: rng: Add vmgenid support
From: Rob Herring @ 2024-03-25 20:41 UTC (permalink / raw)
To: Landge, Sudan
Cc: Sudan Landge, tytso, Jason, krzysztof.kozlowski+dt, conor+dt,
sathyanarayanan.kuppuswamy, thomas.lendacky, dan.j.williams,
devicetree, linux-kernel, graf, dwmw, bchalios, xmarcalx
In-Reply-To: <51403072-f5ca-450e-9206-19ca627ead11@amazon.co.uk>
On Mon, Mar 25, 2024 at 3:11 PM Landge, Sudan <sudanl@amazon.co.uk> wrote:
>
>
>
> On 25/03/2024 15:06, Rob Herring wrote:
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> >
> >
> >
> > On Thu, Mar 21, 2024 at 02:51:04AM +0000, Sudan Landge wrote:
> >> Virtual Machine Generation ID driver was introduced in commit af6b54e2b5ba
> >> ("virt: vmgenid: notify RNG of VM fork and supply generation ID"), as an
> >> ACPI only device.
> >>
> >> VMGenID specification http://go.microsoft.com/fwlink/?LinkId=260709 defines
> >> a mechanism for the BIOS/hypervisors to communicate to the virtual machine
> >> that it is executed with a different configuration (e.g. snapshot execution
> >> or creation from a template).
> >> The guest operating system can use the notification for various purposes
> >> such as re-initializing its random number generator etc.
> >>
> >> As per the specs, hypervisor should provide a globally unique identified,
> >> or GUID via ACPI.
> >>
> >> This patch tries to mimic the mechanism to provide the same functionality
> >> which is for a hypervisor/BIOS to notify the virtual machine when it is
> >> executed with a different configuration.
> >>
> >> As part of this support the devicetree bindings requires the hypervisors or
> >> BIOS to provide a memory address which holds the GUID and an IRQ which is
> >> used to notify when there is a change in the GUID.
> >> The memory exposed in the DT should follow the rules defined in the
> >> vmgenid spec mentioned above.
> >>
> >> *Reason for this change*:
> >> Chosing ACPI or devicetree is an intrinsic part of an hypervisor design.
> >> Without going into details of why a hypervisor would chose DT over ACPI,
> >> we would like to highlight that the hypervisors that have chose devicetree
> >> and now want to make use of the vmgenid functionality cannot do so today
> >> because vmgenid is an ACPI only device.
> >> This forces these hypervisors to change their design which could have
> >> undesirable impacts on their use-cases, test-scenarios etc.
> >>
> >> The point of vmgenid is to provide a mechanism to discover a GUID when
> >> the execution state of a virtual machine changes and the simplest
> >> way to do it is pass a memory location and an interrupt via devicetree.
> >> It would complicate things unnecessarily if instead of using devicetree,
> >> we try to implement a new protocol or modify other protocols to somehow
> >> provide the same functionility.
> >>
> >> We believe that adding a devicetree binding for vmgenid is a simpler,
> >> better alternative to provide the same functionality and will allow
> >> such hypervisors as mentioned above to continue using devicetree.
> >>
> >> More references to vmgenid specs:
> >> - https://www.qemu.org/docs/master/specs/vmgenid.html
> >> - https://learn.microsoft.com/en-us/windows/win32/hyperv_v2/virtual-machine-generation-identifier
> >>
> >> Signed-off-by: Sudan Landge <sudanl@amazon.com>
> >> ---
> >> .../devicetree/bindings/rng/vmgenid.yaml | 57 +++++++++++++++++++
> >> MAINTAINERS | 1 +
> >> 2 files changed, 58 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/rng/vmgenid.yaml
> >>
> >> diff --git a/Documentation/devicetree/bindings/rng/vmgenid.yaml b/Documentation/devicetree/bindings/rng/vmgenid.yaml
> >> new file mode 100644
> >> index 000000000000..4b6ab62cc2ae
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/rng/vmgenid.yaml
> >> @@ -0,0 +1,57 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/rng/vmgenid.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Virtual Machine Generation Counter ID device
> >> +
> >> +maintainers:
> >> + - Jason A. Donenfeld <Jason@zx2c4.com>
> >> +
> >> +description:
> >> + Firmwares or hypervisors can use this devicetree to describe
> >> + interrupts and the shared resources to inject a Virtual Machine Generation
> >> + counter.
> >> +
> >> +properties:
> >> + compatible:
> >> + const: linux,vmgenctr
> >
> > Why 'linux'? It should be named for a particular host implementation
> > (and that implementation's bugs/quirks). However, this thing is simple
> > enough we can perhaps avoid that here. As the interface is defined by
> > Microsoft, then perhaps they should be the vendor here.
> >
> We chose "linux" because the current implementation and usage of
> devicetree was Linux specific. However, I think "virtual" would be a
> better choice than "Microsoft" since this is a generic virtual device
> that could be configured by any hypervisor or firmware not owned or
> related to Microsoft. I have updated this as part of the new version if
> it looks good. I don't have a strong opinion for "virtual" though so if
> that is the right choice as per you I can update it.
I'm not really a fan of 'virtual' and its one and only existing use.
Don't add to it.
Someone has defined how to read a GUID from register(s). I can think
of many ways that could be implemented. The data itself could be hex
or ascii. You could read N times from one register or read from N
sequential registers. And again, there's endianness and access sizes.
Given the only source of any of that is a Microsoft spec, then that
makes sense to me. Or just no vendor prefix is possible, but I prefer
to avoid those cases.
Also, consider 'vmgenctr' has basically 0 search results. 'vmgenid'
returns some relevant results. Not that search results are a
requirement for naming, but perhaps something to consider.
> >> +
> >> + "#interrupt-cells":
> >> + const: 3
> >> + description: |
> >> + The 1st cell is the interrupt type.
> >> + The 2nd cell contains the interrupt number for the interrupt type.
> >> + The 3rd cell is for trigger type and level flags.
> >> +
> >> + interrupt-controller: true
> >
> > Why is this device an interrupt controller?
> >
> My devicetree references I took initially were incorrect which led to
> the addition of this, I have removed this in the next version. Sorry
> about that.
Try again...
> >> +
> >> + reg:
> >> + description: |
> >> + specifies the base physical address and
> >> + size of the regions in memory which holds the VMGenID counter.
> >
> > Odd wrapping, but drop unless you have something specific to say about
> > region like perhaps the layout of the registers. Or maybe thats defined
> > somewhere else?
> >
> > Does the spec say anything about endianness or access size? DT assumes
> > native endianness by default. We have properties to deal these, but
> > would be better to be explicit if that's defined already.
> >
> The spec doesn't mention anything about the endianness but, I have
> updated the description with some more data.
Then what does your driver assume? Microsoft may not have thought
about it because they don't care, but now you want to use DT so you
have to because it is frequently used on BE systems. If we define
something, then there's some hope. Otherwise, it's pretty much a
guarantee folks will do the opposite.
Rob
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: iio: dac: ti,dac5571: Add DAC081C081 support
From: Jonathan Cameron @ 2024-03-25 20:48 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, imx, linux-arm-kernel, Trevor Zaharichuk, Greg Lytle,
Lars-Peter Clausen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sean Nyekjaer, linux-iio
In-Reply-To: <20240325203245.31660-2-laurent.pinchart@ideasonboard.com>
On Mon, 25 Mar 2024 22:32:41 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> The DAC081C081 is a TI DAC whose software interface is compatible with
> the DAC5571. It is the 8-bit version of the DAC121C081, already
> supported by the DAC5571 bindings. Extends the bindings to support this
> chip.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Hi Laurent,
Given it's a part number where no one is going to guess it is compatible
with the DAC5571 and that we don't have a history of fallback compatibles
I'm fine with this change, but just wanted to ask is a fallback compatible
useful to you to run with older kernels?
I should have noticed when Peter added the dac121c081. If we add a fallback
should do that one as well.
Jonathan
> ---
> Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
> index 79da0323c327..e59db861e2eb 100644
> --- a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
> +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
> @@ -21,6 +21,7 @@ properties:
> - ti,dac5573
> - ti,dac6573
> - ti,dac7573
> + - ti,dac081c081
> - ti,dac121c081
>
> reg:
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: imx8mp: Add DT nodes for the two ISPs
From: Laurent Pinchart @ 2024-03-25 20:49 UTC (permalink / raw)
To: Alexander Stein
Cc: imx, linux-arm-kernel, Paul Elder, Adam Ford, Conor Dooley,
Fabio Estevam, Krzysztof Kozlowski, Marek Vasut,
Pengutronix Kernel Team, Rob Herring, Sascha Hauer, Shawn Guo,
devicetree, linux-media
In-Reply-To: <4879631.GXAFRqVoOG@steina-w>
Hi Alexander,
On Mon, Mar 25, 2024 at 04:52:21PM +0100, Alexander Stein wrote:
> Am Montag, 25. März 2024, 16:13:39 CET schrieb Laurent Pinchart:
> > From: Paul Elder <paul.elder@ideasonboard.com>
> >
> > The ISP supports both CSI and parallel interfaces, where port 0
> > corresponds to the former and port 1 corresponds to the latter. Since
> > the i.MX8MP's ISPs are connected by the parallel interface to the CSI
> > receiver, set them both to port 1.
> >
> > Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
> > Changes since v1:
> >
> > - Fix clock ordering
> > - Add #address-cells and #size-cells to ports nodes
> > ---
> > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 50 +++++++++++++++++++++++
> > 1 file changed, 50 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > index bfc5c81a5bd4..1d2670b91b53 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > @@ -1616,6 +1616,56 @@ isi_in_1: endpoint {
> > };
> > };
> >
> > + isp_0: isp@32e10000 {
> > + compatible = "fsl,imx8mp-isp";
> > + reg = <0x32e10000 0x10000>;
> > + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk IMX8MP_CLK_MEDIA_ISP_ROOT>,
> > + <&clk IMX8MP_CLK_MEDIA_AXI_ROOT>,
> > + <&clk IMX8MP_CLK_MEDIA_APB_ROOT>;
> > + clock-names = "isp", "aclk", "hclk";
> > + assigned-clocks = <&clk IMX8MP_CLK_MEDIA_ISP>;
> > + assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_500M>;
> > + assigned-clock-rates = <500000000>;
> > + power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_ISP>;
> > + fsl,blk-ctrl = <&media_blk_ctrl 0>;
> > + status = "disabled";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@1 {
> > + reg = <1>;
> > + };
> > + };
> > + };
> > +
> > + isp_1: isp@32e20000 {
> > + compatible = "fsl,imx8mp-isp";
> > + reg = <0x32e20000 0x10000>;
> > + interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk IMX8MP_CLK_MEDIA_ISP_ROOT>,
> > + <&clk IMX8MP_CLK_MEDIA_AXI_ROOT>,
> > + <&clk IMX8MP_CLK_MEDIA_APB_ROOT>;
> > + clock-names = "isp", "aclk", "hclk";
> > + assigned-clocks = <&clk IMX8MP_CLK_MEDIA_ISP>;
> > + assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_500M>;
> > + assigned-clock-rates = <500000000>;
> > + power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_ISP>;
> > + fsl,blk-ctrl = <&media_blk_ctrl 1>;
> > + status = "disabled";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@1 {
> > + reg = <1>;
> > + };
> > + };
> > + };
> > +
>
> The patch itself is okay. But you might not be able to
> configure the parent of IMX8MP_CLK_MEDIA_ISP if dewarp is enabled before.
> This is due to IMX8MP_CLK_MEDIA_ISP_ROOT being enabled in 'pgc_ispdwp'
> power domain. Reparenting is not possible anymore in this case.
Good point.
> Something like
> ---8<---
> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> @@ -1837,11 +1837,13 @@ media_blk_ctrl: blk-ctrl@32ec0000 {
> <&clk IMX8MP_CLK_MEDIA_APB>,
> <&clk IMX8MP_CLK_MEDIA_DISP1_PIX>,
> <&clk IMX8MP_CLK_MEDIA_DISP2_PIX>,
> + <&clk IMX8MP_CLK_MEDIA_ISP>,
> <&clk IMX8MP_VIDEO_PLL1>;
> assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_1000M>,
> <&clk IMX8MP_SYS_PLL1_800M>,
> <&clk IMX8MP_VIDEO_PLL1_OUT>,
> - <&clk IMX8MP_VIDEO_PLL1_OUT>;
> + <&clk IMX8MP_VIDEO_PLL1_OUT>,
> + <&clk IMX8MP_SYS_PLL2_500M>;
> assigned-clock-rates = <500000000>, <200000000>,
> <0>, <0>, <1039500000>;
With an assigned clock rate here too then ?
> #power-domain-cells = <1>;
> ---8<---
> is needed.
Sascha, are you OK with this approach ?
> > dewarp: dwe@32e30000 {
> > compatible = "nxp,imx8mp-dw100";
> > reg = <0x32e30000 0x10000>;
> >
> > base-commit: 4cece764965020c22cff7665b18a012006359095
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 3/4] dt-bindings: rng: Add vmgenid support
From: Rob Herring @ 2024-03-25 20:53 UTC (permalink / raw)
To: Sudan Landge
Cc: tytso, Jason, krzysztof.kozlowski+dt, conor+dt,
sathyanarayanan.kuppuswamy, thomas.lendacky, dan.j.williams,
devicetree, linux-kernel, graf, dwmw, bchalios, xmarcalx
In-Reply-To: <20240325195306.13133-4-sudanl@amazon.com>
On Mon, Mar 25, 2024 at 2:53 PM Sudan Landge <sudanl@amazon.com> wrote:
>
Please give time for discussions on prior versions to finish and
others to comment. We're not all in one timezone and are busy. I've
replied there too.
> Virtual Machine Generation ID driver was introduced in commit af6b54e2b5ba
> ("virt: vmgenid: notify RNG of VM fork and supply generation ID"), as an
> ACPI only device.
>
> VMGenID specification http://go.microsoft.com/fwlink/?LinkId=260709 defines
> a mechanism for the BIOS/hypervisors to communicate to the virtual machine
> that it is executed with a different configuration (e.g. snapshot execution
> or creation from a template).
> The guest operating system can use the notification for various purposes
> such as re-initializing its random number generator etc.
>
> As per the specs, hypervisor should provide a globally unique identified,
> or GUID via ACPI.
>
> This patch tries to mimic the mechanism to provide the same functionality
> which is for a hypervisor/BIOS to notify the virtual machine when it is
> executed with a different configuration.
>
> As part of this support the devicetree bindings requires the hypervisors or
> BIOS to provide a memory address which holds the GUID and an IRQ which is
> used to notify when there is a change in the GUID.
> The memory exposed in the DT should follow the rules defined in the
> vmgenid spec mentioned above.
>
> *Reason for this change*:
> Chosing ACPI or devicetree is an intrinsic part of an hypervisor design.
> Without going into details of why a hypervisor would chose DT over ACPI,
> we would like to highlight that the hypervisors that have chose devicetree
> and now want to make use of the vmgenid functionality cannot do so today
> because vmgenid is an ACPI only device.
> This forces these hypervisors to change their design which could have
> undesirable impacts on their use-cases, test-scenarios etc.
>
> The point of vmgenid is to provide a mechanism to discover a GUID when
> the execution state of a virtual machine changes and the simplest
> way to do it is pass a memory location and an interrupt via devicetree.
> It would complicate things unnecessarily if instead of using devicetree,
> we try to implement a new protocol or modify other protocols to somehow
> provide the same functionility.
>
> We believe that adding a devicetree binding for vmgenid is a simpler,
> better alternative to provide the same functionality and will allow
> such hypervisors as mentioned above to continue using devicetree.
>
> More references to vmgenid specs:
> - https://www.qemu.org/docs/master/specs/vmgenid.html
> - https://learn.microsoft.com/en-us/windows/win32/hyperv_v2/virtual-
> machine-generation-identifier
>
> Signed-off-by: Sudan Landge <sudanl@amazon.com>
> ---
> .../devicetree/bindings/rng/vmgenid.yaml | 58 +++++++++++++++++++
Filename should match the compatible, whatever that ends up being.
> MAINTAINERS | 1 +
> 2 files changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rng/vmgenid.yaml
>
> diff --git a/Documentation/devicetree/bindings/rng/vmgenid.yaml b/Documentation/devicetree/bindings/rng/vmgenid.yaml
> new file mode 100644
> index 000000000000..24643080d6b0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rng/vmgenid.yaml
> @@ -0,0 +1,58 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rng/vmgenid.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Virtual Machine Generation Counter ID device
> +
> +maintainers:
> + - Jason A. Donenfeld <Jason@zx2c4.com>
> +
> +description:
> + Firmwares or hypervisors can use this devicetree to describe
> + interrupts and the shared resources to inject a Virtual Machine Generation
> + counter.
> +
> +properties:
> + compatible:
> + const: virtual,vmgenctr
> +
> +
> + "#interrupt-cells":
> + const: 3
> + description:
> + The 1st cell is the interrupt type.
> + The 2nd cell contains the interrupt number for the interrupt type.
> + The 3rd cell is for trigger type and level flags.
> +
> + interrupt-map: true
Sigh. What makes this an interrupt-map? Why do you think you need this
and #interrupt-cells? You don't have them in the example.
> +
> + reg:
> + description:
> + The 1st cell specifies the base physical address of the 8-byte aligned
> + buffer in guest memory space which is guaranteed not to be used by the
> + operating system.
> + The 2nd cell specifies the size of the buffer which holds the VMGenID.
I didn't ask for you to explain the purpose of cells in 'reg' as that
is the same for *every* instance of 'reg'. Ignore DTisms and describe
the format of the registers. For example, is it 4 32-bit registers
(hex) or 9 32-bit registers (ascii)?
> + maxItems: 1
> +
> + interrupts:
> + description:
> + interrupt used to notify that a new VMGenID counter is available.
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + rng@80000000 {
> + compatible = "virtual,vmgenctr";
> + reg = <0x80000000 0x1000>;
> + interrupts = <0x00 0x23 0x01>;
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index de6a64b248ae..e295d2f50af4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -18461,6 +18461,7 @@ M: "Theodore Ts'o" <tytso@mit.edu>
> M: Jason A. Donenfeld <Jason@zx2c4.com>
> S: Maintained
> T: git https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git
> +F: Documentation/devicetree/bindings/rng/vmgenid.yaml
> F: drivers/char/random.c
> F: drivers/virt/vmgenid.c
>
> --
> 2.40.1
>
>
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: iio: dac: ti,dac5571: Add DAC081C081 support
From: Laurent Pinchart @ 2024-03-25 20:56 UTC (permalink / raw)
To: Jonathan Cameron
Cc: devicetree, imx, linux-arm-kernel, Trevor Zaharichuk, Greg Lytle,
Lars-Peter Clausen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sean Nyekjaer, linux-iio
In-Reply-To: <20240325204857.4f2fd468@jic23-huawei>
Hi Jonathan,
On Mon, Mar 25, 2024 at 08:48:57PM +0000, Jonathan Cameron wrote:
> On Mon, 25 Mar 2024 22:32:41 +0200 Laurent Pinchart wrote:
>
> > The DAC081C081 is a TI DAC whose software interface is compatible with
> > the DAC5571. It is the 8-bit version of the DAC121C081, already
> > supported by the DAC5571 bindings. Extends the bindings to support this
> > chip.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> Hi Laurent,
>
> Given it's a part number where no one is going to guess it is compatible
> with the DAC5571 and that we don't have a history of fallback compatibles
> I'm fine with this change, but just wanted to ask is a fallback compatible
> useful to you to run with older kernels?
>
> I should have noticed when Peter added the dac121c081. If we add a fallback
> should do that one as well.
I've indeed noticed that there should have been a fallback for
dac121c081, but didn't stop to ponder why that wasn't the case, and just
went along with the flow :-) I agree a fallback could be useful, which
would then allow dropping patch 2/5 from this series (*). I can do so if
you prefer.
* This is not entirely true. While the DAC1081C081 is largely compatible
with the DAC5573, they have different values for one of the power-down
resistors (2.5kΩ instead of 1kΩ if I recall correctly). To be completely
accurate, the driver should report that. We could still use the fallback
compatible, reporting the wrong power-down resistor value.
> > ---
> > Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
> > index 79da0323c327..e59db861e2eb 100644
> > --- a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
> > +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
> > @@ -21,6 +21,7 @@ properties:
> > - ti,dac5573
> > - ti,dac6573
> > - ti,dac7573
> > + - ti,dac081c081
> > - ti,dac121c081
> >
> > reg:
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v4 4/7] dt-bindings: iio: accel: adxl345: Add spi-3wire
From: Lothar Rubusch @ 2024-03-25 21:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <f74a01bd-46a3-46cd-a47a-fcfccd7e4dc6@linaro.org>
On Mon, Mar 25, 2024 at 7:32 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 25/03/2024 16:33, Lothar Rubusch wrote:
> > Add spi-3wire because the driver optionally supports spi-3wire.
>
> This is a friendly reminder during the review process.
>
> It seems my or other reviewer's previous comments were not fully
> addressed. Maybe the feedback got lost between the quotes, maybe you
> just forgot to apply it. Please go back to the previous discussion and
> either implement all requested changes or keep discussing them.
>
> Thank you.
>
You refer yourself to the above mentioned wording. Would replacing
"driver" by "device" in the dt-bindings patch comment be sufficient?
Did I miss something else?
> >
> > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> > ---
>
> This is a friendly reminder during the review process.
>
> It looks like you received a tag and forgot to add it.
>
> 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
Just for confirmation: when I receive a feedback, requesting a change.
And, I accept the change request. This means, I received a tag
"Reviewed-by" which I have to mention in the upcoming patch version
where this change is implemented and in that particular patch?
> the tags. The upstream maintainer will do that for tags received on the
> version they apply.
>
I'm pretty sure we will still see further iterations. So, I apply the
tags in the next version, already scheduled. Ok?
> https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
>
Going over the books I feel it does not make sense to still mention
feedback ("Reveiewed-by") for the v1 or v2 of the patch here in a v5,
does it? Your link mentiones "However if the patch has changed
substantially in followin version, these tags might not be applicable
anymore"
https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L579
> If a tag was not added on purpose, please state why and what changed.
>
> Best regards,
> Krzysztof
>
I give it a try with b4. Let's see.
^ permalink raw reply
* [PATCH v2 0/4] dt-bindings: rtc: convert multiple devices to dtschema
From: Javier Carrasco @ 2024-03-25 21:10 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
Javier Carrasco
This series converts the following existing bindings to dtschema:
- armada-380-rtc
- alphascale,asm9260
- digicolor-rtc (moved to trivial-rtc)
- nxp,lpc1788-rtc
All bindings include at least one compatible that is referenced in the
existing dts (arch/arm). Those dts could be tested against the new
bindings.
It might be worth mentioning that the reference to nxp,lpc1788-rtc in
arch/arm/boot/dts/nxp/lpc/lpc18xx.dtsi also includes another compatible
called nxp,lpc1850-rtc, which is not documented or supported by existing
drivers. That generates a warning when testing against nxp,lpc1788-rtc.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
Changes in v2:
- General: reference to rtc.yaml
- digicolor-rtc: move to trivial-rtc
- Link to v1: https://lore.kernel.org/r/20240323-rtc-yaml-v1-0-0c5d12b1b89d@gmail.com
---
Javier Carrasco (4):
dt-bindings: rtc: armada-380-rtc: convert to dtschema
dt-bindings: rtc: alphascale,asm9260-rtc: convert to dtschema
dt-bindings: rtc: digicolor-rtc: move to trivial-rtc
dt-bindings: rtc: nxp,lpc1788-rtc: convert to dtschema
.../bindings/rtc/alphascale,asm9260-rtc.txt | 19 -------
.../bindings/rtc/alphascale,asm9260-rtc.yaml | 52 +++++++++++++++++++
.../devicetree/bindings/rtc/armada-380-rtc.txt | 24 ---------
.../devicetree/bindings/rtc/digicolor-rtc.txt | 17 ------
.../bindings/rtc/marvell,armada-380-rtc.yaml | 51 ++++++++++++++++++
.../devicetree/bindings/rtc/nxp,lpc1788-rtc.txt | 21 --------
.../devicetree/bindings/rtc/nxp,lpc1788-rtc.yaml | 60 ++++++++++++++++++++++
.../devicetree/bindings/rtc/trivial-rtc.yaml | 2 +
8 files changed, 165 insertions(+), 81 deletions(-)
---
base-commit: 4cece764965020c22cff7665b18a012006359095
change-id: 20240322-rtc-yaml-473335cbf911
Best regards,
--
Javier Carrasco <javier.carrasco.cruz@gmail.com>
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: rtc: armada-380-rtc: convert to dtschema
From: Javier Carrasco @ 2024-03-25 21:10 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
Javier Carrasco
In-Reply-To: <20240325-rtc-yaml-v2-0-ff9f68f43dbc@gmail.com>
Convert existing binding to dtschema to support validation.
This is a direct conversion with no additions.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
.../devicetree/bindings/rtc/armada-380-rtc.txt | 24 ----------
.../bindings/rtc/marvell,armada-380-rtc.yaml | 51 ++++++++++++++++++++++
2 files changed, 51 insertions(+), 24 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/armada-380-rtc.txt b/Documentation/devicetree/bindings/rtc/armada-380-rtc.txt
deleted file mode 100644
index c3c9a1226f9a..000000000000
--- a/Documentation/devicetree/bindings/rtc/armada-380-rtc.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* Real Time Clock of the Armada 38x/7K/8K SoCs
-
-RTC controller for the Armada 38x, 7K and 8K SoCs
-
-Required properties:
-- compatible : Should be one of the following:
- "marvell,armada-380-rtc" for Armada 38x SoC
- "marvell,armada-8k-rtc" for Aramda 7K/8K SoCs
-- reg: a list of base address and size pairs, one for each entry in
- reg-names
-- reg names: should contain:
- * "rtc" for the RTC registers
- * "rtc-soc" for the SoC related registers and among them the one
- related to the interrupt.
-- interrupts: IRQ line for the RTC.
-
-Example:
-
-rtc@a3800 {
- compatible = "marvell,armada-380-rtc";
- reg = <0xa3800 0x20>, <0x184a0 0x0c>;
- reg-names = "rtc", "rtc-soc";
- interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/marvell,armada-380-rtc.yaml b/Documentation/devicetree/bindings/rtc/marvell,armada-380-rtc.yaml
new file mode 100644
index 000000000000..adf3ba0cd09f
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/marvell,armada-380-rtc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/marvell,armada-380-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RTC controller for the Armada 38x, 7K and 8K SoCs
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - marvell,armada-380-rtc
+ - marvell,armada-8k-rtc
+
+ reg:
+ items:
+ - description: RTC base address size
+ - description: Base address and size of SoC related registers
+
+ reg-names:
+ items:
+ - const: rtc
+ - const: rtc-soc
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ rtc@a3800 {
+ compatible = "marvell,armada-380-rtc";
+ reg = <0xa3800 0x20>, <0x184a0 0x0c>;
+ reg-names = "rtc", "rtc-soc";
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ };
--
2.40.1
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: rtc: alphascale,asm9260-rtc: convert to dtschema
From: Javier Carrasco @ 2024-03-25 21:10 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
Javier Carrasco
In-Reply-To: <20240325-rtc-yaml-v2-0-ff9f68f43dbc@gmail.com>
Convert existing binding to dtschema to support validation.
This is a direct conversion with no additions.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
.../bindings/rtc/alphascale,asm9260-rtc.txt | 19 --------
.../bindings/rtc/alphascale,asm9260-rtc.yaml | 52 ++++++++++++++++++++++
2 files changed, 52 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.txt b/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.txt
deleted file mode 100644
index 76ebca568db9..000000000000
--- a/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-* Alphascale asm9260 SoC Real Time Clock
-
-Required properties:
-- compatible: Should be "alphascale,asm9260-rtc"
-- reg: Physical base address of the controller and length
- of memory mapped region.
-- interrupts: IRQ line for the RTC.
-- clocks: Reference to the clock entry.
-- clock-names: should contain:
- * "ahb" for the SoC RTC clock
-
-Example:
-rtc0: rtc@800a0000 {
- compatible = "alphascale,asm9260-rtc";
- reg = <0x800a0000 0x100>;
- clocks = <&acc CLKID_AHB_RTC>;
- clock-names = "ahb";
- interrupts = <2>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.yaml b/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.yaml
new file mode 100644
index 000000000000..8acd5e94fd58
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/alphascale,asm9260-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Alphascale asm9260 SoC Real Time Clock
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: alphascale,asm9260-rtc
+
+ reg:
+ description:
+ Base address and length of the register region.
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: ahb
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/alphascale,asm9260.h>
+
+ rtc@800a0000 {
+ compatible = "alphascale,asm9260-rtc";
+ reg = <0x800a0000 0x100>;
+ clocks = <&acc CLKID_AHB_RTC>;
+ clock-names = "ahb";
+ interrupts = <2>;
+ };
--
2.40.1
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: rtc: digicolor-rtc: move to trivial-rtc
From: Javier Carrasco @ 2024-03-25 21:10 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
Javier Carrasco
In-Reply-To: <20240325-rtc-yaml-v2-0-ff9f68f43dbc@gmail.com>
Convert existing binding to dtschema to support validation.
This device meets the requirements to be moved to trivial-rtc
(compatible, reg and a single interrupt).
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
Documentation/devicetree/bindings/rtc/digicolor-rtc.txt | 17 -----------------
Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
2 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/digicolor-rtc.txt b/Documentation/devicetree/bindings/rtc/digicolor-rtc.txt
deleted file mode 100644
index d464986012cd..000000000000
--- a/Documentation/devicetree/bindings/rtc/digicolor-rtc.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Conexant Digicolor Real Time Clock controller
-
-This binding currently supports the CX92755 SoC.
-
-Required properties:
-- compatible: should be "cnxt,cx92755-rtc"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: rtc alarm interrupt
-
-Example:
-
- rtc@f0000c30 {
- compatible = "cnxt,cx92755-rtc";
- reg = <0xf0000c30 0x18>;
- interrupts = <25>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
index c9e3c5262c21..a3db41c5207c 100644
--- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
@@ -24,6 +24,8 @@ properties:
- abracon,abb5zes3
# AB-RTCMC-32.768kHz-EOZ9: Real Time Clock/Calendar Module with I2C Interface
- abracon,abeoz9
+ # Conexant Digicolor Real Time Clock Controller
+ - cnxt,cx92755-rtc
# I2C, 32-Bit Binary Counter Watchdog RTC with Trickle Charger and Reset Input/Output
- dallas,ds1374
# Dallas DS1672 Real-time Clock
--
2.40.1
^ permalink raw reply related
* [PATCH v2 4/4] dt-bindings: rtc: nxp,lpc1788-rtc: convert to dtschema
From: Javier Carrasco @ 2024-03-25 21:10 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
Javier Carrasco
In-Reply-To: <20240325-rtc-yaml-v2-0-ff9f68f43dbc@gmail.com>
Convert existing binding to dtschema to support validation.
This is a direct conversion with no additions.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
.../devicetree/bindings/rtc/nxp,lpc1788-rtc.txt | 21 --------
.../devicetree/bindings/rtc/nxp,lpc1788-rtc.yaml | 60 ++++++++++++++++++++++
2 files changed, 60 insertions(+), 21 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.txt b/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.txt
deleted file mode 100644
index 3c97bd180592..000000000000
--- a/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-NXP LPC1788 real-time clock
-
-The LPC1788 RTC provides calendar and clock functionality
-together with periodic tick and alarm interrupt support.
-
-Required properties:
-- compatible : must contain "nxp,lpc1788-rtc"
-- reg : Specifies base physical address and size of the registers.
-- interrupts : A single interrupt specifier.
-- clocks : Must contain clock specifiers for rtc and register clock
-- clock-names : Must contain "rtc" and "reg"
- See ../clocks/clock-bindings.txt for details.
-
-Example:
-rtc: rtc@40046000 {
- compatible = "nxp,lpc1788-rtc";
- reg = <0x40046000 0x1000>;
- interrupts = <47>;
- clocks = <&creg_clk 0>, <&ccu1 CLK_CPU_BUS>;
- clock-names = "rtc", "reg";
-};
diff --git a/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.yaml b/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.yaml
new file mode 100644
index 000000000000..db900617f1e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/nxp,lpc1788-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC1788 real-time clock
+
+description:
+ The LPC1788 RTC provides calendar and clock functionality
+ together with periodic tick and alarm interrupt support.
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: nxp,lpc1788-rtc
+
+ reg:
+ description:
+ Base address and length of the register region.
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: RTC clock
+ - description: Register clock
+
+ clock-names:
+ items:
+ - const: rtc
+ - const: reg
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-ccu.h>
+
+ rtc@40046000 {
+ compatible = "nxp,lpc1788-rtc";
+ reg = <0x40046000 0x1000>;
+ clocks = <&creg_clk 0>, <&ccu1 CLK_CPU_BUS>;
+ clock-names = "rtc", "reg";
+ interrupts = <47>;
+ };
--
2.40.1
^ permalink raw reply related
* Re: [PATCH v2 1/1] ASoC: dt-bindings: fsl-esai: Convert fsl,esai.txt to yaml
From: Mark Brown @ 2024-03-25 21:23 UTC (permalink / raw)
To: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shengjiu Wang, linux-sound, devicetree, linux-kernel, Frank Li
Cc: imx
In-Reply-To: <20240322145406.2613256-1-Frank.Li@nxp.com>
On Fri, 22 Mar 2024 10:54:05 -0400, Frank Li wrote:
> Convert fsl,esai.txt to yaml. So DTB_CHECK tools can verify dts file about
> esai part.
>
> clock-names 'spba' is optional according to description. So minItems of
> clocks and clock-names is 3.
>
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: dt-bindings: fsl-esai: Convert fsl,esai.txt to yaml
commit: 885dd75f41f9fff5b277bc6ab28ad798f98a37b4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [PATCH v6 1/1] ARM: dts: imx: Add UNI-T UTi260B thermal camera board
From: Sebastian Reichel @ 2024-03-25 21:19 UTC (permalink / raw)
To: Sebastian Reichel, Shawn Guo, Sascha Hauer, Fabio Estevam
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Pengutronix Kernel Team, imx, linux-arm-kernel, devicetree,
linux-kernel, Stefan Wahren
In-Reply-To: <20240325212402.150906-1-sre@kernel.org>
Add DT for the UNI-T UTi260B handheld thermal camera.
Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
arch/arm/boot/dts/nxp/imx/Makefile | 1 +
arch/arm/boot/dts/nxp/imx/imx6ull-uti260b.dts | 566 ++++++++++++++++++
2 files changed, 567 insertions(+)
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-uti260b.dts
diff --git a/arch/arm/boot/dts/nxp/imx/Makefile b/arch/arm/boot/dts/nxp/imx/Makefile
index 4052cad859fa..598361d0632e 100644
--- a/arch/arm/boot/dts/nxp/imx/Makefile
+++ b/arch/arm/boot/dts/nxp/imx/Makefile
@@ -355,6 +355,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ull-tarragon-slavext.dtb \
imx6ull-tqma6ull2-mba6ulx.dtb \
imx6ull-tqma6ull2l-mba6ulx.dtb \
+ imx6ull-uti260b.dtb \
imx6ulz-14x14-evk.dtb \
imx6ulz-bsh-smm-m2.dtb
dtb-$(CONFIG_SOC_IMX7D) += \
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ull-uti260b.dts b/arch/arm/boot/dts/nxp/imx/imx6ull-uti260b.dts
new file mode 100644
index 000000000000..e4576d509a5b
--- /dev/null
+++ b/arch/arm/boot/dts/nxp/imx/imx6ull-uti260b.dts
@@ -0,0 +1,566 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+// Copyright (C) 2022-2024 Sebastian Reichel <sre@kernel.org>
+
+/dts-v1/;
+#include "imx6ull.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/clock/imx6ul-clock.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "UNI-T UTi260B Thermal Camera";
+ compatible = "uni-t,uti260b", "fsl,imx6ull";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x20000000>;
+ };
+
+ panel_backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ enable-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_backlight_enable>;
+ power-supply = <®_vsd>;
+ pwms = <&pwm1 0 50000 0>;
+ };
+
+ battery: battery {
+ compatible = "simple-battery";
+ /* generic 26650 battery */
+ device-chemistry = "lithium-ion";
+ charge-full-design-microamp-hours = <5000000>;
+ voltage-max-design-microvolt = <4200000>;
+ voltage-min-design-microvolt = <3300000>;
+ };
+
+ tp5000: charger {
+ compatible = "gpio-charger";
+ charger-type = "usb-sdp";
+ gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_charger_stat1>;
+ };
+
+ fuel-gauge {
+ compatible = "adc-battery";
+ charged-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
+ io-channel-names = "voltage";
+ io-channels = <&adc1 7>;
+ monitored-battery = <&battery>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_charger_stat2>;
+ power-supplies = <&tp5000>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_gpio_keys>;
+ autorepeat;
+
+ up-key {
+ label = "Up";
+ gpios = <&gpio2 11 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_UP>;
+ };
+
+ down-key {
+ label = "Down";
+ gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_DOWN>;
+ };
+
+ left-key {
+ label = "Left";
+ gpios = <&gpio2 13 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_LEFT>;
+ };
+
+ right-key {
+ label = "Right";
+ gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_RIGHT>;
+ };
+
+ ok-key {
+ label = "Ok";
+ gpios = <&gpio2 9 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_ENTER>;
+ };
+
+ return-key {
+ label = "Return";
+ gpios = <&gpio2 15 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_ESC>;
+ };
+
+ play-key {
+ label = "Media";
+ gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_MEDIA>;
+ };
+
+ trigger-key {
+ label = "Trigger";
+ gpios = <&gpio2 14 GPIO_ACTIVE_LOW>;
+ linux,code = <BTN_TRIGGER>;
+ };
+
+ power-key {
+ label = "Power";
+ gpios = <&gpio2 3 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_POWER>;
+ };
+
+ light-key {
+ label = "Light";
+ gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_LIGHTS_TOGGLE>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_led_ctrl>;
+
+ led {
+ color = <LED_COLOR_ID_WHITE>;
+ function = LED_FUNCTION_FLASH;
+ gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+
+ poweroff {
+ compatible = "gpio-poweroff";
+ gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_poweroff>;
+ };
+
+ reg_vref: regulator-vref-4v2 {
+ compatible = "regulator-fixed";
+ regulator-name = "VREF_4V2";
+ regulator-min-microvolt = <4200000>;
+ regulator-max-microvolt = <4200000>;
+ };
+
+ reg_vsd: regulator-vsd {
+ compatible = "regulator-fixed";
+ regulator-name = "VSD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+&adc1 {
+ #io-channel-cells = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_adc>;
+ vref-supply = <®_vref>;
+ status = "okay";
+};
+
+&csi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_csi>;
+ status = "okay";
+
+ port {
+ parallel_from_gc0308: endpoint {
+ remote-endpoint = <&gc0308_to_parallel>;
+ };
+ };
+};
+
+&ecspi3 {
+ cs-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_spi3>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "inanbo,t28cp45tn89-v17";
+ reg = <0>;
+ backlight = <&panel_backlight>;
+ power-supply = <®_vsd>;
+ spi-cpha;
+ spi-cpol;
+ spi-max-frequency = <1000000>;
+ spi-rx-bus-width = <0>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+ };
+};
+
+&gpio1 {
+ ir-reset-hog {
+ gpio-hog;
+ gpios = <3 GPIO_ACTIVE_LOW>;
+ line-name = "ir-reset-gpio";
+ output-low;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_ir_reset>;
+ };
+};
+
+&gpio2 {
+ /* configuring this to output-high results in poweroff */
+ power-en-hog {
+ gpio-hog;
+ gpios = <6 GPIO_ACTIVE_HIGH>;
+ line-name = "power-en-gpio";
+ output-low;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_poweroff2>;
+ };
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_i2c1>;
+ status = "okay";
+
+ camera@21 {
+ compatible = "galaxycore,gc0308";
+ reg = <0x21>;
+ clocks = <&clks IMX6UL_CLK_CSI>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_gc0308>;
+ powerdown-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 6 GPIO_ACTIVE_LOW>;
+ vdd28-supply = <®_vsd>;
+
+ port {
+ gc0308_to_parallel: endpoint {
+ remote-endpoint = <¶llel_from_gc0308>;
+ bus-width = <8>;
+ data-shift = <2>; /* lines 9:2 are used */
+ hsync-active = <1>; /* active high */
+ vsync-active = <1>; /* active high */
+ data-active = <1>; /* active high */
+ pclk-sample = <1>; /* sample on rising edge */
+ };
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_i2c2>;
+ status = "okay";
+
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&lcdif {
+ assigned-clocks = <&clks IMX6UL_CLK_LCDIF_PRE_SEL>;
+ assigned-clock-parents = <&clks IMX6UL_CLK_PLL5_VIDEO_DIV>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_lcd_data>, <&mux_lcd_ctrl>;
+ status = "okay";
+
+ port {
+ display_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_pwm>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_uart>;
+ status = "okay";
+};
+
+&usbotg1 {
+ /* USB-C connector */
+ disable-over-current;
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbotg2 {
+ /* thermal sensor */
+ disable-over-current;
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usbphy1 {
+ fsl,tx-d-cal = <106>;
+};
+
+&usbphy2 {
+ fsl,tx-d-cal = <106>;
+};
+
+&usdhc1 {
+ /* MicroSD */
+ cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
+ keep-power-in-suspend;
+ no-1-8-v;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&mux_sdhc1>, <&mux_sdhc1_cd>;
+ pinctrl-1 = <&mux_sdhc1_100mhz>, <&mux_sdhc1_cd>;
+ pinctrl-2 = <&mux_sdhc1_200mhz>, <&mux_sdhc1_cd>;
+ wakeup-source;
+ vmmc-supply = <®_vsd>;
+ status = "okay";
+};
+
+&usdhc2 {
+ /* eMMC */
+ keep-power-in-suspend;
+ no-1-8-v;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_sdhc2>;
+ wakeup-source;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mux_wdog>;
+};
+
+&iomuxc {
+ mux_adc: adcgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO07__GPIO1_IO07 0xb0
+ >;
+ };
+
+ mux_backlight_enable: blenablegrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO09__GPIO1_IO09 0x3008
+ >;
+ };
+
+ mux_charger_stat1: charger1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO01__GPIO1_IO01 0x3008
+ >;
+ };
+
+ mux_charger_stat2: charger2grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO02__GPIO1_IO02 0x3008
+ >;
+ };
+
+ mux_csi: csi1grp {
+ fsl,pins = <
+ MX6UL_PAD_CSI_PIXCLK__CSI_PIXCLK 0x1b088
+ MX6UL_PAD_CSI_VSYNC__CSI_VSYNC 0x1b088
+ MX6UL_PAD_CSI_HSYNC__CSI_HSYNC 0x1b088
+ MX6UL_PAD_CSI_DATA00__CSI_DATA02 0x1b088
+ MX6UL_PAD_CSI_DATA01__CSI_DATA03 0x1b088
+ MX6UL_PAD_CSI_DATA02__CSI_DATA04 0x1b088
+ MX6UL_PAD_CSI_DATA03__CSI_DATA05 0x1b088
+ MX6UL_PAD_CSI_DATA04__CSI_DATA06 0x1b088
+ MX6UL_PAD_CSI_DATA05__CSI_DATA07 0x1b088
+ MX6UL_PAD_CSI_DATA06__CSI_DATA08 0x1b088
+ MX6UL_PAD_CSI_DATA07__CSI_DATA09 0x1b088
+ >;
+ };
+
+ mux_gc0308: gc0308grp {
+ fsl,pins = <
+ MX6UL_PAD_CSI_MCLK__CSI_MCLK 0x1e038
+ MX6UL_PAD_GPIO1_IO05__GPIO1_IO05 0x1b088
+ MX6UL_PAD_GPIO1_IO06__GPIO1_IO06 0x1b088
+ >;
+ };
+
+ mux_gpio_keys: gpiokeygrp {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_TX_DATA0__GPIO2_IO11 0x3008
+ MX6UL_PAD_ENET2_TX_DATA1__GPIO2_IO12 0x3008
+ MX6UL_PAD_ENET2_TX_EN__GPIO2_IO13 0x3008
+ MX6UL_PAD_ENET2_RX_EN__GPIO2_IO10 0x3008
+ MX6UL_PAD_ENET2_RX_DATA1__GPIO2_IO09 0x3008
+ MX6UL_PAD_ENET2_RX_ER__GPIO2_IO15 0x3008
+ MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08 0x3008
+ MX6UL_PAD_ENET2_TX_CLK__GPIO2_IO14 0x3008
+ MX6UL_PAD_ENET1_TX_DATA0__GPIO2_IO03 0x3008
+ MX6UL_PAD_ENET1_RX_DATA1__GPIO2_IO01 0x3008
+ >;
+ };
+
+ mux_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART4_TX_DATA__I2C1_SCL 0x4001b8b0
+ MX6UL_PAD_UART4_RX_DATA__I2C1_SDA 0x4001b8b0
+ >;
+ };
+
+ mux_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6UL_PAD_UART5_TX_DATA__I2C2_SCL 0x4001f8a8
+ MX6UL_PAD_UART5_RX_DATA__I2C2_SDA 0x4001f8a8
+ >;
+ };
+
+ mux_ir_reset: irresetgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0x3008
+ >;
+ };
+
+ mux_lcd_ctrl: lcdifctrlgrp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_CLK__LCDIF_CLK 0x79
+ MX6UL_PAD_LCD_ENABLE__LCDIF_ENABLE 0x79
+ MX6UL_PAD_LCD_HSYNC__LCDIF_HSYNC 0x79
+ MX6UL_PAD_LCD_VSYNC__LCDIF_VSYNC 0x79
+ >;
+ };
+
+ mux_lcd_data: lcdifdatgrp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_DATA00__LCDIF_DATA00 0x79
+ MX6UL_PAD_LCD_DATA01__LCDIF_DATA01 0x79
+ MX6UL_PAD_LCD_DATA02__LCDIF_DATA02 0x79
+ MX6UL_PAD_LCD_DATA03__LCDIF_DATA03 0x79
+ MX6UL_PAD_LCD_DATA04__LCDIF_DATA04 0x79
+ MX6UL_PAD_LCD_DATA05__LCDIF_DATA05 0x79
+ MX6UL_PAD_LCD_DATA06__LCDIF_DATA06 0x79
+ MX6UL_PAD_LCD_DATA07__LCDIF_DATA07 0x79
+ MX6UL_PAD_LCD_DATA08__LCDIF_DATA08 0x79
+ MX6UL_PAD_LCD_DATA09__LCDIF_DATA09 0x79
+ MX6UL_PAD_LCD_DATA10__LCDIF_DATA10 0x79
+ MX6UL_PAD_LCD_DATA11__LCDIF_DATA11 0x79
+ MX6UL_PAD_LCD_DATA12__LCDIF_DATA12 0x79
+ MX6UL_PAD_LCD_DATA13__LCDIF_DATA13 0x79
+ MX6UL_PAD_LCD_DATA14__LCDIF_DATA14 0x79
+ MX6UL_PAD_LCD_DATA15__LCDIF_DATA15 0x79
+ MX6UL_PAD_LCD_DATA16__LCDIF_DATA16 0x79
+ MX6UL_PAD_LCD_DATA17__LCDIF_DATA17 0x79
+ >;
+ };
+
+ mux_led_ctrl: ledctrlgrp {
+ fsl,pins = <
+ MX6UL_PAD_ENET1_RX_EN__GPIO2_IO02 0x3008
+ >;
+ };
+
+ mux_poweroff: poweroffgrp {
+ fsl,pins = <
+ MX6UL_PAD_ENET1_TX_DATA1__GPIO2_IO04 0x3008
+ >;
+ };
+
+ mux_poweroff2: poweroff2grp {
+ fsl,pins = <
+ MX6UL_PAD_ENET1_TX_CLK__GPIO2_IO06 0x3008
+ >;
+ };
+
+ mux_pwm: pwm1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO08__PWM1_OUT 0x110b0
+ >;
+ };
+
+ mux_sdhc1: sdhc1grp {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10071
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+ >;
+ };
+
+ mux_sdhc1_100mhz: sdhc1-100mhz-grp {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x170b9
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x170b9
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170b9
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170b9
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170b9
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170b9
+ >;
+ };
+
+ mux_sdhc1_200mhz: sdhc1-200mhz-grp {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x170f9
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x170f9
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170f9
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170f9
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170f9
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170f9
+ >;
+ };
+
+ mux_sdhc1_cd: sdhc1-cd-grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x17059
+ >;
+ };
+
+ mux_sdhc2: sdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x10069
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x17059
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x17059
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x17059
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x17059
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x17059
+ MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x17059
+ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x17059
+ MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x17059
+ MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x17059
+ >;
+ };
+
+ mux_spi3: ecspi3grp {
+ fsl,pins = <
+ MX6UL_PAD_UART2_CTS_B__ECSPI3_MOSI 0x100b1
+ MX6UL_PAD_UART2_RX_DATA__ECSPI3_SCLK 0x100b1
+ MX6UL_PAD_UART2_TX_DATA__GPIO1_IO20 0x3008
+ >;
+ };
+
+ mux_uart: uartgrp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+ >;
+ };
+
+ mux_wdog: wdoggrp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_RESET__WDOG1_WDOG_ANY 0x30b0
+ >;
+ };
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v6 0/1] UNI-T UTi260B support
From: Sebastian Reichel @ 2024-03-25 21:19 UTC (permalink / raw)
To: Sebastian Reichel, Shawn Guo, Sascha Hauer, Fabio Estevam
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Pengutronix Kernel Team, imx, linux-arm-kernel, devicetree,
linux-kernel, Sebastian Reichel
From: Sebastian Reichel <sebastian.reichel@collabora.com>
Hi,
This adds adds support for the i.MX6ULL based UNI-T UTi260B thermal camera.
The DT is based on reverse engineered information. More information about
the device can be found in this presentation from Embedded Recipes 2023:
* https://embedded-recipes.org/2023/wp-content/uploads/2023/10/Running-FOSS-on-a-Thermal-Camera-Sebastian-Reichel-compressed.pdf
* https://www.youtube.com/watch?v=uvObsCG-Cqo
make -j4 CHECK_DTBS=y nxp/imx/imx6ull-uti260b.dtb reports no issues.
I also prepared a branch with these patches (and a minimal kernel config)
and published it here:
https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-misc.git/log/?h=uti260b
Changes since PATCHv5:
* https://lore.kernel.org/all/20240226212740.2019837-1-sre@kernel.org/
- rebase to v6.9-rc1
- drop merged patches (all but DTS)
Changes since PATCHv4:
* https://lore.kernel.org/all/20240224213240.1854709-1-sre@kernel.org/
- drop merged patches
- use new NXP mailing list
- UTi260B board DT: change patch title
- UTi260B board DT: fix node order
Changes since PATCHv3:
* https://lore.kernel.org/all/20240216223654.1312880-1-sre@kernel.org/
- weim binding: use " instead of '
- weim binding: use "if: not: required: - foo" instead of "if: properties: foo: false"
- imx6ull-uti260b.dts: merge ecspi3_csgrp into ecspi3grp
- collect Reviewed-by from Krzysztof Kozlowski
Changes since PATCHv2:
* https://lore.kernel.org/all/20240213010347.1075251-1-sre@kernel.org/
- drop fsl,imx-asrc YAML binding conversion (merged)
- collect a bunch of Reviewed-by/Acked-by tags
- weim DT binding: fix issue with requirements
- xnur-gpio -> xnur-gpios change: Improve patch long description
Changes since PATCHv1:
* https://lore.kernel.org/all/20240210012114.489102-1-sre@kernel.org/
- uni-t,imx6ull-uti260b -> uni-t,uti260b
- add Acked-by for uni-t vendor prefix
- add Acked-by for HDMI audio index fix
- add Acked-by for LCDIF power-domain requirement drop
- anatop DT binding: Fixed indentation in example
- anatop DT binding: Described IRQs
- touchscreen DT binding: change tsc@ to touchscreen@ in example
- touchscreen DT binding: change xnur-gpio to xnur-gpios
- weim DT binding: drop acme,whatever example
- weim DT binding: use flash@ instead of nor@
- weim DT binding: update weim.txt reference in arcx,anybus-controller.txt
- weim DT binding: switch to memory-controller binding
- fsl,imx-asrc DT binding: fix ASoC patch subject prefix
- fsl,imx-asrc DT binding: add constraints
- add new patch fixing xnur-gpio(s) in all i.MX6UL board DT files
- add new patch fixing touchscreen nodename in i.MX6UL SoC DT file
- add new patch fixing weim nodename in all i.MX SoC DT files
- device DTS: use color/functions for the led
- device DTS: increase SPI speed
- device DTS: add comment for SD / eMMC node
Unadressed feedback from PATCHv1:
- anatop phandle vs parent: technically it makes sense to just use the
parent, but this driver is only used by i.MX6. The current code makes
use of the phandle, so we cannot drop it because of backwards
compatibility. So I don't see a point in deprecating this property.
- touchscreen binding: I kept measure-delay-time and pre-charge-time
values in hex, since that is being used everywhere and the unit
is unknown. The values are directly written into HW registers and
the i.MX6UL TRM does not provide any hints about the unit. I do not
have an i.MX6UL device with a touchsreen, so I cannot test either.
- regulator name in DT: I did not rename the regulators to just
"regulator", since the nodename must be unique.
Greetings,
-- Sebastian
Sebastian Reichel (1):
ARM: dts: imx: Add UNI-T UTi260B thermal camera board
arch/arm/boot/dts/nxp/imx/Makefile | 1 +
arch/arm/boot/dts/nxp/imx/imx6ull-uti260b.dts | 566 ++++++++++++++++++
2 files changed, 567 insertions(+)
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-uti260b.dts
--
2.43.0
^ permalink raw reply
* Re: [PATCH v4 4/7] dt-bindings: iio: accel: adxl345: Add spi-3wire
From: Krzysztof Kozlowski @ 2024-03-25 21:40 UTC (permalink / raw)
To: Lothar Rubusch
Cc: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <CAFXKEHbJ_5unY24aZeutvM-xrjevQ=z7ngDcgwJR=NXzXONx5A@mail.gmail.com>
On 25/03/2024 22:05, Lothar Rubusch wrote:
> On Mon, Mar 25, 2024 at 7:32 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 25/03/2024 16:33, Lothar Rubusch wrote:
>>> Add spi-3wire because the driver optionally supports spi-3wire.
>>
>> This is a friendly reminder during the review process.
>>
>> It seems my or other reviewer's previous comments were not fully
>> addressed. Maybe the feedback got lost between the quotes, maybe you
>> just forgot to apply it. Please go back to the previous discussion and
>> either implement all requested changes or keep discussing them.
>>
>> Thank you.
>>
>
> You refer yourself to the above mentioned wording. Would replacing
> "driver" by "device" in the dt-bindings patch comment be sufficient?
> Did I miss something else?
Yes, the wording, but isn't the device require 3-wire mode? Don't just
replace one word with another, but write the proper rationale for your
hardware.
>
>>>
>>> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
>>> ---
>>
>> This is a friendly reminder during the review process.
>>
>> It looks like you received a tag and forgot to add it.
>>
>> 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
>
> Just for confirmation: when I receive a feedback, requesting a change.
> And, I accept the change request. This means, I received a tag
> "Reviewed-by" which I have to mention in the upcoming patch version
> where this change is implemented and in that particular patch?
Please go through the docs. Yes, you received a tag which should be
included with the change.
Reviewer's feedback should not be ignored.
>
>> the tags. The upstream maintainer will do that for tags received on the
>> version they apply.
>>
>
> I'm pretty sure we will still see further iterations. So, I apply the
> tags in the next version, already scheduled. Ok?
>
>> https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
>>
>
> Going over the books I feel it does not make sense to still mention
> feedback ("Reveiewed-by") for the v1 or v2 of the patch here in a v5,
> does it? Your link mentiones "However if the patch has changed
I don't understand. When did you receive the tag? v3, right? So what do
you mean by v1 and v2?
Best regards,
Krzysztof
^ 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