* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Svyatoslav Ryhel @ 2026-04-19 13:46 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419143751.11ec0b69@jic23-huawei>
нд, 19 квіт. 2026 р. о 16:38 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Sun, 19 Apr 2026 11:31:23 +0300
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
>
> A Sashiko review comment makes me wonder about one thing below if the
> register set does match. Maybe it's a bit more subtle than this
> patch description suggests?
>
> > just add the correct bindings and the appropriate LUX table derived from
> > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > index c8f15ba95267..8dab34bf00ca 100644
> > --- a/drivers/iio/light/tsl2772.c
> > +++ b/drivers/iio/light/tsl2772.c
> > @@ -127,6 +127,7 @@ enum {
> > tmd2672,
> > tsl2772,
> > tmd2772,
> > + apds990x,
> > apds9930,
> > };
> >
> > @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > { 0, 0 },
> > };
> >
> > +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > + { 52000, 115960 },
> > + { 36400, 73840 },
> > + { 0, 0 },
> > +};
> > +
> > static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > { 52000, 96824 },
> > { 38792, 67132 },
> > @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > [tmd2672] = tmd2x72_lux_table,
> > [tsl2772] = tsl2x72_lux_table,
> > [tmd2772] = tmd2x72_lux_table,
> > + [apds990x] = apds990x_lux_table,
> > [apds9930] = apds9930_lux_table,
> > };
> >
> > @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> > [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> > };
> >
> > @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> > [tmd2672] = PRX2,
> > [tsl2772] = ALSPRX2,
> > [tmd2772] = ALSPRX2,
> > + [apds990x] = ALSPRX,
>
> This is different from tsl2772?
yes, lux table is different and made according to datasheet,
tsl2772_int_time_avail differs, ALSPRX configuration assumes that
proximity sensor needs no calibration which is true for apds9900/1
while tsl2772 needs calibration, device ID is different 0x20/0x29 for
apds and 0x30 for tsl2772
>
> > [apds9930] = ALSPRX2,
> > };
>
^ permalink raw reply
* Re: [PATCH v2 3/4] staging: iio: magnetometer: Add QST QMC5883P driver
From: Hardik Phalet @ 2026-04-19 14:30 UTC (permalink / raw)
To: David Lechner, Hardik Phalet, Greg Kroah-Hartman
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Brigham Campbell, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-staging
In-Reply-To: <2d966423-52b5-4b8a-a4d1-0edcd93a841b@baylibre.com>
On Mon Apr 13, 2026 at 12:22 AM IST, David Lechner wrote:
> On 4/12/26 4:54 AM, Hardik Phalet wrote:
>> On Sat Apr 11, 2026 at 1:32 AM IST, David Lechner wrote:
>>> On 4/9/26 4:07 PM, Hardik Phalet wrote:
>>>
>>> This is a little bit much to review all in one patch. Could be nice
>>> to split out power management to a separate patch.
>>>
>
> ...
>
>>>> +static IIO_DEVICE_ATTR(downsampling_ratio, 0644, downsampling_ratio_show,
>>>> + downsampling_ratio_store, 0);
>>>> +static IIO_CONST_ATTR(downsampling_ratio_available, "1 2 4 8");
>>>
>>> As mentioned in the cover letter, we'd like to know more about what
>>> this actually does. If there is a good reason it doesn't fit with
>>> any existing filter attribute, then we'll need a patch to document
>>> the sysfs ABI as well.
>>>
>> In the device datasheet, OSR2("Down sampling ratio") is mentioned like this:
>> "Another filter is added for better noise performance; the depth can be
>> adjusted through OSR2". OSR2's defintion is called "down sampling ratio"
>> in a table. Nowhere else. I didn't know what attribute to map it to in
>> this case.
>>
> I wonder if there is an application note or something that explains it
> in more detail if the datasheet does not.
>
I could not find any mention of it, in an application note or otherwise.
I cannot confirm what this does, unless I get an oscilloscope and figure
it out.
> We could always omit the feature if no one knows what it actually does.
Yes that's what I am planning to do.
Regards,
Hardik
^ permalink raw reply
* [PATCH] arm64: dts: amlogic: add support for Amedia X98Q
From: christian.koever-draxl @ 2026-04-19 15:08 UTC (permalink / raw)
To: neil.armstrong, khilman
Cc: linux-amlogic, devicetree, linux-arm-kernel,
Christian Stefan Kövér-Draxl
From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
The X98Q is a TV box based on the Amlogic S4 (S905W2) SoC.
Add the device tree for this board and document the compatible string.
Supported features:
- 1GB/2GB RAM (via U-Boot memory fixup)
- 10/100 Ethernet (Internal PHY)
- eMMC and SD card storage
- PWM-based CPU voltage regulation
- UART (Serial console)
Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
---
- The Wi-Fi chip on this board is Amlogic W150S1. I have left the SDIO node enabled
but omitted the specific chip sub-node due to lack of mainline drivers (yet).
- The console uses uart_b at 921600 baud.
- Verified memory via /proc/device-tree; U-Boot patches the node to around 2GB if board supports more than 1GB.
- Tested on the 2GB RAM plus 16GB EMMC variant.
.../devicetree/bindings/arm/amlogic.yaml | 7 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 244 ++++++++++++++++++
3 files changed, 252 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index a885278bc4e2..82671d58d1da 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -254,6 +254,13 @@ properties:
- khadas,vim1s
- const: amlogic,s905y4
- const: amlogic,s4
+
+ - description: Boards with the Amlogic Meson S4 S905W2 SoC
+ items:
+ - enum:
+ - amediatech,x98q
+ - const: amlogic,s905w2
+ - const: amlogic,s4
- description: Boards with the Amlogic S6 S905X5 SoC
items:
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 15f9c817e502..6f0bdd5bdca2 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -86,6 +86,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-s4-s805x2-aq222.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905y4-khadas-vim1s.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905w2-x98q.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air-gbit.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m2-pro.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
new file mode 100644
index 000000000000..f2db01730a3d
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
@@ -0,0 +1,244 @@
+
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2026 Christian Stefan Köver-Draxl
+ */
+
+/dts-v1/;
+
+#include "meson-s4.dtsi"
+
+/ {
+ model = "Shenzhen Amedia X98Q";
+ compatible = "amediatech,x98q", "amlogic,s905w2", "amlogic,s4";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ mmc0 = &emmc; /* eMMC */
+ mmc1 = &sd; /* SD card */
+ mmc2 = &sdio; /* SDIO */
+ serial0 = &uart_b;
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x40000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 52 MiB reserved for ARM Trusted Firmware */
+ secmon_reserved: secmon@5000000 {
+ reg = <0x0 0x05000000 0x0 0x3400000>;
+ no-map;
+ };
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio GPIOB_9 GPIO_ACTIVE_LOW>;
+ };
+
+ sdio_32k: sdio-32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&sdio_32k>;
+ clock-names = "ext_clock";
+ };
+
+ main_5v: regulator-main-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ sd_3v3: regulator-sd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "SD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio GPIOD_4 GPIO_ACTIVE_LOW>;
+ regulator-always-on;
+ };
+
+ vddio_sd: regulator-vddio-sd {
+ compatible = "regulator-gpio";
+ regulator-name = "VDDIO_SD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <1800000 1
+ 3300000 0>;
+ };
+
+ vddao_3v3: regulator-vddao-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&main_5v>;
+ regulator-always-on;
+ };
+
+ vddio_ao1v8: regulator-vddio-ao1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ /* SY8120B1ABC DC/DC Regulator. */
+ vddcpu: regulator-vddcpu {
+ compatible = "pwm-regulator";
+
+ regulator-name = "VDDCPU";
+ regulator-min-microvolt = <689000>;
+ regulator-max-microvolt = <1049000>;
+
+ vin-supply = <&main_5v>;
+
+ pwms = <&pwm_ij 1 1500 0>;
+ pwm-dutycycle-range = <100 0>;
+
+ regulator-boot-on;
+ regulator-always-on;
+ /* Voltage Duty-Cycle */
+ voltage-table = <1049000 0>,
+ <1039000 3>,
+ <1029000 6>,
+ <1019000 9>,
+ <1009000 12>,
+ <999000 14>,
+ <989000 17>,
+ <979000 20>,
+ <969000 23>,
+ <959000 26>,
+ <949000 29>,
+ <939000 31>,
+ <929000 34>,
+ <919000 37>,
+ <909000 40>,
+ <899000 43>,
+ <889000 45>,
+ <879000 48>,
+ <869000 51>,
+ <859000 54>,
+ <849000 56>,
+ <839000 59>,
+ <829000 62>,
+ <819000 65>,
+ <809000 68>,
+ <799000 70>,
+ <789000 73>,
+ <779000 76>,
+ <769000 79>,
+ <759000 81>,
+ <749000 84>,
+ <739000 87>,
+ <729000 89>,
+ <719000 92>,
+ <709000 95>,
+ <699000 98>,
+ <689000 100>;
+ };
+};
+
+&emmc {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
+ pinctrl-1 = <&emmc_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+};
+
+ðmac {
+ status = "okay";
+ phy-handle = <&internal_ephy>;
+ phy-mode = "rmii";
+};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_pins>;
+ pinctrl-names = "default";
+};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins1>;
+ pinctrl-names = "default";
+};
+
+&pwm_ij {
+ status = "okay";
+};
+
+&sd {
+ status = "okay";
+ pinctrl-0 = <&sdcard_pins>;
+ pinctrl-1 = <&sdcard_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <50000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddao_3v3>;
+};
+
+&sdio {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-1 = <&sdio_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ no-sd;
+ no-mmc;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+};
+
+&uart_b {
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: amlogic: add support for Amedia X98Q
From: Ferass El Hafidi @ 2026-04-19 15:19 UTC (permalink / raw)
To: linux-amlogic, christian.koever-draxl, neil.armstrong, khilman
Cc: linux-amlogic, devicetree, linux-arm-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260419150855.121136-1-christian.koever-draxl@student.uibk.ac.at>
Hi, some drive-by feedback
On Sun, 19 Apr 2026 15:08, christian.koever-draxl@student.uibk.ac.at wrote:
>From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
>The X98Q is a TV box based on the Amlogic S4 (S905W2) SoC.
>Add the device tree for this board and document the compatible string.
>
>Supported features:
>- 1GB/2GB RAM (via U-Boot memory fixup)
>- 10/100 Ethernet (Internal PHY)
>- eMMC and SD card storage
>- PWM-based CPU voltage regulation
>- UART (Serial console)
>
>Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>---
>- The Wi-Fi chip on this board is Amlogic W150S1. I have left the SDIO node enabled
> but omitted the specific chip sub-node due to lack of mainline drivers (yet).
>- The console uses uart_b at 921600 baud.
>- Verified memory via /proc/device-tree; U-Boot patches the node to around 2GB if board supports more than 1GB.
>- Tested on the 2GB RAM plus 16GB EMMC variant.
>
> .../devicetree/bindings/arm/amlogic.yaml | 7 +
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 244 ++++++++++++++++++
> 3 files changed, 252 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>
>diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
>index a885278bc4e2..82671d58d1da 100644
>--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
>+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
>@@ -254,6 +254,13 @@ properties:
> - khadas,vim1s
> - const: amlogic,s905y4
> - const: amlogic,s4
>+
>+ - description: Boards with the Amlogic Meson S4 S905W2 SoC
>+ items:
>+ - enum:
>+ - amediatech,x98q
>+ - const: amlogic,s905w2
>+ - const: amlogic,s4
>
> - description: Boards with the Amlogic S6 S905X5 SoC
> items:
It is better to send the dt-binding changes separate from the actual
DTS. The golden rule is one commit per change.
You can (and should) send both patches as part of a patch series.
>diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
>index 15f9c817e502..6f0bdd5bdca2 100644
>--- a/arch/arm64/boot/dts/amlogic/Makefile
>+++ b/arch/arm64/boot/dts/amlogic/Makefile
>@@ -86,6 +86,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-s4-s805x2-aq222.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905y4-khadas-vim1s.dtb
>+dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905w2-x98q.dtb
Keep this file in alphabetic order.
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air-gbit.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m2-pro.dtb
>diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>new file mode 100644
>index 000000000000..f2db01730a3d
>--- /dev/null
>+++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>@@ -0,0 +1,244 @@
>+
>+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>+/*
>+ * Copyright (c) 2026 Christian Stefan Köver-Draxl
>+ */
Did you base this DTS on another DTS that is already upstream? This
looks a lot like
https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts?h=v7.1/arm64-dt
If so, then you should keep their copyright. Something like:
/*
* Copyright (c) 2026 Christian Stefan Köver-Draxl
* Based on <...>:
* - Copyright (c) <authors of the DTB this one is based on>
*/
Correct me if I'm wrong.
>+
>+/dts-v1/;
>+
>+#include "meson-s4.dtsi"
>+
>+/ {
>+ model = "Shenzhen Amedia X98Q";
Shouldn't this be
model = "Shenzhen Amediatech Technology Co., Ltd X98Q";
?
There are other Amediatech boards supported currently:
dts/amlogic/meson-g12a-x96-max.dts: model = "Shenzhen Amediatech Technology Co., Ltd X96 Max";
dts/amlogic/meson-sm1-x96-air-gbit.dts: model = "Shenzhen Amediatech Technology Co., Ltd X96 Air";
dts/amlogic/meson-sm1-x96-air.dts: model = "Shenzhen Amediatech Technology Co., Ltd X96 Air";
I think it might be preferable to use a similar model format for
consistency.
It is also the documented vendor prefix for amediatech. (see
Documentation/devicetree/bindings/vendor-prefixes.yaml)
>+ compatible = "amediatech,x98q", "amlogic,s905w2", "amlogic,s4";
>+ interrupt-parent = <&gic>;
>+ #address-cells = <2>;
>+ #size-cells = <2>;
>+
>+ aliases {
>+ mmc0 = &emmc; /* eMMC */
>+ mmc1 = &sd; /* SD card */
>+ mmc2 = &sdio; /* SDIO */
>+ serial0 = &uart_b;
>+ };
>+
>+ memory@0 {
>+ device_type = "memory";
>+ reg = <0x0 0x0 0x0 0x40000000>;
>+ };
>+
>+ reserved-memory {
>+ #address-cells = <2>;
>+ #size-cells = <2>;
>+ ranges;
>+
>+ /* 52 MiB reserved for ARM Trusted Firmware */
>+ secmon_reserved: secmon@5000000 {
>+ reg = <0x0 0x05000000 0x0 0x3400000>;
>+ no-map;
>+ };
>+ };
>+
>+ emmc_pwrseq: emmc-pwrseq {
>+ compatible = "mmc-pwrseq-emmc";
>+ reset-gpios = <&gpio GPIOB_9 GPIO_ACTIVE_LOW>;
>+ };
>+
>+ sdio_32k: sdio-32k {
>+ compatible = "pwm-clock";
>+ #clock-cells = <0>;
>+ clock-frequency = <32768>;
>+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
>+ };
>+
>+ sdio_pwrseq: sdio-pwrseq {
>+ compatible = "mmc-pwrseq-simple";
>+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
>+ clocks = <&sdio_32k>;
>+ clock-names = "ext_clock";
>+ };
>+
>+ main_5v: regulator-main-5v {
>+ compatible = "regulator-fixed";
>+ regulator-name = "5V";
>+ regulator-min-microvolt = <5000000>;
>+ regulator-max-microvolt = <5000000>;
>+ regulator-always-on;
>+ };
>+
>+ sd_3v3: regulator-sd-3v3 {
>+ compatible = "regulator-fixed";
>+ regulator-name = "SD_3V3";
>+ regulator-min-microvolt = <3300000>;
>+ regulator-max-microvolt = <3300000>;
>+ gpio = <&gpio GPIOD_4 GPIO_ACTIVE_LOW>;
>+ regulator-always-on;
>+ };
>+
>+ vddio_sd: regulator-vddio-sd {
>+ compatible = "regulator-gpio";
>+ regulator-name = "VDDIO_SD";
>+ regulator-min-microvolt = <1800000>;
>+ regulator-max-microvolt = <3300000>;
>+ gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
>+ gpios-states = <1>;
>+ states = <1800000 1
>+ 3300000 0>;
nit: keep this in one line.
>+ };
>+
>+ vddao_3v3: regulator-vddao-3v3 {
>+ compatible = "regulator-fixed";
>+ regulator-name = "VDDAO_3V3";
>+ regulator-min-microvolt = <3300000>;
>+ regulator-max-microvolt = <3300000>;
>+ vin-supply = <&main_5v>;
>+ regulator-always-on;
>+ };
>+
>+ vddio_ao1v8: regulator-vddio-ao1v8 {
>+ compatible = "regulator-fixed";
>+ regulator-name = "VDDIO_AO1V8";
>+ regulator-min-microvolt = <1800000>;
>+ regulator-max-microvolt = <1800000>;
>+ vin-supply = <&vddao_3v3>;
>+ regulator-always-on;
>+ };
>+
>+ /* SY8120B1ABC DC/DC Regulator. */
>+ vddcpu: regulator-vddcpu {
>+ compatible = "pwm-regulator";
>+
>+ regulator-name = "VDDCPU";
>+ regulator-min-microvolt = <689000>;
>+ regulator-max-microvolt = <1049000>;
>+
>+ vin-supply = <&main_5v>;
>+
>+ pwms = <&pwm_ij 1 1500 0>;
>+ pwm-dutycycle-range = <100 0>;
>+
>+ regulator-boot-on;
>+ regulator-always-on;
>+ /* Voltage Duty-Cycle */
>+ voltage-table = <1049000 0>,
>+ <1039000 3>,
>+ <1029000 6>,
>+ <1019000 9>,
>+ <1009000 12>,
>+ <999000 14>,
>+ <989000 17>,
>+ <979000 20>,
>+ <969000 23>,
>+ <959000 26>,
>+ <949000 29>,
>+ <939000 31>,
>+ <929000 34>,
>+ <919000 37>,
>+ <909000 40>,
>+ <899000 43>,
>+ <889000 45>,
>+ <879000 48>,
>+ <869000 51>,
>+ <859000 54>,
>+ <849000 56>,
>+ <839000 59>,
>+ <829000 62>,
>+ <819000 65>,
>+ <809000 68>,
>+ <799000 70>,
>+ <789000 73>,
>+ <779000 76>,
>+ <769000 79>,
>+ <759000 81>,
>+ <749000 84>,
>+ <739000 87>,
>+ <729000 89>,
>+ <719000 92>,
>+ <709000 95>,
>+ <699000 98>,
>+ <689000 100>;
>+ };
>+};
>+
>+&emmc {
>+ status = "okay";
>+ pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
>+ pinctrl-1 = <&emmc_clk_gate_pins>;
>+ pinctrl-names = "default", "clk-gate";
>+
>+ bus-width = <8>;
>+ cap-mmc-highspeed;
>+ mmc-ddr-1_8v;
>+ mmc-hs200-1_8v;
>+ max-frequency = <200000000>;
>+ non-removable;
>+ disable-wp;
>+
>+ mmc-pwrseq = <&emmc_pwrseq>;
>+ vmmc-supply = <&vddao_3v3>;
>+ vqmmc-supply = <&vddio_ao1v8>;
>+};
>+
>+ðmac {
>+ status = "okay";
>+ phy-handle = <&internal_ephy>;
>+ phy-mode = "rmii";
>+};
>+
>+&ir {
>+ status = "okay";
>+ pinctrl-0 = <&remote_pins>;
>+ pinctrl-names = "default";
>+};
>+
>+&pwm_ef {
>+ status = "okay";
>+ pinctrl-0 = <&pwm_e_pins1>;
>+ pinctrl-names = "default";
>+};
>+
>+&pwm_ij {
>+ status = "okay";
>+};
>+
>+&sd {
>+ status = "okay";
>+ pinctrl-0 = <&sdcard_pins>;
>+ pinctrl-1 = <&sdcard_clk_gate_pins>;
>+ pinctrl-names = "default", "clk-gate";
>+ bus-width = <4>;
>+ cap-sd-highspeed;
>+ max-frequency = <50000000>;
>+ disable-wp;
>+
>+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
>+
>+ vmmc-supply = <&vddao_3v3>;
>+ vqmmc-supply = <&vddao_3v3>;
>+};
>+
>+&sdio {
>+ status = "okay";
>+ pinctrl-0 = <&sdio_pins>;
>+ pinctrl-1 = <&sdio_clk_gate_pins>;
>+ pinctrl-names = "default", "clk-gate";
>+ #address-cells = <1>;
>+ #size-cells = <0>;
>+ bus-width = <4>;
>+ cap-sd-highspeed;
>+ sd-uhs-sdr50;
>+ sd-uhs-sdr104;
>+ max-frequency = <200000000>;
>+ non-removable;
>+ disable-wp;
>+
>+ no-sd;
>+ no-mmc;
>+ mmc-pwrseq = <&sdio_pwrseq>;
>+ vmmc-supply = <&vddao_3v3>;
>+ vqmmc-supply = <&vddio_ao1v8>;
>+};
I suppose that's the Wi-Fi module you're talking about. I would put a comment
above to specify that it is indeed Wi-Fi and not yet supported.
Something like:
/*
* Wireless SDIO Module (Amlogic W150S1)
* Note: There is no driver for this at the moment.
*/
>+
>+&uart_b {
>+ status = "okay";
>+};
>--
>2.53.0
--
Best regards,
Ferass
^ permalink raw reply
* Re: [PATCH] arm64: dts: amlogic: add support for Amedia X98Q
From: Ferass El Hafidi @ 2026-04-19 15:42 UTC (permalink / raw)
To: linux-amlogic, christian.koever-draxl, neil.armstrong, khilman
Cc: linux-amlogic, devicetree, linux-arm-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260419150855.121136-1-christian.koever-draxl@student.uibk.ac.at>
On Sun, 19 Apr 2026 15:08, christian.koever-draxl@student.uibk.ac.at wrote:
>From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
>The X98Q is a TV box based on the Amlogic S4 (S905W2) SoC.
>Add the device tree for this board and document the compatible string.
>
>Supported features:
>- 1GB/2GB RAM (via U-Boot memory fixup)
>- 10/100 Ethernet (Internal PHY)
>- eMMC and SD card storage
>- PWM-based CPU voltage regulation
>- UART (Serial console)
>
>Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>---
>- The Wi-Fi chip on this board is Amlogic W150S1. I have left the SDIO node enabled
> but omitted the specific chip sub-node due to lack of mainline drivers (yet).
>- The console uses uart_b at 921600 baud.
>- Verified memory via /proc/device-tree; U-Boot patches the node to around 2GB if board supports more than 1GB.
>- Tested on the 2GB RAM plus 16GB EMMC variant.
>
Also, I just noticed now, but you seem to be missing a lot of people in
your To/Cc. You should use get_maintainer.pl to get the list of
the people you should send your patch to.
(you can also use b4 (v0.14 is what I use) to make sending patches
properly much easier)
--
Best regards,
Ferass
^ permalink raw reply
* Re: [PATCH 2/2] iio: dac: mcp47feb02: add MCP48FEB02 SPI driver to MCP47FEB02 I2C driver
From: Jonathan Cameron @ 2026-04-19 16:16 UTC (permalink / raw)
To: Ariana Lazar
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron, Conor Dooley,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260403-mcp47feb02-fix2-v1-2-da60c773550e@microchip.com>
On Fri, 3 Apr 2026 13:50:14 +0300
Ariana Lazar <ariana.lazar@microchip.com> wrote:
> This is the iio driver for Microchip MCP48FxBy1/2/4/8 series of
> buffered voltage output Digital-to-Analog Converters with nonvolatile or
> volatile memory on top of MCP47FEB02. The families support up to 8
> output channels and have 8-bit, 10-bit or 12-bit resolution.
>
> The MCP47FEB02 driver was split into three modules: mcp47feb02-core.c,
> mcp47feb02-i2c.c and mcp47feb02-spi.c in order to support both DAC families
> - I2C (MCP47F(E/V)BXX) and SPI (MCP48F(E/V)BXX).
Normal flow is to do a noop refactor for I2C + core split, then a follow
up patch to add anything new (SPI driver + any changes that are only needed
by SPI to the core module)
>
> Fixes: bf394cc80369 ("iio: dac: adding support for Microchip MCP47FEB02")
> Signed-off-by: Ariana Lazar <ariana.lazar@microchip.com>
> Link: https://lore.kernel.org/all/aY4yaVP2TQFRI1E4@smile.fi.intel.com/
> ---
> MAINTAINERS | 4 +
> drivers/iio/dac/Kconfig | 29 +-
> drivers/iio/dac/Makefile | 3 +
> drivers/iio/dac/mcp47feb02-core.c | 845 ++++++++++++++++++++++++++++++++++++++
> drivers/iio/dac/mcp47feb02-i2c.c | 145 +++++++
> drivers/iio/dac/mcp47feb02-spi.c | 145 +++++++
> drivers/iio/dac/mcp47feb02.h | 158 +++++++
Given the description I'm a bit lost on why there isn't a mass of code being
removed from mcp47feb02.c as it migrates to the core library.
Anyhow one thing I noticed whilst glancing through this.
> 7 files changed, 1328 insertions(+), 1 deletion(-)
> diff --git a/drivers/iio/dac/mcp47feb02-spi.c b/drivers/iio/dac/mcp47feb02-spi.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..82e99388ac75860d534d0f2cc05dcc6628d96f6b
> --- /dev/null
> +++ b/drivers/iio/dac/mcp47feb02-spi.c
> @@ -0,0 +1,145 @@
> +
> +static struct spi_driver mcp47feb02_spi_driver = {
> + .driver = {
> + .name = "mcp47feb02",
> + .of_match_table = mcp47feb02_of_spi_match,
As attempting to align = is already broken, that is pretty strong example
for why it is rarely worth the pain. I'd just use a single space before the =
in all cases.
> + .pm = pm_sleep_ptr(&mcp47feb02_pm_ops),
> + },
> + .probe = mcp47feb02_spi_probe,
> + .id_table = mcp47feb02_spi_id,
> +};
> +module_spi_driver(mcp47feb02_spi_driver);
^ permalink raw reply
* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Jonathan Cameron @ 2026-04-19 16:22 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <CAPVz0n1qrSYr16zSSqRHuTWVkRfdC+c9w+mxAhtzgfHzL41XFw@mail.gmail.com>
On Sun, 19 Apr 2026 16:41:24 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> нд, 19 квіт. 2026 р. о 16:33 Jonathan Cameron <jic23@kernel.org> пише:
> >
> > On Sun, 19 Apr 2026 11:31:24 +0300
> > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > > The Avago APDS9900/9901 ALS/Proximity sensor is now supported by tsl2772
> > > IIO driver so there is no need to keep this old implementation. Remove it.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > Documentation/misc-devices/apds990x.rst | 128 ---
> > Sashiko AI reviewing is now running on anything that hits linux-iio@vger.kernel.org
> >
> > I'm slowly getting into the habit of checking out what it finds though
> > I'm 500+ emails behind so it might not be that thorough today :*
> >
> > Anyhow, it caught an easy one here.
> >
> > This file is referenced from Documentation/misc-devices/index.rst
> > so that needs an update as well.
> >
>
> Good catch, index was not updated, I will do so in v3.
>
> > There is the obvious point of ABI compatibility raised as well, but given
> > we don't seem to be getting much push back on that maybe that's not a significant
> > concern.
>
> I did not found any ABI in the Documentation/ABI regarding this sensor
> using grep, maybe you are more familiar?
Doesn't matter if it's documented explicitly (many older drivers are not).
The question is whether anyone has supported parts and userspace code that
makes use of the sysfs files this driver provides.
Their userspace will be broken by dropping it. The lack of upstream users
makes this less critical but it can be argued it's still a possible regression.
Jonathan
>
> >
> > Jonathan
> >
> > > drivers/misc/Kconfig | 10 -
> > > drivers/misc/Makefile | 1 -
> > > drivers/misc/apds990x.c | 1284 -----------------------
> > > include/linux/platform_data/apds990x.h | 65 --
> > > 5 files changed, 1488 deletions(-)
> > > delete mode 100644 Documentation/misc-devices/apds990x.rst
> > > delete mode 100644 drivers/misc/apds990x.c
> > > delete mode 100644 include/linux/platform_data/apds990x.h
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Jonathan Cameron @ 2026-04-19 16:24 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <CAPVz0n1iB9iC+TFrGK5ajXjdk8-g8vzr4ZbXdvW5=F8iukanaA@mail.gmail.com>
On Sun, 19 Apr 2026 14:50:55 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> нд, 19 квіт. 2026 р. о 14:30 Jonathan Cameron <jic23@kernel.org> пише:
> >
> > On Sun, 19 Apr 2026 11:31:23 +0300
> > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> > > just add the correct bindings and the appropriate LUX table derived from
> > > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > Hi Svyatoslav,
> >
> > Just one small thing.
> >
> > Experience has given me a strong aversion to the use of wildcards
> > in naming within drivers. They go wrong too often because companies
> > can seem to resist using similar names for very different parts.
> >
>
> Noted.
>
> > > ---
> > > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > > index c8f15ba95267..8dab34bf00ca 100644
> > > --- a/drivers/iio/light/tsl2772.c
> > > +++ b/drivers/iio/light/tsl2772.c
> > > @@ -127,6 +127,7 @@ enum {
> > > tmd2672,
> > > tsl2772,
> > > tmd2772,
> > > + apds990x,
> >
> > As above, just name this after one of the supported parts. apds9900
> > That doesn't stop you using it for multiple compatible devices.
> >
> > Same applies for all the uses of x as a wildcard.
> >
>
> If this is the only thing keeping you from picking this patchset may I
> resend with apds990x fixed right away?
No. I'm just one reviewer - others may need more time. You should wait
at least a few days before sending a new version unless I've specifically
requested a rushed version.
I only do that if I'm trying to get something in at the end of a kernel
cycle or there are dependencies on a patch from others. In this case, neither
applies so please take your time. I'd normally suggest approximately a week.
Thanks,
Jonathan
>
> > thanks,
> >
> > Jonathan
> >
> > > apds9930,
> > > };
> >
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Jonathan Cameron @ 2026-04-19 16:24 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <CAPVz0n048kPMAnGQpOk0_SPtQ+hz=-p6jdyRYPB5d+CD9i7_Cw@mail.gmail.com>
On Sun, 19 Apr 2026 16:46:25 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> нд, 19 квіт. 2026 р. о 16:38 Jonathan Cameron <jic23@kernel.org> пише:
> >
> > On Sun, 19 Apr 2026 11:31:23 +0300
> > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> >
> > A Sashiko review comment makes me wonder about one thing below if the
> > register set does match. Maybe it's a bit more subtle than this
> > patch description suggests?
> >
> > > just add the correct bindings and the appropriate LUX table derived from
> > > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > > index c8f15ba95267..8dab34bf00ca 100644
> > > --- a/drivers/iio/light/tsl2772.c
> > > +++ b/drivers/iio/light/tsl2772.c
> > > @@ -127,6 +127,7 @@ enum {
> > > tmd2672,
> > > tsl2772,
> > > tmd2772,
> > > + apds990x,
> > > apds9930,
> > > };
> > >
> > > @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > { 0, 0 },
> > > };
> > >
> > > +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > + { 52000, 115960 },
> > > + { 36400, 73840 },
> > > + { 0, 0 },
> > > +};
> > > +
> > > static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > { 52000, 96824 },
> > > { 38792, 67132 },
> > > @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > > [tmd2672] = tmd2x72_lux_table,
> > > [tsl2772] = tsl2x72_lux_table,
> > > [tmd2772] = tmd2x72_lux_table,
> > > + [apds990x] = apds990x_lux_table,
> > > [apds9930] = apds9930_lux_table,
> > > };
> > >
> > > @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> > > [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> > > };
> > >
> > > @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> > > [tmd2672] = PRX2,
> > > [tsl2772] = ALSPRX2,
> > > [tmd2772] = ALSPRX2,
> > > + [apds990x] = ALSPRX,
> >
> > This is different from tsl2772?
>
> yes, lux table is different and made according to datasheet,
> tsl2772_int_time_avail differs, ALSPRX configuration assumes that
> proximity sensor needs no calibration which is true for apds9900/1
> while tsl2772 needs calibration, device ID is different 0x20/0x29 for
> apds and 0x30 for tsl2772
All makes sense but that means the patch description needs to be
more precise about what elements are compatible, or use vaguer wording
like 'similar to'.
Jonathan
>
> >
> > > [apds9930] = ALSPRX2,
> > > };
> >
>
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Svyatoslav Ryhel @ 2026-04-19 16:28 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419172458.375e7897@jic23-huawei>
нд, 19 квіт. 2026 р. о 19:25 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Sun, 19 Apr 2026 16:46:25 +0300
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > нд, 19 квіт. 2026 р. о 16:38 Jonathan Cameron <jic23@kernel.org> пише:
> > >
> > > On Sun, 19 Apr 2026 11:31:23 +0300
> > > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > >
> > > > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> > >
> > > A Sashiko review comment makes me wonder about one thing below if the
> > > register set does match. Maybe it's a bit more subtle than this
> > > patch description suggests?
> > >
> > > > just add the correct bindings and the appropriate LUX table derived from
> > > > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> > > >
> > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > ---
> > > > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > > > 1 file changed, 16 insertions(+)
> > > >
> > > > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > > > index c8f15ba95267..8dab34bf00ca 100644
> > > > --- a/drivers/iio/light/tsl2772.c
> > > > +++ b/drivers/iio/light/tsl2772.c
> > > > @@ -127,6 +127,7 @@ enum {
> > > > tmd2672,
> > > > tsl2772,
> > > > tmd2772,
> > > > + apds990x,
> > > > apds9930,
> > > > };
> > > >
> > > > @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > > { 0, 0 },
> > > > };
> > > >
> > > > +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > > + { 52000, 115960 },
> > > > + { 36400, 73840 },
> > > > + { 0, 0 },
> > > > +};
> > > > +
> > > > static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > > { 52000, 96824 },
> > > > { 38792, 67132 },
> > > > @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > > > [tmd2672] = tmd2x72_lux_table,
> > > > [tsl2772] = tsl2x72_lux_table,
> > > > [tmd2772] = tmd2x72_lux_table,
> > > > + [apds990x] = apds990x_lux_table,
> > > > [apds9930] = apds9930_lux_table,
> > > > };
> > > >
> > > > @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > > > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> > > > [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > };
> > > >
> > > > @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> > > > [tmd2672] = PRX2,
> > > > [tsl2772] = ALSPRX2,
> > > > [tmd2772] = ALSPRX2,
> > > > + [apds990x] = ALSPRX,
> > >
> > > This is different from tsl2772?
> >
> > yes, lux table is different and made according to datasheet,
> > tsl2772_int_time_avail differs, ALSPRX configuration assumes that
> > proximity sensor needs no calibration which is true for apds9900/1
> > while tsl2772 needs calibration, device ID is different 0x20/0x29 for
> > apds and 0x30 for tsl2772
>
> All makes sense but that means the patch description needs to be
> more precise about what elements are compatible, or use vaguer wording
> like 'similar to'.
>
Fair, noted.
> Jonathan
>
> >
> > >
> > > > [apds9930] = ALSPRX2,
> > > > };
> > >
> >
>
^ permalink raw reply
* Re: [PATCH v8 2/2] iio: dac: ad5706r: Add support for AD5706R DAC
From: Jonathan Cameron @ 2026-04-19 16:41 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, Alexis Czezar Torreno, Lars-Peter Clausen,
Michael Hennerich, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-iio,
devicetree, linux-kernel
In-Reply-To: <aeJ2clUsHk-VTr0F@ashevche-desk.local>
On Fri, 17 Apr 2026 21:05:38 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Fri, Apr 17, 2026 at 01:56:24PM +0100, Jonathan Cameron wrote:
> > On Fri, 17 Apr 2026 11:35:12 +0300
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > > On Fri, Apr 17, 2026 at 04:27:16PM +0800, Alexis Czezar Torreno wrote:
>
> ...
>
> > > > +#define AD5706R_DAC_RESOLUTION 16
> > > > +#define AD5706R_DAC_MAX_CODE GENMASK(15, 0)
> > >
> > > I know Jonathan asked for this, hence it's comment for him.
> > > I think that BIT() notation in a form of (BIT(16) - 1) is
> > > also appropriate here as it gives the relationship to the
> > > resolution of the given register / bitfield in HW.
> > >
> > > GENMASK() works for me, but it might require an additional
> > > operation to deduce the above.
> > >
> > > (Note, there is no request to change or resend for you, Alexis. It's just
> > > a remark to make Jonathan to think about which one suits better. He might
> > > change that whilst applying.)
> > >
> > I'm not against that form. It was more being against bare BIT(16) as that was
> > 1 greater than the maximum value it can take.
> > However making the relationship explicit would be even better.
> >
> > #define AD5705_DAC_MAX_CODE (BIT(AD5706R_DAC_RESOLUTION) - 1)
>
> While that's technically correct, I would still prefer an explicit number
With the resolution stated on the line above I'd slightly prefer the explicit coupling
that is lost with the number being repeated. Meh, I don't care that much.
>
> #define AD5705_DAC_MAX_CODE (BIT(16) - 1)
>
> Note, GENMASK() is also fine with me, this is really a minor difference.
>
> > I might tweak it when picking this up.
>
^ permalink raw reply
* Re: [PATCH v8 2/2] iio: dac: ad5706r: Add support for AD5706R DAC
From: Jonathan Cameron @ 2026-04-19 16:46 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-iio, devicetree, linux-kernel,
Andy Shevchenko
In-Reply-To: <20260417-dev_ad5706r-v8-2-ef87dff62b57@analog.com>
On Fri, 17 Apr 2026 16:27:16 +0800
Alexis Czezar Torreno <alexisczezar.torreno@analog.com> wrote:
> Add support for the Analog Devices AD5706R, a 4-channel 16-bit
> current output digital-to-analog converter with SPI interface.
>
> Features:
> - 4 independent DAC channels
> - Hardware and software LDAC trigger
> - Configurable output range
> - PWM-based LDAC control
> - Dither and toggle modes
> - Dynamically configurable SPI speed
https://sashiko.dev/#/patchset/20260417-dev_ad5706r-v8-0-ef87dff62b57%40analog.com
Sashiko correctly points out that the driver in v8 at least doesn't
do a bunch of things in this list. It's a bit odd to list device features
in a 1st driver patch if you haven't implemented them yet. So this
needs a rewrite to say what is implemented.
> MAINTAINERS | 1 +
> drivers/iio/dac/Kconfig | 11 ++
> drivers/iio/dac/Makefile | 1 +
> drivers/iio/dac/ad5706r.c | 253 ++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 266 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 17a3d2d45fccb9cd3c93fd35666fb85d17d53cde..3d7bd98b4d1b55836e40687a9a3ac9f4935a8acb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1502,6 +1502,7 @@ L: linux-iio@vger.kernel.org
> S: Supported
> W: https://ez.analog.com/linux-software-drivers
> F: Documentation/devicetree/bindings/iio/dac/adi,ad5706r.yaml
> +F: drivers/iio/dac/ad5706r.c
>
> ANALOG DEVICES INC AD7091R DRIVER
> M: Marcelo Schmitt <marcelo.schmitt@analog.com>
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index db9f5c711b3df90641f017652fbbef594cc1627d..a5a328818233e3d019cddaee369dd5b7b1529031 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -178,6 +178,17 @@ config AD5624R_SPI
> Say yes here to build support for Analog Devices AD5624R, AD5644R and
> AD5664R converters (DAC). This driver uses the common SPI interface.
>
> +config AD5706R
> + tristate "Analog Devices AD5706R DAC driver"
> + depends on SPI
> + select REGMAP_SPI
Another catch for Sashiko. REGMAP_SPI isn't used as this now uses a custom regmap
instead.
> + help
> + Say yes here to build support for Analog Devices AD5706R 4-channel,
> + 16-bit current output DAC.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ad5706r.
I think the other things it raised are either features still to come
(like turning on the power) or wrong. My understanding of the use of
buffers for SPI transfers is you can even use the same one for rx and tx
and it shouldn't be a problem. More than possible I'm wrong on that however! :(
Jonathan
^ permalink raw reply
* [PATCH 1/2] arm64: dts: qcom: sc8280xp: add several missing pdc map entries
From: Pengyu Luo @ 2026-04-19 17:32 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Pengyu Luo, linux-arm-msm, devicetree, linux-kernel
pdc 215, 256, 257 are missing, but we can find tlmm pin 103, 84, 90
are mapped to them respectively, so add the map entries from pdc to
gic. These entries are reversed from .data section of qcgpio.sys
Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
---
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index 8d526ffede36..fa1bd27aa16f 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -5365,7 +5365,7 @@ pdc: interrupt-controller@b220000 {
<211 699 1>,
<212 705 1>,
<213 450 1>,
- <214 643 1>,
+ <214 643 2>,
<216 646 5>,
<221 390 5>,
<226 700 3>,
@@ -5388,7 +5388,7 @@ pdc: interrupt-controller@b220000 {
<252 798 1>,
<253 765 1>,
<254 763 1>,
- <255 454 1>,
+ <255 454 3>,
<258 139 1>,
<259 786 2>,
<261 370 2>,
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: qcom: sc8280xp: gaokun3: correct EC interrupt pin
From: Pengyu Luo @ 2026-04-19 17:32 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Pengyu Luo, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260419173251.1180026-1-mitltlatltl@gmail.com>
Unlike other sc8280xp platforms, on this platform, in dsdt, gpio 0x2c0
is not mapped to gpio107, it is gpio103, so fix it. I found this until
I did a trigger track, irq is regularly triggerd every several
millisecs. In the past, since here gpio107 was low forever, ec irq
would keep to be triggered and polling the event every several
millisecs.
About how to get the map, please check openbsd driver for it
https://github.com/openbsd/src/blob/master/sys/dev/acpi/qcgpio.c
Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
---
arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts b/arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts
index 9819454abe13..d9d55241336e 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts
@@ -637,7 +637,7 @@ embedded-controller@38 {
compatible = "huawei,gaokun3-ec";
reg = <0x38>;
- interrupts-extended = <&tlmm 107 IRQ_TYPE_LEVEL_LOW>;
+ interrupts-extended = <&tlmm 103 IRQ_TYPE_LEVEL_LOW>;
#address-cells = <1>;
#size-cells = <0>;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/2] iio: adc: hx711: add HX710B support
From: Piyush Patle @ 2026-04-19 17:46 UTC (permalink / raw)
To: jic23, ak
Cc: dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt, linux-iio,
devicetree, linux-kernel
Add support for the HX710B ADC, a variant of the HX711 with the same
GPIO interface but a different channel and gain model.
The first patch updates the devicetree binding to add the
`avia,hx710b` compatible, document the variant-specific behavior, and
add chip-specific properties for supplies, the RATE pin, and an allOf
constraint for HX710B nodes.
The second patch refactors the driver with per-chip configuration,
pulse counts stored in chan->address, a dedicated fixed_gain flag, and
the differential channel descriptor for the HX710B input.
Tested on PocketBeagle2 with an HX710B breakout module. The device
probed successfully and raw readings were stable.
Changes in v2:
- See individual patch changelogs for full details.
- dt-bindings: add dvdd-supply, vsup-supply, rate-gpios; allOf if/then
for HX710B; fix clock-frequency description; remove dead vendor URL;
clarify vref not needed (AVDD serves as reference on both chips)
- driver: fix pulse count bug ({25,26}→{1,2}); move counts to
chan->address; add fixed_gain flag; add .differential/.channel2;
remove NULL check; drop reset_channel; pass iio_chan_spec * directly
Piyush Patle (2):
dt-bindings: iio: adc: avia-hx711: add avia,hx710b compatible
iio: adc: hx711: add support for HX710B
.../bindings/iio/adc/avia-hx711.yaml | 61 +++++-
drivers/iio/adc/Kconfig | 9 +-
drivers/iio/adc/hx711.c | 206 ++++++++++++++----
3 files changed, 225 insertions(+), 51 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: iio: adc: avia-hx711: add avia,hx710b compatible
From: Piyush Patle @ 2026-04-19 17:46 UTC (permalink / raw)
To: jic23, ak
Cc: dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260419174654.683692-1-piyushpatle228@gmail.com>
The HX710B shares the same two-wire interface as the HX711 but differs
in its channel and gain model: gain is fixed at 128 and the number of
trailing PD_SCK pulses selects the input channel rather than the gain.
Add avia,hx710b to the compatible enum. Document the chip differences
in the description and add chip-specific supply properties (dvdd-supply,
vsup-supply) for the HX711, a rate-gpios property for the HX711 RATE
pin, and an allOf constraint that forbids HX711-only properties on
HX710B nodes. Clarify the clock-frequency description to reflect its
actual purpose: controlling the SCK bit-bang timing. Note that AVDD
serves as the voltage reference on both chips so no separate
vref-supply is needed.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
---
Changes in v2:
- Remove driver implementation details (bit-banging, channel-selection
mechanics) from the description; describe hardware behaviour only
- Drop unrelated punctuation cleanup (trailing period on PD_SCK description)
- Add dvdd-supply and vsup-supply optional properties for HX711
- Add rate-gpios optional property for the HX711 RATE pin; forbid it on
HX710B via the allOf if/then block
- Add note to avdd-supply clarifying it serves as voltage reference on
both chips (no separate vref-supply needed)
- Add allOf if/then block forbidding HX711-only properties on HX710B
- Fix clock-frequency description to reflect its true purpose (SCK
bit-bang timing control, not a crystal/external clock frequency)
- Sort compatible enum alphabetically (hx710b before hx711)
- Remove redundant example comments (compatible already identifies part)
- Update HX711 example to exercise the new rate-gpios property
.../bindings/iio/adc/avia-hx711.yaml | 61 ++++++++++++++++---
1 file changed, 51 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
index 9c57eb13f892..35ac74a490b1 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
@@ -4,24 +4,24 @@
$id: http://devicetree.org/schemas/iio/adc/avia-hx711.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: AVIA HX711 ADC chip for weight cells
+title: AVIA HX711 and HX710B ADCs
maintainers:
- Andreas Klinger <ak@it-klinger.de>
description: |
- Bit-banging driver using two GPIOs:
- - sck-gpio gives a clock to the sensor with 24 cycles for data retrieval
- and up to 3 cycles for selection of the input channel and gain for the
- next measurement
- - dout-gpio is the sensor data the sensor responds to the clock
+ The HX711 is a 24-bit ADC with selectable gain (32/64/128) and two
+ differential input channels. Channel A supports gain 64 and 128;
+ channel B supports gain 32.
- Specifications about the driver can be found at:
- http://www.aviaic.com/ENProducts.aspx
+ The HX710B is a 24-bit ADC with fixed gain of 128. Channel 0 is the
+ differential input and channel 1 measures the DVDD-AVDD supply
+ voltage difference.
properties:
compatible:
enum:
+ - avia,hx710b
- avia,hx711
sck-gpios:
@@ -40,13 +40,45 @@ properties:
avdd-supply:
description:
- Definition of the regulator used as analog supply
+ Analog supply voltage (AVDD). Also serves as the voltage reference on
+ both chips; no separate vref-supply is required.
+
+ dvdd-supply:
+ description:
+ Digital supply voltage (DVDD). HX711 only.
+
+ vsup-supply:
+ description:
+ Supply voltage for the on-chip regulator (VSUP). HX711 only.
+
+ rate-gpios:
+ description:
+ GPIO connected to the RATE pin (HX711 only). When driven low the
+ output data rate is 10 SPS; when driven high it is 80 SPS. If
+ omitted the RATE pin state is determined by the board wiring.
+ maxItems: 1
clock-frequency:
+ description:
+ Controls the SCK bit-bang timing. The value is used to derive the
+ delay between SCK edges; keep the SCK high time below 60 us to
+ avoid triggering chip power-down mode. Defaults to 400 kHz if not
+ specified.
minimum: 20000
maximum: 2500000
default: 400000
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: avia,hx710b
+ then:
+ properties:
+ vsup-supply: false
+ dvdd-supply: false
+ rate-gpios: false
+
required:
- compatible
- sck-gpios
@@ -58,10 +90,19 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- weight {
+ weight0 {
compatible = "avia,hx711";
sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
+ rate-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
avdd-supply = <&avdd>;
clock-frequency = <100000>;
};
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ weight1 {
+ compatible = "avia,hx710b";
+ sck-gpios = <&gpio3 11 GPIO_ACTIVE_HIGH>;
+ dout-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
+ avdd-supply = <&avdd>;
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/2] iio: adc: hx711: add support for HX710B
From: Piyush Patle @ 2026-04-19 17:46 UTC (permalink / raw)
To: jic23, ak
Cc: dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260419174654.683692-1-piyushpatle228@gmail.com>
The HX711 uses trailing SCK pulses after each 24-bit conversion to
select the channel and gain for the next measurement: 1 pulse gives
channel A at gain 128, 2 pulses give channel B at gain 32, and 3 pulses
give channel A at gain 64.
The HX710B works differently: gain is fixed at 128 and the trailing
pulses select only the channel. One trailing pulse selects the
differential input (channel 0, 10 SPS) and two trailing pulses select
the DVDD-AVDD supply monitor (channel 1, 40 SPS).
Refactor the driver around a per-chip hx711_chip_info structure so both
variants can share the same core. Each chip provides its own
iio_chan_spec array and iio_info pointer. The HX710B stores per-channel
trailing pulse counts in chan->address (1 for channel 0, 2 for
channel 1) instead of a separate array. A bool fixed_gain flag and
fixed_gain_val field in hx711_chip_info distinguish the fixed-gain path
from the HX711's user-selectable gain path without conflating unrelated
properties. The HX710B differential input channel is described with
.differential=1 and .channel2=1 as required by the IIO ABI.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
---
Changes in v2:
- Fix pulse count bug: hx710b values were {25, 26} (total SCK cycles);
corrected to {1, 2} (trailing-only, hx711_read() clocks 24 data bits)
- Add .differential = 1 and .channel2 = 1 to HX710B channel 0
- Move trailing pulse counts from a separate array to chan->address
(1 for ch0, 2 for ch1); remove chan_pulse_count / num_chan_pulses
- Replace chan_pulse_count != NULL tests with dedicated bool fixed_gain
flag; add fixed_gain_val field to hx711_chip_info
- Add const struct iio_info *iio_info to hx711_chip_info; probe sets
indio_dev->info = chip_info->iio_info directly
- Remove NULL check after device_get_match_data()
- Remove reset_channel from hx711_chip_info (always 0; use literal)
- Change hx711_reset_read() and hx710b_set_channel() to take
const struct iio_chan_spec * instead of int chan
- Revert hx711_data struct member alignment noise
- Restore trailing blank line at end of file (unrelated removal reverted)
- Sort of_device_id entries alphabetically (hx710b before hx711)
- Expand commit message to explain HX711 vs HX710B trailing-pulse model
- Restore file header to mention weight sensor modules
drivers/iio/adc/Kconfig | 9 +-
drivers/iio/adc/hx711.c | 206 ++++++++++++++++++++++++++++++++--------
2 files changed, 174 insertions(+), 41 deletions(-)
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 60038ae8dfc4..ddf981fa72a2 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -784,18 +784,21 @@ config HI8435
called hi8435.
config HX711
- tristate "AVIA HX711 ADC for weight cells"
+ tristate "AVIA HX711 and HX710B ADC"
depends on GPIOLIB
select IIO_BUFFER
select IIO_TRIGGERED_BUFFER
help
- If you say yes here you get support for AVIA HX711 ADC which is used
- for weigh cells
+ If you say yes here you get support for AVIA HX711 and HX710B ADCs
+ which are used for bridge sensors such as weigh cells.
This driver uses two GPIOs, one acts as the clock and controls the
channel selection and gain, the other one is used for the measurement
data
+ The HX710B is a variant with fixed gain and a different channel
+ selection scheme.
+
Currently the raw value is read from the chip and delivered.
To get an actual weight one needs to subtract the
zero offset and multiply by a scale factor.
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 1db8b68a8f64..b024fb341b2e 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * HX711: analog to digital converter for weight sensor module
+ * HX711/HX710B: ADC driver for weight sensor modules
*
* Copyright (c) 2016 Andreas Klinger <ak@it-klinger.de>
*/
@@ -76,12 +76,33 @@ static int hx711_get_scale_to_gain(int scale)
return -EINVAL;
}
+/**
+ * struct hx711_chip_info - per-variant static configuration
+ * @name: IIO device name
+ * @channels: channel specification
+ * @num_channels: number of channels
+ * @iio_info: IIO info ops for this variant
+ * @fixed_gain: true if the variant has a fixed ADC gain (e.g. HX710B)
+ * @fixed_gain_val: the fixed gain value used to compute scale (when fixed_gain)
+ */
+struct hx711_chip_info {
+ const char *name;
+ const struct iio_chan_spec *channels;
+ int num_channels;
+ const struct iio_info *iio_info;
+ bool fixed_gain;
+ int fixed_gain_val;
+};
+
struct hx711_data {
struct device *dev;
struct gpio_desc *gpiod_pd_sck;
struct gpio_desc *gpiod_dout;
int gain_set; /* gain set on device */
int gain_chan_a; /* gain for channel A */
+ int channel_set; /* HX710B current channel */
+ int scale; /* HX710B fixed scale */
+ const struct hx711_chip_info *chip_info;
struct mutex lock;
/*
* triggered buffer
@@ -92,10 +113,7 @@ struct hx711_data {
aligned_s64 timestamp;
} buffer;
/*
- * delay after a rising edge on SCK until the data is ready DOUT
- * this is dependent on the hx711 where the datasheet tells a
- * maximum value of 100 ns
- * but also on potential parasitic capacities on the wiring
+ * Delay after SCK rising edge before sampling DOUT.
*/
u32 data_ready_delay_ns;
u32 clock_frequency;
@@ -139,7 +157,11 @@ static int hx711_cycle(struct hx711_data *hx711_data)
return gpiod_get_value(hx711_data->gpiod_dout);
}
-static int hx711_read(struct hx711_data *hx711_data)
+/*
+ * Clock out 24 data bits and then send trailing pulses to select the
+ * next channel/gain state.
+ */
+static int hx711_read(struct hx711_data *hx711_data, int trailing_pulses)
{
int i, ret;
int value = 0;
@@ -158,7 +180,7 @@ static int hx711_read(struct hx711_data *hx711_data)
value ^= 0x800000;
- for (i = 0; i < hx711_get_gain_to_pulse(hx711_data->gain_set); i++)
+ for (i = 0; i < trailing_pulses; i++)
hx711_cycle(hx711_data);
return value;
@@ -188,6 +210,7 @@ static int hx711_wait_for_ready(struct hx711_data *hx711_data)
static int hx711_reset(struct hx711_data *hx711_data)
{
+ const struct hx711_chip_info *info = hx711_data->chip_info;
int val = hx711_wait_for_ready(hx711_data);
if (val) {
@@ -206,13 +229,17 @@ static int hx711_reset(struct hx711_data *hx711_data)
val = hx711_wait_for_ready(hx711_data);
- /* after a reset the gain is 128 */
- hx711_data->gain_set = HX711_RESET_GAIN;
+ /* Restore variant default after reset. */
+ if (info->fixed_gain)
+ hx711_data->channel_set = 0;
+ else
+ hx711_data->gain_set = HX711_RESET_GAIN;
}
return val;
}
+/* Select HX711 channel/gain for the next conversion. */
static int hx711_set_gain_for_channel(struct hx711_data *hx711_data, int chan)
{
int ret;
@@ -221,7 +248,8 @@ static int hx711_set_gain_for_channel(struct hx711_data *hx711_data, int chan)
if (hx711_data->gain_set == 32) {
hx711_data->gain_set = hx711_data->gain_chan_a;
- ret = hx711_read(hx711_data);
+ ret = hx711_read(hx711_data,
+ hx711_get_gain_to_pulse(hx711_data->gain_set));
if (ret < 0)
return ret;
@@ -233,7 +261,8 @@ static int hx711_set_gain_for_channel(struct hx711_data *hx711_data, int chan)
if (hx711_data->gain_set != 32) {
hx711_data->gain_set = 32;
- ret = hx711_read(hx711_data);
+ ret = hx711_read(hx711_data,
+ hx711_get_gain_to_pulse(hx711_data->gain_set));
if (ret < 0)
return ret;
@@ -246,27 +275,50 @@ static int hx711_set_gain_for_channel(struct hx711_data *hx711_data, int chan)
return 0;
}
-static int hx711_reset_read(struct hx711_data *hx711_data, int chan)
+/* Select HX710B channel for the next conversion. */
+static int hx710b_set_channel(struct hx711_data *hx711_data,
+ const struct iio_chan_spec *chan)
{
int ret;
- int val;
- /*
- * hx711_reset() must be called from here
- * because it could be calling hx711_read() by itself
- */
+ if (hx711_data->channel_set == chan->channel)
+ return 0;
+
+ hx711_data->channel_set = chan->channel;
+
+ ret = hx711_read(hx711_data, chan->address);
+ if (ret < 0)
+ return ret;
+
+ return hx711_wait_for_ready(hx711_data);
+}
+
+static int hx711_reset_read(struct hx711_data *hx711_data,
+ const struct iio_chan_spec *chan)
+{
+ const struct hx711_chip_info *info = hx711_data->chip_info;
+ int trailing_pulses;
+ int ret;
+
+ /* Reset first so the read starts from a known chip state. */
if (hx711_reset(hx711_data)) {
dev_err(hx711_data->dev, "reset failed!");
return -EIO;
}
- ret = hx711_set_gain_for_channel(hx711_data, chan);
- if (ret < 0)
- return ret;
-
- val = hx711_read(hx711_data);
+ if (info->fixed_gain) {
+ ret = hx710b_set_channel(hx711_data, chan);
+ if (ret < 0)
+ return ret;
+ trailing_pulses = chan->address;
+ } else {
+ ret = hx711_set_gain_for_channel(hx711_data, chan->channel);
+ if (ret < 0)
+ return ret;
+ trailing_pulses = hx711_get_gain_to_pulse(hx711_data->gain_set);
+ }
- return val;
+ return hx711_read(hx711_data, trailing_pulses);
}
static int hx711_read_raw(struct iio_dev *indio_dev,
@@ -274,12 +326,13 @@ static int hx711_read_raw(struct iio_dev *indio_dev,
int *val, int *val2, long mask)
{
struct hx711_data *hx711_data = iio_priv(indio_dev);
+ const struct hx711_chip_info *info = hx711_data->chip_info;
switch (mask) {
case IIO_CHAN_INFO_RAW:
mutex_lock(&hx711_data->lock);
- *val = hx711_reset_read(hx711_data, chan->channel);
+ *val = hx711_reset_read(hx711_data, chan);
mutex_unlock(&hx711_data->lock);
@@ -290,7 +343,10 @@ static int hx711_read_raw(struct iio_dev *indio_dev,
*val = 0;
mutex_lock(&hx711_data->lock);
- *val2 = hx711_get_gain_to_scale(hx711_data->gain_set);
+ if (info->fixed_gain)
+ *val2 = hx711_data->scale;
+ else
+ *val2 = hx711_get_gain_to_scale(hx711_data->gain_set);
mutex_unlock(&hx711_data->lock);
@@ -332,7 +388,8 @@ static int hx711_write_raw(struct iio_dev *indio_dev,
if (gain != 32)
hx711_data->gain_chan_a = gain;
- ret = hx711_read(hx711_data);
+ ret = hx711_read(hx711_data,
+ hx711_get_gain_to_pulse(hx711_data->gain_set));
if (ret < 0) {
mutex_unlock(&hx711_data->lock);
return ret;
@@ -368,7 +425,7 @@ static irqreturn_t hx711_trigger(int irq, void *p)
iio_for_each_active_channel(indio_dev, i) {
hx711_data->buffer.channel[j] = hx711_reset_read(hx711_data,
- indio_dev->channels[i].channel);
+ &indio_dev->channels[i]);
j++;
}
@@ -423,6 +480,10 @@ static const struct iio_info hx711_iio_info = {
.attrs = &hx711_attribute_group,
};
+static const struct iio_info hx710b_iio_info = {
+ .read_raw = hx711_read_raw,
+};
+
static const struct iio_chan_spec hx711_chan_spec[] = {
{
.type = IIO_VOLTAGE,
@@ -455,10 +516,69 @@ static const struct iio_chan_spec hx711_chan_spec[] = {
IIO_CHAN_SOFT_TIMESTAMP(2),
};
+/*
+ * HX710B channels.
+ * Channel 0: differential input (IN+ vs IN-), 10 SPS, 1 trailing pulse.
+ * Channel 1: DVDD-AVDD supply monitor, 40 SPS, 2 trailing pulses.
+ * .address holds the trailing pulse count used by hx710b_set_channel().
+ */
+static const struct iio_chan_spec hx710b_chan_spec[] = {
+ {
+ .type = IIO_VOLTAGE,
+ .differential = 1,
+ .channel = 0,
+ .channel2 = 1,
+ .indexed = 1,
+ .address = 1,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ .scan_index = 0,
+ .scan_type = {
+ .sign = 'u',
+ .realbits = 24,
+ .storagebits = 32,
+ .endianness = IIO_CPU,
+ },
+ },
+ {
+ .type = IIO_VOLTAGE,
+ .channel = 1,
+ .indexed = 1,
+ .address = 2,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ .scan_index = 1,
+ .scan_type = {
+ .sign = 'u',
+ .realbits = 24,
+ .storagebits = 32,
+ .endianness = IIO_CPU,
+ },
+ },
+ IIO_CHAN_SOFT_TIMESTAMP(2),
+};
+
+static const struct hx711_chip_info hx711_chip = {
+ .name = "hx711",
+ .channels = hx711_chan_spec,
+ .num_channels = ARRAY_SIZE(hx711_chan_spec),
+ .iio_info = &hx711_iio_info,
+};
+
+static const struct hx711_chip_info hx710b_chip = {
+ .name = "hx710b",
+ .channels = hx710b_chan_spec,
+ .num_channels = ARRAY_SIZE(hx710b_chan_spec),
+ .iio_info = &hx710b_iio_info,
+ .fixed_gain = true,
+ .fixed_gain_val = 128,
+};
+
static int hx711_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct hx711_data *hx711_data;
+ const struct hx711_chip_info *chip_info;
struct iio_dev *indio_dev;
int ret;
int i;
@@ -472,6 +592,9 @@ static int hx711_probe(struct platform_device *pdev)
mutex_init(&hx711_data->lock);
+ chip_info = device_get_match_data(dev);
+ hx711_data->chip_info = chip_info;
+
/*
* PD_SCK stands for power down and serial clock input of HX711
* in the driver it is an output
@@ -510,12 +633,19 @@ static int hx711_probe(struct platform_device *pdev)
/* we need 10^-9 mV */
ret *= 100;
- for (i = 0; i < HX711_GAIN_MAX; i++)
- hx711_gain_to_scale[i].scale =
- ret / hx711_gain_to_scale[i].gain / 1678;
+ if (chip_info->fixed_gain) {
+ /* Fixed-gain variant: compute scale once at probe. */
+ hx711_data->scale = ret / chip_info->fixed_gain_val / 1678;
+ } else {
+ for (i = 0; i < HX711_GAIN_MAX; i++)
+ hx711_gain_to_scale[i].scale =
+ ret / hx711_gain_to_scale[i].gain / 1678;
+
+ hx711_data->gain_set = 128;
+ hx711_data->gain_chan_a = 128;
+ }
- hx711_data->gain_set = 128;
- hx711_data->gain_chan_a = 128;
+ indio_dev->info = chip_info->iio_info;
hx711_data->clock_frequency = 400000;
ret = device_property_read_u32(&pdev->dev, "clock-frequency",
@@ -533,11 +663,10 @@ static int hx711_probe(struct platform_device *pdev)
hx711_data->data_ready_delay_ns =
1000000000 / hx711_data->clock_frequency;
- indio_dev->name = "hx711";
- indio_dev->info = &hx711_iio_info;
+ indio_dev->name = chip_info->name;
indio_dev->modes = INDIO_DIRECT_MODE;
- indio_dev->channels = hx711_chan_spec;
- indio_dev->num_channels = ARRAY_SIZE(hx711_chan_spec);
+ indio_dev->channels = chip_info->channels;
+ indio_dev->num_channels = chip_info->num_channels;
ret = devm_iio_triggered_buffer_setup(dev, indio_dev,
iio_pollfunc_store_time,
@@ -554,7 +683,8 @@ static int hx711_probe(struct platform_device *pdev)
}
static const struct of_device_id of_hx711_match[] = {
- { .compatible = "avia,hx711", },
+ { .compatible = "avia,hx710b", .data = &hx710b_chip },
+ { .compatible = "avia,hx711", .data = &hx711_chip },
{ }
};
@@ -571,7 +701,7 @@ static struct platform_driver hx711_driver = {
module_platform_driver(hx711_driver);
MODULE_AUTHOR("Andreas Klinger <ak@it-klinger.de>");
-MODULE_DESCRIPTION("HX711 bitbanging driver - ADC for weight cells");
+MODULE_DESCRIPTION("HX711/HX710B GPIO ADC driver");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:hx711-gpio");
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: amlogic: add support for Amedia X98Q
From: Christian Stefan Köver-Draxl @ 2026-04-19 17:59 UTC (permalink / raw)
To: Ferass El Hafidi, linux-amlogic, neil.armstrong, khilman
Cc: devicetree, linux-arm-kernel
In-Reply-To: <tdqzjg.e0dtukngm56y@postmarketos.org>
On 4/19/26 17:19, Ferass El Hafidi wrote:
> Hi, some drive-by feedback
>
> On Sun, 19 Apr 2026 15:08, christian.koever-draxl@student.uibk.ac.at
> wrote:
>> From: Christian Stefan Kövér-Draxl
>> <christian.koever-draxl@student.uibk.ac.at>
>>
>> The X98Q is a TV box based on the Amlogic S4 (S905W2) SoC.
>> Add the device tree for this board and document the compatible string.
>>
>> Supported features:
>> - 1GB/2GB RAM (via U-Boot memory fixup)
>> - 10/100 Ethernet (Internal PHY)
>> - eMMC and SD card storage
>> - PWM-based CPU voltage regulation
>> - UART (Serial console)
>>
>> Signed-off-by: Christian Stefan Kövér-Draxl
>> <christian.koever-draxl@student.uibk.ac.at>
>> ---
>> - The Wi-Fi chip on this board is Amlogic W150S1. I have left the
>> SDIO node enabled
>> but omitted the specific chip sub-node due to lack of mainline
>> drivers (yet).
>> - The console uses uart_b at 921600 baud.
>> - Verified memory via /proc/device-tree; U-Boot patches the node to
>> around 2GB if board supports more than 1GB.
>> - Tested on the 2GB RAM plus 16GB EMMC variant.
>>
>> .../devicetree/bindings/arm/amlogic.yaml | 7 +
>> arch/arm64/boot/dts/amlogic/Makefile | 1 +
>> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 244 ++++++++++++++++++
>> 3 files changed, 252 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>>
>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml
>> b/Documentation/devicetree/bindings/arm/amlogic.yaml
>> index a885278bc4e2..82671d58d1da 100644
>> --- a/Documentation/devicetree/bindings/arm/amlogic.yaml
>> +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
>> @@ -254,6 +254,13 @@ properties:
>> - khadas,vim1s
>> - const: amlogic,s905y4
>> - const: amlogic,s4
>> + + - description: Boards with the Amlogic Meson S4 S905W2 SoC
>> + items:
>> + - enum:
>> + - amediatech,x98q
>> + - const: amlogic,s905w2
>> + - const: amlogic,s4
>>
>> - description: Boards with the Amlogic S6 S905X5 SoC
>> items:
>
> It is better to send the dt-binding changes separate from the actual
> DTS. The golden rule is one commit per change.
>
> You can (and should) send both patches as part of a patch series.
Thanks for the Review! I have split this for v2.
>
>> diff --git a/arch/arm64/boot/dts/amlogic/Makefile
>> b/arch/arm64/boot/dts/amlogic/Makefile
>> index 15f9c817e502..6f0bdd5bdca2 100644
>> --- a/arch/arm64/boot/dts/amlogic/Makefile
>> +++ b/arch/arm64/boot/dts/amlogic/Makefile
>> @@ -86,6 +86,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
>> dtb-$(CONFIG_ARCH_MESON) += meson-s4-s805x2-aq222.dtb
>> dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905y4-khadas-vim1s.dtb
>> +dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905w2-x98q.dtb
>
> Keep this file in alphabetic order.
Thanks, i have fixed it!
>
>> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air-gbit.dtb
>> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air.dtb
>> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m2-pro.dtb
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>> b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>> new file mode 100644
>> index 000000000000..f2db01730a3d
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>> @@ -0,0 +1,244 @@
>> +
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (c) 2026 Christian Stefan Köver-Draxl
>> + */
>
> Did you base this DTS on another DTS that is already upstream? This
> looks a lot like
> https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts?h=v7.1/arm64-dt
>
>
> If so, then you should keep their copyright. Something like:
>
> /*
> * Copyright (c) 2026 Christian Stefan Köver-Draxl
> * Based on <...>:
> * - Copyright (c) <authors of the DTB this one is based on>
> */
>
> Correct me if I'm wrong.
Yes, I used the VIM1S as a base. I will update the copyright header to
include the original authors.
>
>> +
>> +/dts-v1/;
>> +
>> +#include "meson-s4.dtsi"
>> +
>> +/ {
>> + model = "Shenzhen Amedia X98Q";
>
> Shouldn't this be
> model = "Shenzhen Amediatech Technology Co., Ltd X98Q";
> ?
>
> There are other Amediatech boards supported currently:
>
> dts/amlogic/meson-g12a-x96-max.dts: model = "Shenzhen Amediatech
> Technology Co., Ltd X96 Max";
> dts/amlogic/meson-sm1-x96-air-gbit.dts: model = "Shenzhen Amediatech
> Technology Co., Ltd X96 Air";
> dts/amlogic/meson-sm1-x96-air.dts: model = "Shenzhen Amediatech
> Technology Co., Ltd X96 Air";
>
> I think it might be preferable to use a similar model format for
> consistency.
>
> It is also the documented vendor prefix for amediatech. (see
> Documentation/devicetree/bindings/vendor-prefixes.yaml)
I have updated the vendor prefix accordingly.
>
>> + compatible = "amediatech,x98q", "amlogic,s905w2", "amlogic,s4";
>> + interrupt-parent = <&gic>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + aliases {
>> + mmc0 = &emmc; /* eMMC */
>> + mmc1 = &sd; /* SD card */
>> + mmc2 = &sdio; /* SDIO */
>> + serial0 = &uart_b;
>> + };
>> +
>> + memory@0 {
>> + device_type = "memory";
>> + reg = <0x0 0x0 0x0 0x40000000>;
>> + };
>> +
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + /* 52 MiB reserved for ARM Trusted Firmware */
>> + secmon_reserved: secmon@5000000 {
>> + reg = <0x0 0x05000000 0x0 0x3400000>;
>> + no-map;
>> + };
>> + };
>> +
>> + emmc_pwrseq: emmc-pwrseq {
>> + compatible = "mmc-pwrseq-emmc";
>> + reset-gpios = <&gpio GPIOB_9 GPIO_ACTIVE_LOW>;
>> + };
>> +
>> + sdio_32k: sdio-32k {
>> + compatible = "pwm-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <32768>;
>> + pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
>> + };
>> +
>> + sdio_pwrseq: sdio-pwrseq {
>> + compatible = "mmc-pwrseq-simple";
>> + reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
>> + clocks = <&sdio_32k>;
>> + clock-names = "ext_clock";
>> + };
>> +
>> + main_5v: regulator-main-5v {
>> + compatible = "regulator-fixed";
>> + regulator-name = "5V";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + regulator-always-on;
>> + };
>> +
>> + sd_3v3: regulator-sd-3v3 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "SD_3V3";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + gpio = <&gpio GPIOD_4 GPIO_ACTIVE_LOW>;
>> + regulator-always-on;
>> + };
>> +
>> + vddio_sd: regulator-vddio-sd {
>> + compatible = "regulator-gpio";
>> + regulator-name = "VDDIO_SD";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <3300000>;
>> + gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
>> + gpios-states = <1>;
>> + states = <1800000 1
>> + 3300000 0>;
>
> nit: keep this in one line.
Done for v2!
BTW: I applied this part from the VIM1S. So maybe that dts needs to be
adjusted too in the future.
>
>> + };
>> +
>> + vddao_3v3: regulator-vddao-3v3 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "VDDAO_3V3";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + vin-supply = <&main_5v>;
>> + regulator-always-on;
>> + };
>> +
>> + vddio_ao1v8: regulator-vddio-ao1v8 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "VDDIO_AO1V8";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + vin-supply = <&vddao_3v3>;
>> + regulator-always-on;
>> + };
>> +
>> + /* SY8120B1ABC DC/DC Regulator. */
>> + vddcpu: regulator-vddcpu {
>> + compatible = "pwm-regulator";
>> +
>> + regulator-name = "VDDCPU";
>> + regulator-min-microvolt = <689000>;
>> + regulator-max-microvolt = <1049000>;
>> +
>> + vin-supply = <&main_5v>;
>> +
>> + pwms = <&pwm_ij 1 1500 0>;
>> + pwm-dutycycle-range = <100 0>;
>> +
>> + regulator-boot-on;
>> + regulator-always-on;
>> + /* Voltage Duty-Cycle */
>> + voltage-table = <1049000 0>,
>> + <1039000 3>,
>> + <1029000 6>,
>> + <1019000 9>,
>> + <1009000 12>,
>> + <999000 14>,
>> + <989000 17>,
>> + <979000 20>,
>> + <969000 23>,
>> + <959000 26>,
>> + <949000 29>,
>> + <939000 31>,
>> + <929000 34>,
>> + <919000 37>,
>> + <909000 40>,
>> + <899000 43>,
>> + <889000 45>,
>> + <879000 48>,
>> + <869000 51>,
>> + <859000 54>,
>> + <849000 56>,
>> + <839000 59>,
>> + <829000 62>,
>> + <819000 65>,
>> + <809000 68>,
>> + <799000 70>,
>> + <789000 73>,
>> + <779000 76>,
>> + <769000 79>,
>> + <759000 81>,
>> + <749000 84>,
>> + <739000 87>,
>> + <729000 89>,
>> + <719000 92>,
>> + <709000 95>,
>> + <699000 98>,
>> + <689000 100>;
>> + };
>> +};
>> +
>> +&emmc {
>> + status = "okay";
>> + pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
>> + pinctrl-1 = <&emmc_clk_gate_pins>;
>> + pinctrl-names = "default", "clk-gate";
>> +
>> + bus-width = <8>;
>> + cap-mmc-highspeed;
>> + mmc-ddr-1_8v;
>> + mmc-hs200-1_8v;
>> + max-frequency = <200000000>;
>> + non-removable;
>> + disable-wp;
>> +
>> + mmc-pwrseq = <&emmc_pwrseq>;
>> + vmmc-supply = <&vddao_3v3>;
>> + vqmmc-supply = <&vddio_ao1v8>;
>> +};
>> +
>> +ðmac {
>> + status = "okay";
>> + phy-handle = <&internal_ephy>;
>> + phy-mode = "rmii";
>> +};
>> +
>> +&ir {
>> + status = "okay";
>> + pinctrl-0 = <&remote_pins>;
>> + pinctrl-names = "default";
>> +};
>> +
>> +&pwm_ef {
>> + status = "okay";
>> + pinctrl-0 = <&pwm_e_pins1>;
>> + pinctrl-names = "default";
>> +};
>> +
>> +&pwm_ij {
>> + status = "okay";
>> +};
>> +
>> +&sd {
>> + status = "okay";
>> + pinctrl-0 = <&sdcard_pins>;
>> + pinctrl-1 = <&sdcard_clk_gate_pins>;
>> + pinctrl-names = "default", "clk-gate";
>> + bus-width = <4>;
>> + cap-sd-highspeed;
>> + max-frequency = <50000000>;
>> + disable-wp;
>> +
>> + cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
>> +
>> + vmmc-supply = <&vddao_3v3>;
>> + vqmmc-supply = <&vddao_3v3>;
>> +};
>> +
>> +&sdio {
>> + status = "okay";
>> + pinctrl-0 = <&sdio_pins>;
>> + pinctrl-1 = <&sdio_clk_gate_pins>;
>> + pinctrl-names = "default", "clk-gate";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + bus-width = <4>;
>> + cap-sd-highspeed;
>> + sd-uhs-sdr50;
>> + sd-uhs-sdr104;
>> + max-frequency = <200000000>;
>> + non-removable;
>> + disable-wp;
>> +
>> + no-sd;
>> + no-mmc;
>> + mmc-pwrseq = <&sdio_pwrseq>;
>> + vmmc-supply = <&vddao_3v3>;
>> + vqmmc-supply = <&vddio_ao1v8>;
>> +};
>
> I suppose that's the Wi-Fi module you're talking about. I would put a
> comment
> above to specify that it is indeed Wi-Fi and not yet supported.
>
> Something like:
>
> /*
> * Wireless SDIO Module (Amlogic W150S1)
> * Note: There is no driver for this at the moment.
> */
>
Yes that makes sense. I will add that.
>> +
>> +&uart_b {
>> + status = "okay";
>> +};
>> --
>> 2.53.0
>
> --
> Best regards,
> Ferass
Thanks again,
Christian
^ permalink raw reply
* [PATCH v1 14/14] dt-bindings: thermal: cooling-devices: Update support for 3 cells cooling device
From: Daniel Lezcano @ 2026-04-19 18:21 UTC (permalink / raw)
To: rafael
Cc: gaurav.kohli, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lucas Stach, Russell King,
Christian Gmeiner, David Airlie, Simona Vetter, Guenter Roeck,
Joel Stanley, Andrew Jeffery, Thomas Weißschuh, Benson Leung,
Pali Rohár, Avi Fishman, Tomer Maimon, Tali Perry,
Patrick Venture, Nancy Yuen, Benjamin Fair, Heiko Stuebner,
Thierry Reding, Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Amit Daniel Kachhap, Viresh Kumar, Neil Armstrong, Amit Kucheria,
linux-pm, linux-kernel, linux-hwmon, Daniel Lezcano,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20260419182203.4083985-1-daniel.lezcano@oss.qualcomm.com>
From: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Extend the thermal cooling device binding to support a 3 cells specifier
along with tje 2 cells format.
Update #cooling-cells property to enum to support both 2 and 3 arguments.
Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
---
.../bindings/thermal/thermal-cooling-devices.yaml | 8 ++++++--
.../devicetree/bindings/thermal/thermal-zones.yaml | 3 ++-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml b/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
index b9022f1613d8..28f5818f1e60 100644
--- a/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
+++ b/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
@@ -44,10 +44,14 @@ select: true
properties:
"#cooling-cells":
description:
- Must be 2, in order to specify minimum and maximum cooling state used in
+ Must be 2 or 3. If 2, specifies minimum and maximum cooling state used in
the cooling-maps reference. The first cell is the minimum cooling state
and the second cell is the maximum cooling state requested.
- const: 2
+ If 3, the first cell specifies the thermal mitigation device specifier
+ index for devices that support multiple thermal mitigation mechanisms.
+ The two other cells are respectively the minimum cooling state and the
+ maximum cooling state.
+ enum: [2, 3]
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
index 0de0a9757ccc..1261ba0e802e 100644
--- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
+++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
@@ -214,7 +214,8 @@ patternProperties:
device. Using the THERMAL_NO_LIMIT (-1UL) constant in the
cooling-device phandle limit specifier lets the framework
use the minimum and maximum cooling state for that cooling
- device automatically.
+ device automatically. If three arguments are specified,
+ the first argument is the cooling device specifier.
contribution:
$ref: /schemas/types.yaml#/definitions/uint32
--
2.43.0
^ permalink raw reply related
* [PATCH 0/7] arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD SoC and Geist board
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
Add support for the Renesas R-Car M3Le (R8A779MD) SoC, a register-compatible
variant of the R8A77965 (M3-N) with reduced set of peripherals. Add support
for the Geist board based on the Renesas R-Car R8A779MD (M3Le).
The DU part does probe, and to the best of my knowledge, should correctly
describe the hardware, but is otherwise untested due to no remote display
access. Note that the DU uses ports 0 and 2, which is unusual.
VIN is also untested due to no remote hardware access.
Marek Vasut (5):
dt-bindings: display: renesas,du: Document Renesas R-Car R8A779MD M3Le
drm/rcar-du: Add support for Renesas R-Car R8A779MD M3Le
dt-bindings: clock: cs2000-cp: document CS2500
dt-bindings: soc: renesas: Document Renesas R-Car R8A779MD Geist
soc: renesas: Identify Renesas R-Car R8A779MD M3Le SoC
Nguyen Tran (2):
arm64: dts: renesas: r8a779md: Add Renesas R-Car R8A779MD M3Le DTs
arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD
Geist
.../bindings/clock/cirrus,cs2000-cp.yaml | 10 +-
.../bindings/display/renesas,du.yaml | 70 ++
.../bindings/soc/renesas/renesas.yaml | 6 +
arch/arm64/boot/dts/renesas/Makefile | 3 +
.../dts/renesas/geist-panel-aa104xd12.dtso | 17 +
.../arm64/boot/dts/renesas/r8a779md-geist.dts | 832 ++++++++++++++++++
arch/arm64/boot/dts/renesas/r8a779md.dtsi | 48 +
drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 25 +
drivers/soc/renesas/renesas-soc.c | 1 +
9 files changed, 1009 insertions(+), 3 deletions(-)
create mode 100644 arch/arm64/boot/dts/renesas/geist-panel-aa104xd12.dtso
create mode 100644 arch/arm64/boot/dts/renesas/r8a779md-geist.dts
create mode 100644 arch/arm64/boot/dts/renesas/r8a779md.dtsi
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
--
2.53.0
^ permalink raw reply
* [PATCH 1/7] dt-bindings: display: renesas,du: Document Renesas R-Car R8A779MD M3Le
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Extend the Renesas DU display bindings to support the Renesas R-Car
R8A779MD M3Le SoC. This SoC is similar to R-Car R8A77965 M3-N SoC,
except the HDMI port@1 is not present.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
.../bindings/display/renesas,du.yaml | 70 +++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml
index c27dfea7fc622..3c3667ff4a27f 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
@@ -42,6 +42,7 @@ properties:
- renesas,du-r8a779a0 # for R-Car V3U compatible DU
- renesas,du-r8a779g0 # for R-Car V4H compatible DU
- renesas,du-r8a779h0 # for R-Car V4M compatible DU
+ - renesas,du-r8a779md # for R-Car M3Le compatible DU
reg:
maxItems: 1
@@ -890,6 +891,75 @@ allOf:
- reset-names
- renesas,vsps
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,du-r8a779md
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ items:
+ - description: Functional clock for DU0
+ - description: Functional clock for DU1
+ - description: Functional clock for DU3
+ - description: DU_DOTCLKIN0 input clock
+ - description: DU_DOTCLKIN1 input clock
+ - description: DU_DOTCLKIN3 input clock
+
+ clock-names:
+ minItems: 3
+ items:
+ - const: du.0
+ - const: du.1
+ - const: du.3
+ - pattern: '^dclkin\.[013]$'
+ - pattern: '^dclkin\.[013]$'
+ - pattern: '^dclkin\.[013]$'
+
+ interrupts:
+ minItems: 3
+ maxItems: 3
+
+ resets:
+ minItems: 2
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: du.0
+ - const: du.3
+
+ ports:
+ properties:
+ port@0:
+ description: DPAD 0
+ port@1: false
+ port@2:
+ description: LVDS 0
+ port@3: false
+
+ required:
+ - port@0
+ - port@2
+
+ renesas,cmms:
+ minItems: 3
+ maxItems: 3
+
+ renesas,vsps:
+ minItems: 3
+ maxItems: 3
+
+ required:
+ - clock-names
+ - interrupts
+ - resets
+ - reset-names
+ - renesas,vsps
+
additionalProperties: false
examples:
--
2.53.0
^ permalink raw reply related
* [PATCH 2/7] drm/rcar-du: Add support for Renesas R-Car R8A779MD M3Le
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Add support the Renesas R-Car R8A779MD M3Le SoC. This SoC is
similar to R-Car R8A77965 M3-N SoC, except the HDMI port@1 is
not present.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
index 031d07f4508e9..be862b5524fd2 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
@@ -564,6 +564,30 @@ static const struct rcar_du_device_info rcar_du_r8a779h0_info = {
.dsi_clk_mask = BIT(0),
};
+static const struct rcar_du_device_info rcar_du_r8a779md_info = {
+ .gen = 3,
+ .features = RCAR_DU_FEATURE_CRTC_IRQ
+ | RCAR_DU_FEATURE_CRTC_CLOCK
+ | RCAR_DU_FEATURE_VSP1_SOURCE
+ | RCAR_DU_FEATURE_INTERLACED
+ | RCAR_DU_FEATURE_TVM_SYNC,
+ .channels_mask = BIT(1) | BIT(0),
+ .routes = {
+ /* R8A779MD has one RGB output and one LVDS output. */
+ [RCAR_DU_OUTPUT_DPAD0] = {
+ .possible_crtcs = BIT(1),
+ .port = 0,
+ },
+ [RCAR_DU_OUTPUT_LVDS0] = {
+ .possible_crtcs = BIT(0),
+ .port = 2,
+ },
+ },
+ .num_lvds = 1,
+ .num_rpf = 5,
+ .dpll_mask = BIT(1),
+};
+
static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7742", .data = &rcar_du_r8a7790_info },
{ .compatible = "renesas,du-r8a7743", .data = &rzg1_du_r8a7743_info },
@@ -591,6 +615,7 @@ static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a779a0", .data = &rcar_du_r8a779a0_info },
{ .compatible = "renesas,du-r8a779g0", .data = &rcar_du_r8a779g0_info },
{ .compatible = "renesas,du-r8a779h0", .data = &rcar_du_r8a779h0_info },
+ { .compatible = "renesas,du-r8a779md", .data = &rcar_du_r8a779md_info },
{ }
};
--
2.53.0
^ permalink raw reply related
* [PATCH 4/7] dt-bindings: soc: renesas: Document Renesas R-Car R8A779MD Geist
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Document the compatible value for the Renesas R-Car M3Le (R8A779MD)
SoC and the Renesas Geist development board. The Renesas M3Le SoC is
a register-compatible variant of the R8A77965 (M3-N) with reduced set
of peripherals. The Geist board is derived from Renesas Salvator-X/XS
boards, with adjustment for the R8A779MD SoC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
Documentation/devicetree/bindings/soc/renesas/renesas.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml
index 5c22c51b1533d..bda223237c812 100644
--- a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml
@@ -473,6 +473,12 @@ properties:
- const: renesas,r8a779mb
- const: renesas,r8a7795
+ - description: R-Car M3Le (R8A779MD)
+ items:
+ - const: renesas,geist # M3Le Geist
+ - const: renesas,r8a779md
+ - const: renesas,r8a77965
+
- description: R-Car X5H (R8A78000)
items:
- enum:
--
2.53.0
^ permalink raw reply related
* [PATCH 3/7] dt-bindings: clock: cs2000-cp: document CS2500
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Document backward compatibility support for CS2500 chip, which
is a drop-in replacement for CS2000 chip.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
.../devicetree/bindings/clock/cirrus,cs2000-cp.yaml | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
index d416c374e8534..031c52b2e5cec 100644
--- a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
+++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
@@ -11,14 +11,18 @@ maintainers:
description: |
The CS2000-CP is an extremely versatile system clocking device that
- utilizes a programmable phase lock loop.
+ utilizes a programmable phase lock loop. CP2500-CP is a compatible
+ drop-in replacement for CP2000-CP.
Link: https://www.cirrus.com/products/cs2000/
properties:
compatible:
- enum:
- - cirrus,cs2000-cp
+ oneOf:
+ - items:
+ - const: cirrus,cs2500-cp
+ - const: cirrus,cs2000-cp
+ - const: cirrus,cs2000-cp
clocks:
description:
--
2.53.0
^ permalink raw reply related
* [PATCH 5/7] soc: renesas: Identify Renesas R-Car R8A779MD M3Le SoC
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Add support for identifying the R-Car M3Le (R8A779MD) SoC.
The Renesas R-Car R8A779MD M3Le SoC is a variant of the
already supported R-Car M3-N SoC with reduced peripherals.
Enable support for the M3Le SoC through already existing
ARCH_R8A77965 configuration symbol. PRR reads 0x67c05501 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/soc/renesas/renesas-soc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
index 38ff0b823bdaf..c82835cf6d8e9 100644
--- a/drivers/soc/renesas/renesas-soc.c
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -361,6 +361,7 @@ static const struct of_device_id renesas_socs[] __initconst __maybe_unused = {
{ .compatible = "renesas,r8a77965", .data = &soc_rcar_m3_n },
{ .compatible = "renesas,r8a779m4", .data = &soc_rcar_m3_n },
{ .compatible = "renesas,r8a779m5", .data = &soc_rcar_m3_n },
+ { .compatible = "renesas,r8a779md", .data = &soc_rcar_m3_n },
#endif
#ifdef CONFIG_ARCH_R8A77970
{ .compatible = "renesas,r8a77970", .data = &soc_rcar_v3m },
--
2.53.0
^ permalink raw reply related
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