* [PATCH v1 1/2] dt-bindings: iio: adc: avia-hx711: add avia,hx710b compatible
From: Piyush Patle @ 2026-04-18 17:05 UTC (permalink / raw)
To: jic23, ak, robh, krzk+dt, conor+dt
Cc: dlechner, nuno.sa, andy, linux-iio, devicetree, linux-kernel
Add the HX710B compatible to the binding and describe the variant-specific
channel and gain model.
Also add an example node for HX710B so the schema covers both supported
parts.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
---
.../bindings/iio/adc/avia-hx711.yaml | 36 +++++++++++++++----
1 file changed, 30 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
index 9c57eb13f892..19318c4dd994 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
@@ -4,7 +4,7 @@
$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>
@@ -12,9 +12,19 @@ maintainers:
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
+ and 1 to 3 additional cycles for selection of the input channel and gain
+ for the next measurement
+ - dout-gpio is the sensor data output the sensor drives in response to
+ the clock
+
+ HX711: 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.
+
+ HX710B: 24-bit ADC with fixed gain of 128. Channel 0 is the differential
+ input and channel 1 measures the DVDD-AVDD supply voltage difference.
+ Channel selection for the next conversion is controlled by the number of
+ trailing PD_SCK pulses.
Specifications about the driver can be found at:
http://www.aviaic.com/ENProducts.aspx
@@ -23,11 +33,12 @@ properties:
compatible:
enum:
- avia,hx711
+ - avia,hx710b
sck-gpios:
description:
Definition of the GPIO for the clock (output). In the datasheet it is
- named PD_SCK
+ named PD_SCK.
maxItems: 1
dout-gpios:
@@ -43,6 +54,9 @@ properties:
Definition of the regulator used as analog supply
clock-frequency:
+ description:
+ Bit-bang clock frequency on PD_SCK. Keep the PD_SCK high time below
+ the chip power-down threshold.
minimum: 20000
maximum: 2500000
default: 400000
@@ -58,10 +72,20 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- weight {
+ /* HX711 example */
+ weight0 {
compatible = "avia,hx711";
sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
avdd-supply = <&avdd>;
clock-frequency = <100000>;
};
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ /* HX710B example */
+ 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
* Re: [PATCH v1 0/2] iio: adc: hx711: add HX710B support
From: Piyush Patle @ 2026-04-18 17:14 UTC (permalink / raw)
To: jic23, ak, robh, krzk+dt, conor+dt; +Cc: linux-iio, devicetree, linux-kernel
In-Reply-To: <20260418170519.312360-1-piyushpatle228@gmail.com>
On Sat, Apr 18, 2026 at 10:35 PM Piyush Patle <piyushpatle228@gmail.com> wrote:
>
> 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 and document the variant-specific behavior.
> The second patch extends the driver with per-chip configuration, HX710B
> channel selection through trailing pulse counts, and fixed-scale
> handling for the variant.
>
> Tested on PocketBeagle2 with an HX710B breakout module. The device
> probed successfully and raw readings were stable.
>
> 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 | 36 ++-
> drivers/iio/adc/Kconfig | 9 +-
> drivers/iio/adc/hx711.c | 222 ++++++++++++++----
> 3 files changed, 214 insertions(+), 53 deletions(-)
>
> --
> 2.43.0
The two patches in this series were sent without proper In-Reply-To
threading by mistake.
Patch 1/2:
[PATCH v1 1/2] dt-bindings: iio: adc: avia-hx711: add avia,hx710b compatible
Patch 2/2:
[PATCH v1 2/2] iio: adc: hx711: add support for HX710B
Apologies!
^ permalink raw reply
* Re: [PATCH 09/10] ARM: dts: qcom: msm8960: add Riva
From: Dmitry Baryshkov @ 2026-04-18 17:46 UTC (permalink / raw)
To: linux
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio,
Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta
In-Reply-To: <20260414-msm8960-wifi-v1-9-007fda9d6134@smankusors.com>
On Tue, Apr 14, 2026 at 01:55:36AM +0700, Antony Kurniawan Soemardi via B4 Relay wrote:
> From: Antony Kurniawan Soemardi <linux@smankusors.com>
>
> Add the Riva Peripheral Image Loader node to support the Wireless
> Connectivity and Networking Subsystem on MSM8960. This includes:
>
> - Reserved memory region for WCNSS firmware
> - WCN3660 iris radio controller
> - Bluetooth and Wi-Fi sub-devices exposed via the SMD edge
> - Pinctrl states for Bluetooth and Wi-Fi power management
>
> Tested-by: Rudraksha Gupta <guptarud@gmail.com>
> Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
> ---
> arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 78 ++++++++++++++++++++++++++++++++
> 1 file changed, 78 insertions(+)
>
> @@ -456,6 +489,51 @@ saw1_vreg: regulator {
> };
> };
>
> + riva: riva-pil@3200800 {
> + compatible = "qcom,riva-pil";
> + reg = <0x03200800 0x1000>, <0x03202000 0x2000>, <0x03204000 0x100>;
> + reg-names = "ccu", "dxe", "pmu";
If this is going to be resent, one item per line, please (for both reg
and reg-names). Align to '<' or '"'.
> + interrupts-extended = <&intc GIC_SPI 199 IRQ_TYPE_EDGE_RISING>,
> + <&wcnss_smsm 6 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "wdog", "fatal";
> + memory-region = <&wcnss_mem>;
> +
> + status = "disabled";
> +
> + iris {
> + compatible = "qcom,wcn3660";
> + clocks = <&cxo_board>;
> + clock-names = "xo";
> + };
> +
> + smd-edge {
> + interrupts = <GIC_SPI 198 IRQ_TYPE_EDGE_RISING>;
> + label = "riva";
> + qcom,ipc = <&l2cc 8 25>;
> + qcom,smd-edge = <6>;
> +
> + wcnss {
> + compatible = "qcom,wcnss";
> + qcom,smd-channels = "WCNSS_CTRL";
> + qcom,mmio = <&riva>;
> +
> + bluetooth {
> + compatible = "qcom,wcnss-bt";
> + };
> +
> + wifi {
> + compatible = "qcom,wcnss-wlan";
> + interrupts = <GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "tx", "rx";
> + qcom,smem-states = <&apps_smsm 10>, <&apps_smsm 9>;
The same for interrupt-names and smem-states.
Other than that:
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> + qcom,smem-state-names = "tx-enable",
> + "tx-rings-empty";
> + };
> + };
> + };
> + };
> +
> clock-controller@4000000 {
> compatible = "qcom,mmcc-msm8960";
> reg = <0x4000000 0x1000>;
>
> --
> 2.34.1
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH RFC v4 7/7] arm64: dts: qcom: milos: Add Adreno 810 GPU and GMU nodes
From: Dmitry Baryshkov @ 2026-04-18 17:53 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Akhil P Oommen,
Bjorn Andersson, Luca Weiss, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel
In-Reply-To: <20260416-adreno-810-v4-7-61676e073f8a@pm.me>
On Thu, Apr 16, 2026 at 11:05:57AM +0000, Alexander Koskovich wrote:
> Add GPU and GMU devicetree nodes for the Adreno 810 GPU found on
> Qualcomm SM7635 (Milos) based devices.
>
> The qcom,kaanapali-gxclkctl.h header can be reused here because
> Milos uses the same driver and the GX_CLKCTL_GX_GDSC definition
> is identical.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> arch/arm64/boot/dts/qcom/milos.dtsi | 166 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 166 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: purwa-iot-evk: Update TSENS thermal zone
From: Dmitry Baryshkov @ 2026-04-18 17:56 UTC (permalink / raw)
To: Gaurav Kohli
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
manaf.pallikunhi
In-Reply-To: <20260416-purwa_high_tj-v1-1-b538f98d42da@oss.qualcomm.com>
On Thu, Apr 16, 2026 at 05:04:48PM +0530, Gaurav Kohli wrote:
> Purwa IOT boards support a different thermal junction temperature
> specification compared to the base Purwa platform due to package
> level differences.
>
> Update the passive trip thresholds to 105°C to align with the higher
> temperature specification.
>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/purwa-iot-evk.dts | 32 ++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> index ad503beec1d3..261d1e85651d 100644
> --- a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
Is it a property of the SKU used in the EVK or a property of the overall
form factor, cooling, etc.? In the former case it should go to
purwa-iot-som.dtsi.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 3/8] wifi: ath10k: snoc: support powering on the device via pwrseq
From: Dmitry Baryshkov @ 2026-04-18 19:38 UTC (permalink / raw)
To: Luca Weiss
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Jeff Johnson, Bjorn Andersson,
Konrad Dybcio, Manivannan Sadhasivam, Vinod Koul,
Balakrishna Godavarthi, Matthias Kaehlcke, linux-arm-msm,
linux-kernel, devicetree, linux-bluetooth, linux-wireless, ath10k,
linux-pm, Krzysztof Kozlowski, Bartosz Golaszewski
In-Reply-To: <DHUHU7UIT487.139L3KIVRVREU@fairphone.com>
On Thu, Apr 16, 2026 at 12:06:09PM +0200, Luca Weiss wrote:
> Hi Dmitry,
>
> On Mon Jan 19, 2026 at 6:07 PM CET, Dmitry Baryshkov wrote:
> > The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading
> > voltages over internal rails. Implement support for using powersequencer
> > for this family of ATH10k devices in addition to using regulators.
> >
> > Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > ---
> > drivers/net/wireless/ath/ath10k/snoc.c | 53 ++++++++++++++++++++++++++++++++--
> > drivers/net/wireless/ath/ath10k/snoc.h | 3 ++
> > 2 files changed, 53 insertions(+), 3 deletions(-)
> >
> > + ar_snoc->pwrseq = devm_pwrseq_get(&pdev->dev, "wlan");
> > + if (IS_ERR(ar_snoc->pwrseq)) {
> > + ret = PTR_ERR(ar_snoc->pwrseq);
> > + ar_snoc->pwrseq = NULL;
> > + if (ret != -EPROBE_DEFER)
> > + goto err_free_irq;
>
> I'm fairly sure this is now broken with CONFIG_POWER_SEQUENCING=n since
> then pwrseq_get() is returning ERR_PTR(-ENOSYS) which is not handled
> here.
>
> I'm observing my ath10k_snoc is now failing to probe "with error -38"
> which definitely seems to be related, but I haven't debugged it further
> yet.
Posted https://patch.msgid.link/20260418-ath10k-snoc-pwrseq-v1-1-832594ba3294@oss.qualcomm.com
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 0/5] Update APDS990x ALS to support device trees
From: Svyatoslav Ryhel @ 2026-04-18 19:48 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Greg Kroah-Hartman, Randy Dunlap, linux-iio, devicetree,
linux-kernel
In-Reply-To: <36e3611d-642e-42de-9a56-cf81c3e06832@baylibre.com>
сб, 18 квіт. 2026 р. о 19:24 David Lechner <dlechner@baylibre.com> пише:
>
> On 4/18/26 9:47 AM, Svyatoslav Ryhel wrote:
> > Document Avago APDS9900/9901 ALS/Proximity sensor in schema and modernize
> > its driver to support OF bindings.
> >
> > Svyatoslav Ryhel (5):
> > dt-bindings: iio: light: Document Avago APDS9900/9901 ALS/Proximity
> > sensor
> > misc: apds990x: Use more device managed approach in the probe
> > misc: apds990x: Drop Vled supply
> > misc: apds990x: Convert to use OF bindings
> > misc: apds990x: Drop IRQF_TRIGGER_LOW trigger
> >
> > .../bindings/iio/light/avago,apds9900.yaml | 83 ++++++++
> > drivers/misc/apds990x.c | 197 +++++++++---------
>
> As mentioned in my reply to the dt-bindings patch, there is already an
> IIO driver that looks like it could be compatible. I'm guessing that
> this misc driver pre-dates the IIO subsystem. I would have a look at it
> instead (drivers/iio/light/tsl2772.c).
>
tsl2772 driver fits, thanks for pointing out. Maybe you know how
apds9930 lux table was calculated? It is quite obscure to me.
Obviously this patchset is obsolete and different set of changes is required.
> > include/linux/platform_data/apds990x.h | 65 ------
> > 3 files changed, 187 insertions(+), 158 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/iio/light/avago,apds9900.yaml
> > delete mode 100644 include/linux/platform_data/apds990x.h
> >
>
^ permalink raw reply
* Re: [PATCH v2 1/3] MAINTAINERS: Move Peter De Schrijver to CREDITS
From: Aaro Koskinen @ 2026-04-18 20:07 UTC (permalink / raw)
To: Thierry Reding
Cc: Geert Uytterhoeven, linux-tegra, linux-arm-kernel, linux-pm,
linux-omap, linux-m68k, devicetree, linux-kernel, Paul Walmsley
In-Reply-To: <20260417131549.3154534-1-thierry.reding@kernel.org>
Hi,
On Fri, Apr 17, 2026 at 03:15:46PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Peter sadly passed away a while back. Paul did a much better job at
> finding the right words to mourn this loss than I ever could, so I will
> leave this link here:
>
> https://lore.kernel.org/lkml/alpine.DEB.2.21.999.2407240345480.11116@utopia.booyaka.com/T/#u
>
> Co-developed-by: Paul Walmsley <pjw@kernel.org>
> Co-developed-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> Co-developed-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Aaro Koskinen <aaro.koskinen@iki.fi>
A.
> ---
> Changes in v2:
> - add more missing entries
>
> CREDITS | 10 ++++++++++
> MAINTAINERS | 1 -
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/CREDITS b/CREDITS
> index 885fb05d8816..afd1f70b41cf 100644
> --- a/CREDITS
> +++ b/CREDITS
> @@ -3645,7 +3645,17 @@ D: Macintosh IDE Driver
>
> N: Peter De Schrijver
> E: stud11@cc4.kuleuven.ac.be
> +E: p2@mind.be
> +E: peter.de-schrijver@nokia.com
> +E: pdeschrijver@nvidia.com
> +E: p2@psychaos.be
> +D: Apollo Domain workstations
> +D: Ariadne and Hydra Amiga Ethernet drivers
> +D: IBM PS/2, Microchannel, and Token Ring support
> D: Mitsumi CD-ROM driver patches March version
> +D: TWL4030 power management and audio codec driver
> +D: OMAP power management
> +D: NVIDIA Tegra clock and BPMP drivers, among many other things
> S: Molenbaan 29
> S: B2240 Zandhoven
> S: Belgium
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ef978bfca514..ffe20d770249 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -26145,7 +26145,6 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git
> N: [^a-z]tegra
>
> TEGRA CLOCK DRIVER
> -M: Peter De Schrijver <pdeschrijver@nvidia.com>
> M: Prashant Gaikwad <pgaikwad@nvidia.com>
> S: Supported
> F: drivers/clk/tegra/
> --
> 2.52.0
>
>
^ permalink raw reply
* Re: [PATCH v1 0/5] Update APDS990x ALS to support device trees
From: Arnd Bergmann @ 2026-04-18 20:18 UTC (permalink / raw)
To: David Lechner, Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Randy Dunlap
Cc: linux-iio, devicetree, linux-kernel
In-Reply-To: <36e3611d-642e-42de-9a56-cf81c3e06832@baylibre.com>
On Sat, Apr 18, 2026, at 18:24, David Lechner wrote:
> On 4/18/26 9:47 AM, Svyatoslav Ryhel wrote:
>> Document Avago APDS9900/9901 ALS/Proximity sensor in schema and modernize
>> its driver to support OF bindings.
>>
>> Svyatoslav Ryhel (5):
>> dt-bindings: iio: light: Document Avago APDS9900/9901 ALS/Proximity
>> sensor
>> misc: apds990x: Use more device managed approach in the probe
>> misc: apds990x: Drop Vled supply
>> misc: apds990x: Convert to use OF bindings
>> misc: apds990x: Drop IRQF_TRIGGER_LOW trigger
>>
>> .../bindings/iio/light/avago,apds9900.yaml | 83 ++++++++
>> drivers/misc/apds990x.c | 197 +++++++++---------
>
> As mentioned in my reply to the dt-bindings patch, there is already an
> IIO driver that looks like it could be compatible. I'm guessing that
> this misc driver pre-dates the IIO subsystem. I would have a look at it
> instead (drivers/iio/light/tsl2772.c).
I see that we have a number of ALS drivers like this one in drivers/misc:
drivers/misc/apds9802als.c
drivers/misc/apds990x.c
drivers/misc/bh1770glc.c
drivers/misc/isl29020.c
drivers/misc/isl29003.c
As far as I can tell, all of these are entirely unused, with nothing
in the kernel creating the platform devices. The drivers that used
instead have all been converted to drivers/iio a long time ago.
Is it time to remove all of the above?
The notable exception is drivers/misc/tsl2550.c, which is instantiated
from both arch/arm/boot/dts/ti/omap/am335x-evm.dts and
drivers/i2c/busses/i2c-taos-evm.c. There is a similarly named
drivers/iio/light/tsl2563.c driver, but unfortunately that uses
a completely different register level interface.
Arnd
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: qcom: Introduce IPQ9650 TLMM driver
From: Dmitry Baryshkov @ 2026-04-18 20:22 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260415-ipq9650_tlmm-v1-2-bd16ccb06332@oss.qualcomm.com>
On Wed, Apr 15, 2026 at 04:59:25PM +0530, Kathiravan Thirumoorthy wrote:
> Qualcomm's IPQ9650 comes with a TLMM block, like all other platforms,
> so add a driver for it.
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
> drivers/pinctrl/qcom/Kconfig.msm | 9 +
> drivers/pinctrl/qcom/Makefile | 1 +
> drivers/pinctrl/qcom/pinctrl-ipq9650.c | 762 +++++++++++++++++++++++++++++++++
> 3 files changed, 772 insertions(+)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: iio: adc: avia-hx711: add avia,hx710b compatible
From: David Lechner @ 2026-04-18 21:46 UTC (permalink / raw)
To: Piyush Patle, jic23, ak, robh, krzk+dt, conor+dt
Cc: nuno.sa, andy, linux-iio, devicetree, linux-kernel
In-Reply-To: <20260418170549.312446-1-piyushpatle228@gmail.com>
On 4/18/26 12:05 PM, Piyush Patle wrote:
> Add the HX710B compatible to the binding and describe the variant-specific
> channel and gain model.
>
> Also add an example node for HX710B so the schema covers both supported
> parts.
>
> Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
> ---
> .../bindings/iio/adc/avia-hx711.yaml | 36 +++++++++++++++----
> 1 file changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
> index 9c57eb13f892..19318c4dd994 100644
> --- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
> @@ -4,7 +4,7 @@
> $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>
> @@ -12,9 +12,19 @@ maintainers:
> 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
> + and 1 to 3 additional cycles for selection of the input channel and gain
> + for the next measurement
> + - dout-gpio is the sensor data output the sensor drives in response to
> + the clock
> +
> + HX711: 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.
> +
> + HX710B: 24-bit ADC with fixed gain of 128. Channel 0 is the differential
> + input and channel 1 measures the DVDD-AVDD supply voltage difference.
> + Channel selection for the next conversion is controlled by the number of
> + trailing PD_SCK pulses.
The bits about "bit-banging" and "channel selection" sound like driver
implementation details that don't belong in the DT bindings.
>
> Specifications about the driver can be found at:
> http://www.aviaic.com/ENProducts.aspx
> @@ -23,11 +33,12 @@ properties:
> compatible:
> enum:
> - avia,hx711
> + - avia,hx710b
>
> sck-gpios:
> description:
> Definition of the GPIO for the clock (output). In the datasheet it is
> - named PD_SCK
> + named PD_SCK.
Save the cleanups for a separate patch to keep the adding HX710B changes clear.
I'm guessing the existing binding for HX711 is quite old because it is quite
incomplete.
It has avdd-supply, but is missing vsup-supply and dvdd-supply.
It should probably also have a way to describe how the rate pin is wired.
And it should have a clocks property instead of clock-frequency.
It would make sense to have two clocks, on for XI/XO and one for PD_SCK.
The second one being optional because of sck-gpios.
HX710B has many fewer pins, so we will need an:
allOf:
- if:
properties:
compatible:
const: avia,hx710b
section that sets anything for pins that chip doesn't have to false, like
vsup-supply.
HX710B also has a vref-supply that HX711 doesn't have. (Unless these are the
same thing by a different name?)
> maxItems: 1
>
> dout-gpios:
> @@ -43,6 +54,9 @@ properties:
> Definition of the regulator used as analog supply
>
> clock-frequency:
> + description:
> + Bit-bang clock frequency on PD_SCK. Keep the PD_SCK high time below
> + the chip power-down threshold.
I suspect that this was meant to be the crystal frequency (XI/XO), not PD_SCK
since sck-gpios already exists for PD_SCK
> minimum: 20000
> maximum: 2500000
> default: 400000
> @@ -58,10 +72,20 @@ additionalProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> - weight {
> + /* HX711 example */
The compatible string already has the part number, so this comment
doesn't really and any new info.
> + weight0 {
> compatible = "avia,hx711";
> sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
> dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
> avdd-supply = <&avdd>;
> clock-frequency = <100000>;
> };
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + /* HX710B example */
> + weight1 {
> + compatible = "avia,hx710b";
> + sck-gpios = <&gpio3 11 GPIO_ACTIVE_HIGH>;
> + dout-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
> + avdd-supply = <&avdd>;
> + };
There is nothing significantly different about this example, so it
isn't particularly useful.
^ permalink raw reply
* Re: [PATCH RFC v3 06/11] RISC-V: QoS: add resctrl setup and domain management
From: Drew Fustini @ 2026-04-18 22:01 UTC (permalink / raw)
To: guo.wenjia23
Cc: pjw, palmer, aou, alex, rkrcmar, samuel.holland, aricciardi,
npitre, mindal, atish.patra, atishp, vasu, ved, conor.dooley,
cuiyunhui, cp0613, zhiwei_liu, liwei1518, gong.shuai, gsh517,
liu.qingtao2, reinette.chatre, tony.luck, babu.moger, peternewman,
fenghua.yu, james.morse, ben.horgan, Dave.Martin, robh, conor+dt,
krzk+dt, rafael, lenb, robert.moore, sunilvl, linux-kernel,
linux-riscv, x86, linux-acpi, acpica-devel, devicetree,
paul.walmsley
In-Reply-To: <202604180028.63I0Svo8029922@mse-fl1.zte.com.cn>
On Fri, Apr 17, 2026 at 06:52:27PM +0800, guo.wenjia23@zte.com.cn wrote:
> Hi Drew,
>
> On Wed, Apr 15, 2026 at 9:57 AM Drew Fustini <fustini@kernel.org> wrote:
>
> > Add the setup and domain management layer: domain allocation
> > (qos_new_domain), controller value initialization
> > (qos_init_domain_ctrlval), resource struct initialization for cache and
> > bandwidth resources, domain registration with the resctrl filesystem
> > (qos_resctrl_add_controller_domain), and the top-level setup function
> > (qos_resctrl_setup) that probes all controllers and calls resctrl_init().
> >
> > Also add qos_resctrl_online_cpu() and qos_resctrl_offline_cpu() for CPU
> > hotplug integration.
> >
> > Co-developed-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > Signed-off-by: Drew Fustini <fustini@kernel.org>
> > ---
> > arch/riscv/kernel/qos/qos_resctrl.c | 295 +++++++++++++++++++++++++++++++++++-
> > 1 file changed, 294 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/riscv/kernel/qos/qos_resctrl.c b/arch/riscv/kernel/qos/qos_resctrl.c
> > index a4a120f89840..8d7e3b0abb75 100644
> > --- a/arch/riscv/kernel/qos/qos_resctrl.c
> > +++ b/arch/riscv/kernel/qos/qos_resctrl.c
> > @@ -675,7 +675,23 @@ void resctrl_arch_reset_rmid_all(struct rdt_resource *r, struct rdt_l3_mon_domai
> >
> > void resctrl_arch_reset_all_ctrls(struct rdt_resource *r)
> > {
> > - /* not implemented for the RISC-V resctrl implementation */
> > + struct cbqri_resctrl_res *hw_res;
> > + struct rdt_ctrl_domain *d;
> > + enum resctrl_conf_type t;
> > + u32 default_ctrl;
> > + int i;
> > +
> > + lockdep_assert_cpus_held();
> > +
> > + hw_res = container_of(r, struct cbqri_resctrl_res, resctrl_res);
> > + default_ctrl = resctrl_get_default_ctrl(r);
> > +
> > + list_for_each_entry(d, &r->ctrl_domains, hdr.list) {
> > + for (i = 0; i < hw_res->max_rcid; i++) {
> > + for (t = 0; t < CDP_NUM_TYPES; t++)
> > + resctrl_arch_update_one(r, d, i, t, default_ctrl);
>
> For the bw controller, default_ctrl = max_bw, and
> resctrl_arch_update_one will set the rbwb of all RCIDs to max_bw.
> According to the spec: The sum of Rbwb allocated across all rcids must
> not exceed MRBWB value.
>
> Does this conflict with the spec?
Good point. Yeah, this is not being done correctly. I had been doing
similar to what is done on x86 but the big difference is that CBQRI is
reservation based.
Each RCID must have at least 1 Rbwb, and the remainder should be
assigned to default group, RCID 0. It'll update the implementation.
Thanks,
Drew
^ permalink raw reply
* Re: [PATCH v1 0/5] Update APDS990x ALS to support device trees
From: David Lechner @ 2026-04-18 22:18 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Greg Kroah-Hartman, Randy Dunlap, linux-iio, devicetree,
linux-kernel
In-Reply-To: <CAPVz0n1ph0Cjw9WOqoVPaEywF0MzaNXeEjw6=0rKf4qLWiJZtw@mail.gmail.com>
On 4/18/26 2:48 PM, Svyatoslav Ryhel wrote:
> сб, 18 квіт. 2026 р. о 19:24 David Lechner <dlechner@baylibre.com> пише:
>>
>> On 4/18/26 9:47 AM, Svyatoslav Ryhel wrote:
>>> Document Avago APDS9900/9901 ALS/Proximity sensor in schema and modernize
>>> its driver to support OF bindings.
>>>
>>> Svyatoslav Ryhel (5):
>>> dt-bindings: iio: light: Document Avago APDS9900/9901 ALS/Proximity
>>> sensor
>>> misc: apds990x: Use more device managed approach in the probe
>>> misc: apds990x: Drop Vled supply
>>> misc: apds990x: Convert to use OF bindings
>>> misc: apds990x: Drop IRQF_TRIGGER_LOW trigger
>>>
>>> .../bindings/iio/light/avago,apds9900.yaml | 83 ++++++++
>>> drivers/misc/apds990x.c | 197 +++++++++---------
>>
>> As mentioned in my reply to the dt-bindings patch, there is already an
>> IIO driver that looks like it could be compatible. I'm guessing that
>> this misc driver pre-dates the IIO subsystem. I would have a look at it
>> instead (drivers/iio/light/tsl2772.c).
>>
>
> tsl2772 driver fits, thanks for pointing out. Maybe you know how
> apds9930 lux table was calculated? It is quite obscure to me.
The tsl2772 driver says:
/*
* Different devices require different coefficents, and these numbers were
* derived from the 'Lux Equation' section of the various device datasheets.
* All of these coefficients assume a Glass Attenuation (GA) factor of 1.
* The coefficients are multiplied by 1000 to avoid floating point operations.
* The two rows in each table correspond to the Lux1 and Lux2 equations from
* the datasheets.
*/
So probably just need to look up the A tsl datasheet and compare it to the
apds datasheet. The apds has some equations with GA, so just need to figure
out what Lux1 and Lux2 correspond to.
>
> Obviously this patchset is obsolete and different set of changes is required.
>
>>> include/linux/platform_data/apds990x.h | 65 ------
>>> 3 files changed, 187 insertions(+), 158 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/iio/light/avago,apds9900.yaml
>>> delete mode 100644 include/linux/platform_data/apds990x.h
>>>
>>
^ permalink raw reply
* Re: [PATCH v5 2/2] arm64: dts: qcom: Add Xiaomi 12 Lite 5G (taoyao) DTS
From: Dmitry Baryshkov @ 2026-04-18 23:47 UTC (permalink / raw)
To: Stanislav Zaikin
Cc: devicetree, linux-arm-msm, andersson, konradybcio, robh, krzk+dt,
conor+dt, linux-kernel, val
In-Reply-To: <20260417084749.253242-3-zstaseg@gmail.com>
On Fri, Apr 17, 2026 at 10:47:49AM +0200, Stanislav Zaikin wrote:
> Xiaomi 12 Lite 5G is a handset released in 2022
>
> This commit has the following features working:
> - Display (with simple fb)
> - Touchscreen
> - UFS
> - Power and volume buttons
> - Pinctrl
> - RPM Regulators
> - Remoteprocs - wifi, bluetooth
> - USB (Device Mode)
>
> Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> .../boot/dts/qcom/sm7325-xiaomi-taoyao.dts | 907 ++++++++++++++++++
> 2 files changed, 908 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/sm7325-xiaomi-taoyao.dts
>
> +
> +&ipa {
> + qcom,gsi-loader = "self";
> + memory-region = <&ipa_fw_mem>;
Could you please move these properties to SoC dtsi (as a separate
commit).
> + firmware-name = "qcom/sm7325/xiaomi/taoyao/ipa_fws.mbn";
> +
> + status = "okay";
> +};
> +
> +
> +&tlmm {
> + gpio-reserved-ranges = <48 4>, <56 4>;
Could you please add a comment why they are reserved? I _assume_ that 48
is NFC SE and 56 is fingerprint reader
> +
> +
> +&wifi {
> + qcom,calibration-variant = "Xiaomi_taoyao";
> +
> + status = "okay";
> +};
> --
> 2.51.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: eliza: Add IMEM node
From: Dmitry Baryshkov @ 2026-04-19 0:11 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260415-eliza-imem-v1-2-4a90e8683799@pm.me>
On Thu, Apr 16, 2026 at 12:23:41AM +0000, Alexander Koskovich wrote:
> Add a node for the IMEM found on Eliza, which contains pil-reloc-info
> and the modem tables for IPA, among others.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> arch/arm64/boot/dts/qcom/eliza.dtsi | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 3/4] dt-bindings: gpio: describe Waveshare GPIO controller
From: Dmitry Baryshkov @ 2026-04-19 0:31 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: dri-devel, Jessica Zhang, Conor Dooley, Simona Vetter, linux-gpio,
Conor Dooley, Javier Martinez Canillas, Maxime Ripard, Jagan Teki,
David Airlie, Maarten Lankhorst, Bartosz Golaszewski,
Neil Armstrong, Cong Yang, Jie Gan, Mark Brown, devicetree,
Krzysztof Kozlowski, linux-kernel, Linus Walleij, Ondrej Jirman,
Thomas Zimmermann, Liam Girdwood
In-Reply-To: <177647276773.3416847.5121391765535033685.robh@kernel.org>
On Fri, Apr 17, 2026 at 07:39:27PM -0500, Rob Herring (Arm) wrote:
>
> On Sat, 18 Apr 2026 02:16:22 +0300, Dmitry Baryshkov wrote:
> > The Waveshare DSI TOUCH family of panels has separate on-board GPIO
> > controller, which controls power supplies to the panel and the touch
> > screen and provides reset pins for both the panel and the touchscreen.
> > Also it provides a simple PWM controller for panel backlight.
> >
> > Add bindings for these GPIO controllers. As overall integration might be
> > not very obvious (and it differs significantly from the bindings used by
> > the original drivers), provide complete example with the on-board
> > regulators and the DSI panel.
> >
> > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > ---
> > .../bindings/gpio/waveshare,dsi-touch-gpio.yaml | 100 +++++++++++++++++++++
> > 1 file changed, 100 insertions(+)
> >
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/gpio/waveshare,dsi-touch-gpio.example.dtb: panel@0 (waveshare,8.0-dsi-touch-a): compatible:0: 'waveshare,8.0-dsi-touch-a' is not one of ['anbernic,rg-ds-display-bottom', 'anbernic,rg-ds-display-top', 'chongzhou,cz101b4001', 'kingdisplay,kd101ne3-40ti', 'melfas,lmfbx101117480', 'radxa,display-10hd-ad001', 'radxa,display-8hd-ad002', 'taiguanck,xti05101-01a']
> from schema $id: http://devicetree.org/schemas/display/panel/jadard,jd9365da-h3.yaml
> Documentation/devicetree/bindings/gpio/waveshare,dsi-touch-gpio.example.dtb: /example-0/dsi/panel@0: failed to match any schema with compatible: ['waveshare,8.0-dsi-touch-a', 'jadard,jd9365da-h3']
>
Sorry, yes. This patch is now a part of drm-misc-next, but is not in
-next, until 7.1-rc1.
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.kernel.org/project/devicetree/patch/20260418-waveshare-dsi-touch-v4-3-b249f3e702bd@oss.qualcomm.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: iio: adc: avia-hx711: add avia,hx710b compatible
From: Andreas Klinger @ 2026-04-19 5:17 UTC (permalink / raw)
To: David Lechner
Cc: Piyush Patle, jic23, robh, krzk+dt, conor+dt, nuno.sa, andy,
linux-iio, devicetree, linux-kernel
In-Reply-To: <23a00548-feac-4ce6-9a71-509b7636b372@baylibre.com>
Hi,
David Lechner <dlechner@baylibre.com> schrieb am Sa, 18. Apr 16:46:
> On 4/18/26 12:05 PM, Piyush Patle wrote:
[...]
> >
> > Specifications about the driver can be found at:
> > http://www.aviaic.com/ENProducts.aspx
> > @@ -23,11 +33,12 @@ properties:
> > compatible:
> > enum:
> > - avia,hx711
> > + - avia,hx710b
> >
> > sck-gpios:
> > description:
> > Definition of the GPIO for the clock (output). In the datasheet it is
> > - named PD_SCK
> > + named PD_SCK.
>
> Save the cleanups for a separate patch to keep the adding HX710B changes clear.
>
> I'm guessing the existing binding for HX711 is quite old because it is quite
> incomplete.
>
> It has avdd-supply, but is missing vsup-supply and dvdd-supply.
>
> It should probably also have a way to describe how the rate pin is wired.
>
> And it should have a clocks property instead of clock-frequency.
The real meaning is a wait time until the DOUT is stable. As a submitted the
driver many years ago my suggestion of a wait time property was not accepted
because it would have introduced a new property which didn't exit in those days.
The suggestion was to name it clock-frequency because it already existed. This
clock-frequency made the driver also a little bit more complicated because at
the end we needed a waiting time and not a frequency.
Today i see there is as "wait-delay" property already introduced at other
bindings. This would also simplify the driver a bit.
@robh@kernel.org, @krzk+dt@kernel.org, @conor+dt@kernel.org:
Would this change in the binding be acceptable?
If yes, i could prepare a driver and binding patch separate of this patchset to
clean it up.
> It would make sense to have two clocks, on for XI/XO and one for PD_SCK.
> The second one being optional because of sck-gpios.
>
> HX710B has many fewer pins, so we will need an:
>
> allOf:
> - if:
> properties:
> compatible:
> const: avia,hx710b
>
> section that sets anything for pins that chip doesn't have to false, like
> vsup-supply.
>
> HX710B also has a vref-supply that HX711 doesn't have. (Unless these are the
> same thing by a different name?)
>
>
> > maxItems: 1
> >
> > dout-gpios:
> > @@ -43,6 +54,9 @@ properties:
> > Definition of the regulator used as analog supply
> >
> > clock-frequency:
> > + description:
> > + Bit-bang clock frequency on PD_SCK. Keep the PD_SCK high time below
> > + the chip power-down threshold.
>
> I suspect that this was meant to be the crystal frequency (XI/XO), not PD_SCK
> since sck-gpios already exists for PD_SCK
see above
[...]
Best regards,
Andreas
--
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: purwa-iot-evk: Update TSENS thermal zone
From: Gaurav Kohli @ 2026-04-19 6:46 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
manaf.pallikunhi
In-Reply-To: <xxouwrtrhgyf6y6xgpqev3cxomn72mty7kvuzh4tof3jnmfmnf@6deaf6mhhdpw>
On 4/18/2026 11:26 PM, Dmitry Baryshkov wrote:
> On Thu, Apr 16, 2026 at 05:04:48PM +0530, Gaurav Kohli wrote:
>> Purwa IOT boards support a different thermal junction temperature
>> specification compared to the base Purwa platform due to package
>> level differences.
>>
>> Update the passive trip thresholds to 105°C to align with the higher
>> temperature specification.
>>
>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/purwa-iot-evk.dts | 32 ++++++++++++++++++++++++++++++
>> 1 file changed, 32 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
>> index ad503beec1d3..261d1e85651d 100644
>> --- a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
>> +++ b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
>
> Is it a property of the SKU used in the EVK or a property of the overall
> form factor, cooling, etc.? In the former case it should go to
> purwa-iot-som.dtsi.
>
thanks Dmitry for review.
it is applicable for overall form factor, 2nd one is applicable here.
thanks
Gaurav
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: talos: Add memory-region for audio PD
From: Ekansh Gupta @ 2026-04-19 7:23 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: konrad.dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, quic_bkumar, quic_chennak,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <v4nqsxnapoyrfifcrjjunhu5s4ggl444nj7gdonghqmhbijiej@fzafvs2igmeo>
On 18-04-2026 20:45, Dmitry Baryshkov wrote:
> On Sat, Apr 18, 2026 at 11:18:01AM +0530, Ekansh Gupta wrote:
>> Reserve memory region for audio PD dynamic loading and remote heap
>> requirements. Add the required VMID list for memory ownership
>> transfers.
>>
>> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/talos.dtsi | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
>> index ff5afbfce2a4..c36917d6e0a9 100644
>> --- a/arch/arm64/boot/dts/qcom/talos.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/talos.dtsi
>> @@ -11,6 +11,7 @@
>> #include <dt-bindings/clock/qcom,qcs615-videocc.h>
>> #include <dt-bindings/clock/qcom,rpmh.h>
>> #include <dt-bindings/dma/qcom-gpi.h>
>> +#include <dt-bindings/firmware/qcom,scm.h>
>> #include <dt-bindings/interconnect/qcom,icc.h>
>> #include <dt-bindings/interconnect/qcom,osm-l3.h>
>> #include <dt-bindings/interconnect/qcom,qcs615-rpmh.h>
>> @@ -657,6 +658,11 @@ pil_gpu_mem: pil-gpu@97715000 {
>> reg = <0x0 0x97715000 0x0 0x2000>;
>> no-map;
>> };
>> +
>> + adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap@97717000 {
>> + reg = <0x0 0x97717000 0x0 0x800000>;
>> + no-map;
>> + };
>> };
>>
>> soc: soc@0 {
>> @@ -5100,6 +5106,9 @@ fastrpc {
>> compatible = "qcom,fastrpc";
>> qcom,glink-channels = "fastrpcglink-apps-dsp";
>> label = "adsp";
>> + memory-region = <&adsp_rpc_remote_heap_mem>;
>> + qcom,vmids = <QCOM_SCM_VMID_LPASS
>> + QCOM_SCM_VMID_ADSP_HEAP>;
>
> Align on '<' symbol.
ack
>
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>>
>> ---
>> base-commit: c7275b05bc428c7373d97aa2da02d3a7fa6b9f66
>> change-id: 20260418-talosaudio-b8ecf8b9a1b3
>>
>> Best regards,
>> --
>> Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>>
>
^ permalink raw reply
* [PATCH v2] arm64: dts: qcom: talos: Add memory-region for audio PD
From: Ekansh Gupta via B4 Relay @ 2026-04-19 7:41 UTC (permalink / raw)
To: konrad.dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, quic_bkumar, quic_chennak,
dmitry.baryshkov
Cc: linux-arm-msm, devicetree, linux-kernel, Ekansh Gupta
From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
Reserve memory region for audio PD dynamic loading and remote heap
requirements. Add the required VMID list for memory ownership
transfers.
Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
---
Changes in v2:
- Fixed VMID list alignment.
- Link to v1: https://lore.kernel.org/r/20260418-talosaudio-v1-1-585ab22faaf4@oss.qualcomm.com
---
arch/arm64/boot/dts/qcom/talos.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
index ff5afbfce2a4..f71b327c7ddf 100644
--- a/arch/arm64/boot/dts/qcom/talos.dtsi
+++ b/arch/arm64/boot/dts/qcom/talos.dtsi
@@ -11,6 +11,7 @@
#include <dt-bindings/clock/qcom,qcs615-videocc.h>
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/dma/qcom-gpi.h>
+#include <dt-bindings/firmware/qcom,scm.h>
#include <dt-bindings/interconnect/qcom,icc.h>
#include <dt-bindings/interconnect/qcom,osm-l3.h>
#include <dt-bindings/interconnect/qcom,qcs615-rpmh.h>
@@ -657,6 +658,11 @@ pil_gpu_mem: pil-gpu@97715000 {
reg = <0x0 0x97715000 0x0 0x2000>;
no-map;
};
+
+ adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap@97717000 {
+ reg = <0x0 0x97717000 0x0 0x800000>;
+ no-map;
+ };
};
soc: soc@0 {
@@ -5100,6 +5106,9 @@ fastrpc {
compatible = "qcom,fastrpc";
qcom,glink-channels = "fastrpcglink-apps-dsp";
label = "adsp";
+ memory-region = <&adsp_rpc_remote_heap_mem>;
+ qcom,vmids = <QCOM_SCM_VMID_LPASS
+ QCOM_SCM_VMID_ADSP_HEAP>;
#address-cells = <1>;
#size-cells = <0>;
---
base-commit: c7275b05bc428c7373d97aa2da02d3a7fa6b9f66
change-id: 20260418-talosaudio-b8ecf8b9a1b3
Best regards,
--
Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v1 0/5] Update APDS990x ALS to support device trees
From: Svyatoslav Ryhel @ 2026-04-19 8:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David Lechner, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Randy Dunlap, linux-iio, devicetree,
linux-kernel
In-Reply-To: <6e9e830b-edb6-46a6-919c-8772b904262e@app.fastmail.com>
сб, 18 квіт. 2026 р. о 23:21 Arnd Bergmann <arnd@arndb.de> пише:
>
> On Sat, Apr 18, 2026, at 18:24, David Lechner wrote:
> > On 4/18/26 9:47 AM, Svyatoslav Ryhel wrote:
> >> Document Avago APDS9900/9901 ALS/Proximity sensor in schema and modernize
> >> its driver to support OF bindings.
> >>
> >> Svyatoslav Ryhel (5):
> >> dt-bindings: iio: light: Document Avago APDS9900/9901 ALS/Proximity
> >> sensor
> >> misc: apds990x: Use more device managed approach in the probe
> >> misc: apds990x: Drop Vled supply
> >> misc: apds990x: Convert to use OF bindings
> >> misc: apds990x: Drop IRQF_TRIGGER_LOW trigger
> >>
> >> .../bindings/iio/light/avago,apds9900.yaml | 83 ++++++++
> >> drivers/misc/apds990x.c | 197 +++++++++---------
> >
> > As mentioned in my reply to the dt-bindings patch, there is already an
> > IIO driver that looks like it could be compatible. I'm guessing that
> > this misc driver pre-dates the IIO subsystem. I would have a look at it
> > instead (drivers/iio/light/tsl2772.c).
>
> I see that we have a number of ALS drivers like this one in drivers/misc:
>
> drivers/misc/apds9802als.c
> drivers/misc/apds990x.c
> drivers/misc/bh1770glc.c
> drivers/misc/isl29020.c
> drivers/misc/isl29003.c
>
> As far as I can tell, all of these are entirely unused, with nothing
> in the kernel creating the platform devices. The drivers that used
> instead have all been converted to drivers/iio a long time ago.
>
> Is it time to remove all of the above?
>
I will remove APDS990x from misc in v2 since this one I can convert it
to use tsl2772 instead.
> The notable exception is drivers/misc/tsl2550.c, which is instantiated
> from both arch/arm/boot/dts/ti/omap/am335x-evm.dts and
> drivers/i2c/busses/i2c-taos-evm.c. There is a similarly named
> drivers/iio/light/tsl2563.c driver, but unfortunately that uses
> a completely different register level interface.
>
> Arnd
^ permalink raw reply
* Re: [PATCH v4 2/8] dt-bindings: arm: Add zx297520v3 board binding
From: Stefan Dösinger @ 2026-04-19 8:30 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: linux-kernel, Conor Dooley, Jonathan Corbet, Alexandre Belloni,
Greg Kroah-Hartman, linux-doc, devicetree, Drew Fustini,
Linus Walleij, Jiri Slaby, Russell King, soc, Arnd Bergmann,
Krzysztof Kozlowski, Krzysztof Kozlowski, linux-arm-kernel,
linux-serial, Shuah Khan
In-Reply-To: <177646012448.2165534.5760108355183774935.robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
Hi Rob,
Am Samstag, 18. April 2026, 00:08:44 Ostafrikanische Zeit schrieben Sie:
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
Here is a new PEBKAC issue for your mail template: I ran dt_binding_check, it
wrote the warning you pointed out, but I only checked the return value - which
indicated success. Which I guess makes sense for a warning, since there seem
to be a few preexisting ones. The warning itself was somewhere in the
scrollback because I let dt_binding_check check all the files.
So I learned I have to actually look at the output to see if there are any
warnings.
Cheers,
Stefan
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* [PATCH v2 0/3] Update APDS990x ALS to support device trees
From: Svyatoslav Ryhel @ 2026-04-19 8:31 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Arnd Bergmann, Greg Kroah-Hartman, Svyatoslav Ryhel,
Randy Dunlap
Cc: linux-iio, devicetree, linux-kernel, linux-doc
Document Avago APDS9900/9901 ALS/Proximity sensor in schema and add its support
to tsl2772 driver.
---
Changes in v2:
- dropped all previous patches
- apds990x was documented in tsl2772.yaml
- apds990x support was added to tsl2772.c
- original apds990x driver removed from misc
---
Svyatoslav Ryhel (3):
dt-bindings: iio: light: Document Avago APDS9900/9901 ALS/Proximity
sensor
iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
misc: Remove old APDS990x driver
.../bindings/iio/light/tsl2772.yaml | 2 +
Documentation/misc-devices/apds990x.rst | 128 --
drivers/iio/light/tsl2772.c | 16 +
drivers/misc/Kconfig | 10 -
drivers/misc/Makefile | 1 -
drivers/misc/apds990x.c | 1284 -----------------
include/linux/platform_data/apds990x.h | 65 -
7 files changed, 18 insertions(+), 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
--
2.51.0
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: iio: light: Document Avago APDS9900/9901 ALS/Proximity sensor
From: Svyatoslav Ryhel @ 2026-04-19 8:31 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Arnd Bergmann, Greg Kroah-Hartman, Svyatoslav Ryhel,
Randy Dunlap
Cc: linux-iio, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-1-clamor95@gmail.com>
Document Avago APDS-9900/9901 combined ALS/IR-LED/Proximity sensor.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
Documentation/devicetree/bindings/iio/light/tsl2772.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/light/tsl2772.yaml b/Documentation/devicetree/bindings/iio/light/tsl2772.yaml
index d81229857944..9921ccaa64a0 100644
--- a/Documentation/devicetree/bindings/iio/light/tsl2772.yaml
+++ b/Documentation/devicetree/bindings/iio/light/tsl2772.yaml
@@ -26,6 +26,8 @@ properties:
- amstaos,tmd2672
- amstaos,tsl2772
- amstaos,tmd2772
+ - avago,apds9900
+ - avago,apds9901
- avago,apds9930
reg:
--
2.51.0
^ permalink raw reply related
* [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Svyatoslav Ryhel @ 2026-04-19 8:31 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Arnd Bergmann, Greg Kroah-Hartman, Svyatoslav Ryhel,
Randy Dunlap
Cc: linux-iio, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-1-clamor95@gmail.com>
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>
---
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,
[apds9930] = ALSPRX2,
};
@@ -530,6 +540,7 @@ static int tsl2772_get_prox(struct iio_dev *indio_dev)
case tmd2672:
case tsl2772:
case tmd2772:
+ case apds990x:
case apds9930:
if (!(ret & TSL2772_STA_PRX_VALID)) {
ret = -EINVAL;
@@ -1367,6 +1378,7 @@ static int tsl2772_device_id_verif(int id, int target)
return (id & 0xf0) == TRITON_ID;
case tmd2671:
case tmd2771:
+ case apds990x:
return (id & 0xf0) == HALIBUT_ID;
case tsl2572:
case tsl2672:
@@ -1898,6 +1910,8 @@ static const struct i2c_device_id tsl2772_idtable[] = {
{ "tmd2672", tmd2672 },
{ "tsl2772", tsl2772 },
{ "tmd2772", tmd2772 },
+ { "apds9900", apds990x },
+ { "apds9901", apds990x },
{ "apds9930", apds9930 },
{ }
};
@@ -1915,6 +1929,8 @@ static const struct of_device_id tsl2772_of_match[] = {
{ .compatible = "amstaos,tmd2672" },
{ .compatible = "amstaos,tsl2772" },
{ .compatible = "amstaos,tmd2772" },
+ { .compatible = "avago,apds9900" },
+ { .compatible = "avago,apds9901" },
{ .compatible = "avago,apds9930" },
{ }
};
--
2.51.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