* [PATCH 1/4] arm64: dts: qcom: glymur-crd: Update VREG l2b_e0 and l9b_e0 voltage for SD-card
From: Monish Chunara @ 2026-06-10 11:15 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nitin Rawat, Pradeep Pragallapati, Komal Bajaj, Sachin,
Monish Chunara, linux-arm-msm, devicetree, linux-kernel,
Kamal Wadhwa
In-Reply-To: <20260610111508.3941207-1-mchunara@oss.qualcomm.com>
From: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
SD cards may need 1.8v VDDIO also to be supported, to accommodate this
requirement reduce the min voltage to 1.8v for `vreg_l2b_e0` which
supplies to VDDIO pin of SD card.
NOTE - Since this SD card is the only client on this regulator, this
change should not have any side effect on any other clients.
moreover, SD card driver takes care to explicitly vote for the
regulator voltage based on the SD card detection sequence.
Also for stable operation of the SD card increase VDD voltage
supplied by `vreg_l9b_e0` to 2.96v.
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
index e784b538f42e..af6f42cdd39a 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
@@ -228,7 +228,7 @@ vreg_l1b_e0_1p8: ldo1 {
vreg_l2b_e0_2p9: ldo2 {
regulator-name = "vreg_l2b_e0_2p9";
- regulator-min-microvolt = <2904000>;
+ regulator-min-microvolt = <1804000>;
regulator-max-microvolt = <2904000>;
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
};
@@ -247,10 +247,10 @@ vreg_l8b_e0_1p50: ldo8 {
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
};
- vreg_l9b_e0_2p7: ldo9 {
- regulator-name = "vreg_l9b_e0_2p7";
- regulator-min-microvolt = <2704000>;
- regulator-max-microvolt = <2704000>;
+ vreg_l9b_e0_2p9: ldo9 {
+ regulator-name = "vreg_l9b_e0_2p9";
+ regulator-min-microvolt = <2960000>;
+ regulator-max-microvolt = <2960000>;
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
};
--
2.34.1
^ permalink raw reply related
* [PATCH 0/4] arm64: dts: qcom: Add SD card support for Glymur
From: Monish Chunara @ 2026-06-10 11:15 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nitin Rawat, Pradeep Pragallapati, Komal Bajaj, Sachin,
Monish Chunara, linux-arm-msm, devicetree, linux-kernel
From: Monish Chunara <monish.chunara@oss.qualcomm.com>
This series adds SD card support for the Qualcomm Glymur SoC and the
Glymur CRD (Customer Reference Design) platform. The changes include
updating voltage regulators to meet SD card requirements, documenting
the new compatible string in device tree bindings, and enabling the SDHC
controller at both the SoC and board levels.
Summary of changes:
Patch 1: Updates the voltage ranges for vreg_l2b_e0 and vreg_l9b_e0 on
the Glymur CRD. Specifically, it reduces the minimum voltage for the
VDDIO supply (l2b) to 1.8V to support high-speed SD card modes and
increases the VDD supply (l9b) for stability.
Patch 2: Documents the Glymur-specific SDHCI compatible string
(qcom,glymur-sdhci) in the sdhci-msm bindings, using qcom,sdhci-msm-v5
as the fallback.
Patch 3: Adds the SDHCI (sdhc_2) node and required pinctrl
configurations to the base Glymur SoC device tree.
Patch 4: Enables the SD card slot on the Glymur CRD by configuring the
regulators and GPIO-based card detection.
Testing: Verified on Glymur CRD hardware.
Kamal Wadhwa (1):
arm64: dts: qcom: glymur-crd: Update VREG l2b_e0 and l9b_e0 voltage
for SD-card
Monish Chunara (3):
dt-bindings: mmc: sdhci-msm: Document the Glymur compatible
arm64: dts: qcom: Add SD Card support for Glymur SoC
arm64: dts: qcom: Enable SD card for Glymur CRD
.../bindings/mmc/qcom,sdhci-msm.yaml | 1 +
arch/arm64/boot/dts/qcom/glymur-crd.dts | 25 +++++
arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 10 +-
arch/arm64/boot/dts/qcom/glymur.dtsi | 91 +++++++++++++++++++
4 files changed, 122 insertions(+), 5 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v5 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
From: Andrew Jeffery @ 2026-06-10 11:15 UTC (permalink / raw)
To: Kyle Hsieh, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260608-ventura2_initial_dts-v5-2-37ee5bcf58b6@gmail.com>
Hi Kyle,
On Mon, 2026-06-08 at 10:42 +0800, Kyle Hsieh wrote:
> Add linux device tree entry related to the Meta(Facebook) rmc-node.
This is redundant as it is evident from the patch itself. Can you
please remove it?
> The system use an AT2600 BMC.
> This node is named "ventura2".
Can you provide some more detail about the platform in the commit
message? What's it's purpose? Can you describe some interesting
features or details about its design?
>
> Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
> ---
> arch/arm/boot/dts/aspeed/Makefile | 1 +
> .../dts/aspeed/aspeed-bmc-facebook-ventura2.dts | 2888 ++++++++++++++++++++
> 2 files changed, 2889 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
> index 9adf9278dc94..6b96997629d4 100644
> --- a/arch/arm/boot/dts/aspeed/Makefile
> +++ b/arch/arm/boot/dts/aspeed/Makefile
> @@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
> aspeed-bmc-facebook-minipack.dtb \
> aspeed-bmc-facebook-santabarbara.dtb \
> aspeed-bmc-facebook-tiogapass.dtb \
> + aspeed-bmc-facebook-ventura2.dtb \
> aspeed-bmc-facebook-wedge40.dtb \
> aspeed-bmc-facebook-wedge100.dtb \
> aspeed-bmc-facebook-wedge400-data64.dtb \
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts
> new file mode 100644
> index 000000000000..9bf7d6e52e40
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts
> @@ -0,0 +1,2888 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2023 Facebook Inc.
> +/dts-v1/;
> +
> +#include "aspeed-g6.dtsi"
> +#include <dt-bindings/i2c/i2c.h>
> +#include <dt-bindings/gpio/aspeed-gpio.h>
> +
> +/ {
> + model = "Facebook Ventura2 RMC";
> + compatible = "facebook,ventura2-rmc", "aspeed,ast2600";
>
...
> +};
> +
...
> +&gpio1 {
> + gpio-line-names =
> + /*18A0-18A7*/ "","","","","","","","",
> + /*18B0-18B7*/ "","","","",
> + "FM_BOARD_BMC_REV_ID0","FM_BOARD_BMC_REV_ID1",
> + "FM_BOARD_BMC_REV_ID2","",
> + /*18C0-18C7*/ "SPI_BMC_BIOS_ROM_IRQ0_R_N","","","","","","","",
> + /*18D0-18D7*/ "","","","","","","","",
> + /*18E0-18E3*/ "FM_BMC_PROT_LS_EN","AC_PWR_BMC_BTN_R_N","","";
> +};
> +
> +&i2c0 {
> + status = "okay";
> +
> + i2c-mux@77 {
> + compatible = "nxp,pca9548";
> + reg = <0x77>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + i2c-mux-idle-disconnect;
> +
> + i2c0mux0ch0: i2c@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + };
> +
> + i2c0mux0ch1: i2c@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> + };
> +
> + i2c0mux0ch2: i2c@2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <2>;
> + };
> +
> + i2c0mux0ch3: i2c@3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <3>;
> + status = "okay";
> + };
> +
> + i2c0mux0ch4: i2c@4 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <4>;
> + status = "okay";
> + };
> +
> + i2c0mux0ch5: i2c@5 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <5>;
> + status = "okay";
> +
> + eeprom@56 {
> + compatible = "atmel,24c128";
> + reg = <0x56>;
> + };
> + };
> +
> + i2c0mux0ch6: i2c@6 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <6>;
> +
> + eeprom@56 {
> + compatible = "atmel,24c128";
> + reg = <0x56>;
> + };
> +
> + fan_io_expander0: gpio@20 {
> + compatible = "nxp,pca9555";
> + reg = <0x20>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +
> + fan_io_expander1: gpio@21 {
> + compatible = "nxp,pca9555";
> + reg = <0x21>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +
> + adc@1d {
> + compatible = "ti,adc128d818";
> + reg = <0x1d>;
> + ti,mode = /bits/ 8 <1>;
> + };
> +
> + adc@35 {
> + compatible = "maxim,max11617";
> + reg = <0x35>;
> + };
> + };
> +
> + i2c0mux0ch7: i2c@7 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <7>;
> +
> + fanctl0: fan-controller@20 {
> + compatible = "maxim,max31790";
> + reg = <0x20>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + channel@2 {
Can you make sure that you consistently use a blank line to separate
child nodes from each other and from properties in their parent?
Please fix throughout.
> + reg = <2>;
> + sensor-type = "TACH";
> + };
> + channel@5 {
> + reg = <5>;
> + sensor-type = "TACH";
> + };
> + };
> +
> + fanctl1: fan-controller@23 {
> + compatible = "nuvoton,nct7363";
> + reg = <0x23>;
> + #pwm-cells = <2>;
> +
> + fan-9 {
> + pwms = <&fanctl1 0 20000>;
> + tach-ch = /bits/ 8 <0x09>;
> + };
> +
> + fan-11 {
> + pwms = <&fanctl1 0 20000>;
> + tach-ch = /bits/ 8 <0x0B>;
> + };
> +
> + fan-10 {
> + pwms = <&fanctl1 4 20000>;
> + tach-ch = /bits/ 8 <0x0A>;
> + };
> +
> + fan-13 {
> + pwms = <&fanctl1 4 20000>;
> + tach-ch = /bits/ 8 <0x0D>;
> + };
> +
> + fan-15 {
> + pwms = <&fanctl1 6 20000>;
> + tach-ch = /bits/ 8 <0x0F>;
> + };
> +
> + fan-1 {
Can you please sort the fan nodes in ascending order?
> + pwms = <&fanctl1 6 20000>;
> + tach-ch = /bits/ 8 <0x01>;
> + };
> +
> + fan-0 {
> + pwms = <&fanctl1 10 20000>;
> + tach-ch = /bits/ 8 <0x00>;
> + };
> +
> + fan-3 {
> + pwms = <&fanctl1 10 20000>;
> + tach-ch = /bits/ 8 <0x03>;
> + };
> + };
> + };
> + };
> +};
>
...
> +
> + // Marvell 88E6393X EEPROM
Please try to be consistent with the comment style (prefer /* */).
> + eeprom@50 {
> + compatible = "atmel,24c64";
> + reg = <0x50>;
> + };
> +
> + rtc@51 {
> + compatible = "nxp,pcf8563";
> + reg = <0x51>;
> + };
> +};
> +
^ permalink raw reply
* [PATCH 2/2] riscv: dts: sophgo: Add Milk-V Duo 256M board support
From: Chen-Yu Yeh @ 2026-06-10 11:11 UTC (permalink / raw)
To: unicorn_wang, inochiama
Cc: Chen-Yu Yeh, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Han Gao, Nutty Liu, Longbin Li,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:SOPHGO DEVICETREES and DRIVERS,
open list:RISC-V ARCHITECTURE, open list
In-Reply-To: <20260610111136.1514155-1-chenyou910331@gmail.com>
The Milk-V Duo 256M is a small form factor development board based on
the Sophgo SG2002 SoC.
This patch adds basic device tree support for the board, including:
- UART console
- SD/MMC controller
- USB host
- Onboard blue status LED (connected to PWR_GPIO[2] / porte 2)
Tested on actual Milk-V Duo 256M hardware, verified boot to shell and
heartbeat LED functionality.
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
arch/riscv/boot/dts/sophgo/Makefile | 2 +
.../boot/dts/sophgo/sg2002-milkv-duo256m.dts | 119 ++++++++++++++++++
2 files changed, 121 insertions(+)
create mode 100644 arch/riscv/boot/dts/sophgo/sg2002-milkv-duo256m.dts
diff --git a/arch/riscv/boot/dts/sophgo/Makefile b/arch/riscv/boot/dts/sophgo/Makefile
index 6f65526d4193..e49c8233ae1f 100644
--- a/arch/riscv/boot/dts/sophgo/Makefile
+++ b/arch/riscv/boot/dts/sophgo/Makefile
@@ -2,7 +2,9 @@
dtb-$(CONFIG_ARCH_SOPHGO) += cv1800b-milkv-duo.dtb
dtb-$(CONFIG_ARCH_SOPHGO) += cv1812h-huashan-pi.dtb
dtb-$(CONFIG_ARCH_SOPHGO) += sg2002-licheerv-nano-b.dtb
+dtb-$(CONFIG_ARCH_SOPHGO) += sg2002-milkv-duo256m.dtb
dtb-$(CONFIG_ARCH_SOPHGO) += sg2042-milkv-pioneer.dtb
dtb-$(CONFIG_ARCH_SOPHGO) += sg2042-evb-v1.dtb
dtb-$(CONFIG_ARCH_SOPHGO) += sg2042-evb-v2.dtb
dtb-$(CONFIG_ARCH_SOPHGO) += sg2044-sophgo-srd3-10.dtb
+
diff --git a/arch/riscv/boot/dts/sophgo/sg2002-milkv-duo256m.dts b/arch/riscv/boot/dts/sophgo/sg2002-milkv-duo256m.dts
new file mode 100644
index 000000000000..882fba441396
--- /dev/null
+++ b/arch/riscv/boot/dts/sophgo/sg2002-milkv-duo256m.dts
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2023 Jisheng Zhang <jszhang@kernel.org>
+ */
+
+/dts-v1/;
+
+#include "sg2002.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ model = "Milk-V Duo 256M";
+ compatible = "milkv,duo256m", "sophgo,sg2002";
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ serial4 = &uart4;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-blue {
+ label = "milkv:blue:status";
+ gpios = <&porte 2 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ coprocessor_rtos: region@83f40000 {
+ reg = <0x83f40000 0xc0000>;
+ no-map;
+ };
+ };
+};
+
+&osc {
+ clock-frequency = <25000000>;
+};
+
+&pinctrl {
+ uart0_cfg: uart0-cfg {
+ uart0-pins {
+ pinmux = <PINMUX(PIN_UART0_TX, 0)>,
+ <PINMUX(PIN_UART0_RX, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+ };
+
+ sdhci0_cfg: sdhci0-cfg {
+ sdhci0-clk-pins {
+ pinmux = <PINMUX(PIN_SD0_CLK, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <16100>;
+ power-source = <3300>;
+ };
+
+ sdhci0-cmd-pins {
+ pinmux = <PINMUX(PIN_SD0_CMD, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+
+ sdhci0-data-pins {
+ pinmux = <PINMUX(PIN_SD0_D0, 0)>,
+ <PINMUX(PIN_SD0_D1, 0)>,
+ <PINMUX(PIN_SD0_D2, 0)>,
+ <PINMUX(PIN_SD0_D3, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+
+ sdhci0-cd-pins {
+ pinmux = <PINMUX(PIN_SD0_CD, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+ };
+};
+
+&sdhci0 {
+ pinctrl-0 = <&sdhci0_cfg>;
+ pinctrl-names = "default";
+ status = "okay";
+ bus-width = <4>;
+ no-1-8-v;
+ no-mmc;
+ no-sdio;
+ disable-wp;
+};
+
+&uart0 {
+ pinctrl-0 = <&uart0_cfg>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usb {
+ dr_mode = "host";
+ status = "okay";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: soc: sophgo: add Milk-V Duo 256M board
From: Chen-Yu Yeh @ 2026-06-10 11:11 UTC (permalink / raw)
To: unicorn_wang, inochiama
Cc: Chen-Yu Yeh, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Sverdlin, Han Gao, Chao Wei,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:SOPHGO DEVICETREES and DRIVERS, open list
Add compatible string for the Milk-V Duo 256M board.
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
Documentation/devicetree/bindings/soc/sophgo/sophgo.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/sophgo/sophgo.yaml b/Documentation/devicetree/bindings/soc/sophgo/sophgo.yaml
index 1c502618de51..fcb1d905da7d 100644
--- a/Documentation/devicetree/bindings/soc/sophgo/sophgo.yaml
+++ b/Documentation/devicetree/bindings/soc/sophgo/sophgo.yaml
@@ -31,6 +31,10 @@ properties:
- milkv,duo-module-01-evb
- const: milkv,duo-module-01
- const: sophgo,sg2000
+ - items:
+ - enum:
+ - milkv,duo256m
+ - const: sophgo,sg2002
- items:
- enum:
- sipeed,licheerv-nano-b
--
2.43.0
^ permalink raw reply related
* [PATCH 9/9] phy: qcom-mipi-csi2: accept PHY_QCOM_CSI2_MODE_DPHY phy-cell
From: Ramshouriesh @ 2026-06-10 11:09 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain, Bryan O'Donoghue,
Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy, Ramshouriesh
In-Reply-To: <20260610-a14-himax-hm1092-v1-0-0c9907da47ed@gmail.com>
qcom_csi2_phy_xlate() validates the phy-cell against the generic
PHY_TYPE_DPHY (10) instead of PHY_QCOM_CSI2_MODE_DPHY (0), so a correct
DPHY request from the camss DTSI is rejected with -EOPNOTSUPP and camss
probe fails with -95.
Include the CSI2 mode header and check the phy-cell against
PHY_QCOM_CSI2_MODE_DPHY.
Signed-off-by: Ramshouriesh <rshouriesh@gmail.com>
---
drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
index dfeff863a406..857c54cbaea6 100644
--- a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
+++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
@@ -3,6 +3,7 @@
* Copyright (c) 2025, Linaro Ltd.
*/
#include <dt-bindings/phy/phy.h>
+#include <dt-bindings/phy/phy-qcom-mipi-csi2.h>
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/err.h>
@@ -188,7 +189,7 @@ static struct phy *qcom_csi2_phy_xlate(struct device *dev,
{
struct mipi_csi2phy_device *csi2phy = dev_get_drvdata(dev);
- if (args->args[0] != PHY_TYPE_DPHY) {
+ if (args->args[0] != PHY_QCOM_CSI2_MODE_DPHY) {
dev_err(csi2phy->dev, "mode %d -EOPNOTSUPP\n", args->args[0]);
return ERR_PTR(-EOPNOTSUPP);
}
--
2.53.0
^ permalink raw reply related
* [PATCH 8/9] dt-bindings: phy: qcom: add MIPI CSI2 mode constants
From: Ramshouriesh @ 2026-06-10 11:09 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain, Bryan O'Donoghue,
Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy, Ramshouriesh
In-Reply-To: <20260610-a14-himax-hm1092-v1-0-0c9907da47ed@gmail.com>
The CSI2-PHY binding references <dt-bindings/phy/phy-qcom-mipi-csi2.h>
and consumers (the x1e80100/hamoa camss DTSI) select D-PHY mode with
PHY_QCOM_CSI2_MODE_DPHY, but the v8 CSI2-PHY series does not ship the
header, so any DT that includes it fails to build.
Add the header with the CSI2 mode constants and cover it in MAINTAINERS.
Signed-off-by: Ramshouriesh <rshouriesh@gmail.com>
---
MAINTAINERS | 1 +
include/dt-bindings/phy/phy-qcom-mipi-csi2.h | 15 +++++++++++++++
2 files changed, 16 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ece71732e6dd..a7ee9f0aaaa8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22280,6 +22280,7 @@ S: Maintained
F: Documentation/devicetree/bindings/phy/qcom,*-csi2-phy.yaml
F: drivers/phy/qualcomm/phy-qcom-mipi-csi2*.c
F: drivers/phy/qualcomm/phy-qcom-mipi-csi2*.h
+F: include/dt-bindings/phy/phy-qcom-mipi-csi2*
QUALCOMM NAND CONTROLLER DRIVER
M: Manivannan Sadhasivam <mani@kernel.org>
diff --git a/include/dt-bindings/phy/phy-qcom-mipi-csi2.h b/include/dt-bindings/phy/phy-qcom-mipi-csi2.h
new file mode 100644
index 000000000000..fa48fd75c58d
--- /dev/null
+++ b/include/dt-bindings/phy/phy-qcom-mipi-csi2.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+/*
+ * Qualcomm MIPI CSI2 PHY constants
+ *
+ * Copyright (C) 2026 Linaro Limited
+ */
+
+#ifndef __DT_BINDINGS_PHY_MIPI_CSI2__
+#define __DT_BINDINGS_PHY_MIPI_CSI2__
+
+#define PHY_QCOM_CSI2_MODE_DPHY 0
+#define PHY_QCOM_CSI2_MODE_CPHY 1
+#define PHY_QCOM_CSI2_MODE_SPLIT_DPHY 2
+
+#endif /* __DT_BINDINGS_PHY_MIPI_CSI2__ */
--
2.53.0
^ permalink raw reply related
* [PATCH 7/9] arm64: dts: qcom: hamoa: reorder csiphy power-domains for v8 CSI2-PHY
From: Ramshouriesh @ 2026-06-10 11:09 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain, Bryan O'Donoghue,
Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy, Ramshouriesh
In-Reply-To: <20260610-a14-himax-hm1092-v1-0-0c9907da47ed@gmail.com>
The v8 phy-qcom-mipi-csi2 binding mandates power-domain-names ordered
"mmcx", "mx" (MMCX first), and its driver reads each domain's required
performance state by index via dev_pm_opp_get_required_pstate(opp, i).
The v3-era camss DTSI listed them "mx", "mmcx" (MXC/MX first), which is
rejected by the v8 binding and, with the v8 driver's
devm_pm_domain_attach_list() + per-index OPP lookup, maps the wrong
pstate to the wrong rail.
Reorder all four csiphy nodes to <MMCX>, <MXC|MX> / "mmcx", "mx". The
second rail stays MXC for csiphy0/1/2 and MX for csiphy4 (the binding
explicitly allows "MXC or MXA" for the second domain); the opp-table
required-opps values are symmetric so they need no change.
Signed-off-by: Ramshouriesh <rshouriesh@gmail.com>
---
arch/arm64/boot/dts/qcom/hamoa.dtsi | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 4226db30e244..1200101d7bb7 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -5853,10 +5853,10 @@ csiphy0: phy@ace4000 {
interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
- power-domains = <&rpmhpd RPMHPD_MXC>,
- <&rpmhpd RPMHPD_MMCX>;
- power-domain-names = "mx",
- "mmcx";
+ power-domains = <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "mmcx",
+ "mx";
#phy-cells = <1>;
@@ -5876,10 +5876,10 @@ csiphy1: phy@ace6000 {
interrupts = <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>;
- power-domains = <&rpmhpd RPMHPD_MXC>,
- <&rpmhpd RPMHPD_MMCX>;
- power-domain-names = "mx",
- "mmcx";
+ power-domains = <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "mmcx",
+ "mx";
#phy-cells = <1>;
@@ -5899,10 +5899,10 @@ csiphy2: phy@ace8000 {
interrupts = <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>;
- power-domains = <&rpmhpd RPMHPD_MXC>,
- <&rpmhpd RPMHPD_MMCX>;
- power-domain-names = "mx",
- "mmcx";
+ power-domains = <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "mmcx",
+ "mx";
#phy-cells = <1>;
@@ -5922,10 +5922,10 @@ csiphy4: phy@acec000 {
interrupts = <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>;
- power-domains = <&rpmhpd RPMHPD_MX>,
- <&rpmhpd RPMHPD_MMCX>;
- power-domain-names = "mx",
- "mmcx";
+ power-domains = <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MX>;
+ power-domain-names = "mmcx",
+ "mx";
#phy-cells = <1>;
--
2.53.0
^ permalink raw reply related
* [PATCH 6/9] arm64: dts/media: qcom: keep PLL8 out of Purwa camss hot path
From: Ramshouriesh @ 2026-06-10 11:09 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain, Bryan O'Donoghue,
Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy, Ramshouriesh
In-Reply-To: <20260610-a14-himax-hm1092-v1-0-0c9907da47ed@gmail.com>
cam_cc_pll8 (defined in camcc-x1e80100.c) doesn't latch on Purwa
silicon. "Lucid PLL latch failed. Output may be unstable!" fires from
wait_for_pll() whenever something asks for a PLL8-sourced rate, and
the camera pipeline ends up dead with "Failed to start media
pipeline: -32" even after the qcom,x1p42100-camss compatible is in
place.
PLL8 sneaks into the streaming path via two RCG freq tables: the
slow_ahb RCG defaults to its 64 MHz entry (PLL8-sourced) when CSID
pulls it during csid_set_power, and vfe_lite picks its highest entry
(480 MHz, also PLL8) at streamon.
Fix this from the DT side:
* pin slow_ahb at 80 MHz via assigned-clock-rates in purwa.dtsi so
the RCG is reprogrammed to PLL0_OUT_EVEN at clk-init time and
never reaches PLL8;
* drop the 480 MHz entry from the Purwa vfe_lite clock_rate array
so the driver caps at 400 MHz (PLL0_OUT_ODD).
I went poking at the Qualcomm Windows BSP shipped for the UX3407QA to
see what rates the vendor side actually uses. The AeoB resource blob
at qccamplatform_ext8380/CAMP_{PERF,RES}_MTP.bin lists the camera
clocks Windows enables, and PLL8 isn't referenced once. For CCI in
particular Windows runs at 37.5 MHz off PLL0_OUT_EVEN, not the
30 MHz/PLL8 alternative the Linux driver happens to pick first.
Whether PLL8 is fused off, trust-zone-only, or just unwired on this
SoC I don't know, but treating it as unavailable matches what the
vendor does.
Signed-off-by: Ramshouriesh <rshouriesh@gmail.com>
---
arch/arm64/boot/dts/qcom/purwa.dtsi | 12 ++++++++++++
drivers/media/platform/qcom/camss/camss.c | 16 ++++++++--------
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/purwa.dtsi b/arch/arm64/boot/dts/qcom/purwa.dtsi
index cee72349da49..5e39355c38d4 100644
--- a/arch/arm64/boot/dts/qcom/purwa.dtsi
+++ b/arch/arm64/boot/dts/qcom/purwa.dtsi
@@ -409,3 +409,15 @@ &tsens3 {
&videocc {
compatible = "qcom,x1p42100-videocc";
};
+
+/*
+ * PLL8 in the camcc-x1e80100 driver fails to lock on Purwa silicon
+ * ("Lucid PLL latch failed"). Several RCGs default to PLL8 as parent
+ * (slow_ahb at 64 MHz, cci_0 at 30 MHz). Pin slow_ahb to the next-best
+ * PLL0-sourced rate (80 MHz) at clock-init time so enabling it does not
+ * try to bring PLL8 up. cci_0 already defaults to 19.2 MHz via TCXO.
+ */
+&camcc {
+ assigned-clocks = <&camcc CAM_CC_SLOW_AHB_CLK_SRC>;
+ assigned-clock-rates = <80000000>;
+};
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 5c9530d52bbd..ca43ff309b26 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -4437,8 +4437,8 @@ static const struct camss_subdev_resources vfe_res_x1e80100[] = {
{ 0 },
{ 0 },
{ 0 },
- { 266666667, 400000000, 480000000 },
- { 266666667, 400000000, 480000000 }, },
+ { 266666667, 400000000 },
+ { 266666667, 400000000 }, },
.reg = { "vfe_lite0" },
.interrupt = { "vfe_lite0" },
.vfe = {
@@ -4460,8 +4460,8 @@ static const struct camss_subdev_resources vfe_res_x1e80100[] = {
{ 0 },
{ 0 },
{ 0 },
- { 266666667, 400000000, 480000000 },
- { 266666667, 400000000, 480000000 }, },
+ { 266666667, 400000000 },
+ { 266666667, 400000000 }, },
.reg = { "vfe_lite1" },
.interrupt = { "vfe_lite1" },
.vfe = {
@@ -4574,8 +4574,8 @@ static const struct camss_subdev_resources vfe_res_x1p42100[] = {
{ 0 },
{ 0 },
{ 0 },
- { 266666667, 400000000, 480000000 },
- { 266666667, 400000000, 480000000 }, },
+ { 266666667, 400000000 },
+ { 266666667, 400000000 }, },
.reg = { "vfe_lite0" },
.interrupt = { "vfe_lite0" },
.vfe = {
@@ -4597,8 +4597,8 @@ static const struct camss_subdev_resources vfe_res_x1p42100[] = {
{ 0 },
{ 0 },
{ 0 },
- { 266666667, 400000000, 480000000 },
- { 266666667, 400000000, 480000000 }, },
+ { 266666667, 400000000 },
+ { 266666667, 400000000 }, },
.reg = { "vfe_lite1" },
.interrupt = { "vfe_lite1" },
.vfe = {
--
2.53.0
^ permalink raw reply related
* [PATCH 5/9] arm64: dts: qcom: x1-asus-zenbook-a14: add HM1092 IR camera and wire cameras to camss
From: Ramshouriesh @ 2026-06-10 11:09 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain, Bryan O'Donoghue,
Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy, Ramshouriesh
In-Reply-To: <20260610-a14-himax-hm1092-v1-0-0c9907da47ed@gmail.com>
Add the Himax HM1092 mono NIR (Windows-Hello IR) sensor on CSIPHY0,
together with its PM8550 IR illuminator and the pm8010 l4m/l7m camera
rails, and connect both sensors to the CAMSS input ports defined in
hamoa.dtsi.
On Purwa CAMSS exposes two CSIPHYs (0 and 4) and the camss input port
number selects the CSIPHY by index, so the board wiring is:
camss port@0 -> HM1092 (IR, 1 data lane, CSIPHY0)
camss port@1 -> OV02C10 (RGB, 2 data lanes, CSIPHY4)
Each CSIPHY node carries its sensor's D-PHY lane routing in its own
port@0 endpoint, per the qcom,x1e80100-csi2-phy binding: the PHY driver
parses data-lanes from that endpoint at probe time, and its
remote-endpoint must reference an available device for
fwnode_graph_get_endpoint_by_id() to return it, hence each csiphy
port@0 points at its sensor. The CAMSS-to-CSIPHY association itself
comes from the phys/phy-names properties inherited from hamoa.dtsi.
The IR illuminator is a PM8550 flash LED (channel 4) referenced through
the generic "leds" consumer property from video-interface-devices.yaml.
The HM1092 driver strobes it while streaming (700 mA, re-fired within
the 1.28 s hardware safety timeout) so the scene stays lit for IR
face-unlock capture.
Signed-off-by: Ramshouriesh <rshouriesh@gmail.com>
---
arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi | 140 ++++++++++++++++++++--
1 file changed, 129 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi b/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
index 388737eaa624..ab8f231cad8d 100644
--- a/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
@@ -8,7 +8,6 @@
#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/leds/common.h>
-#include <dt-bindings/phy/phy.h>
#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
@@ -815,6 +814,20 @@ vreg_l3m_1p8: ldo3 {
regulator-max-microvolt = <1800000>;
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
};
+
+ vreg_l4m_1p8: ldo4 {
+ regulator-name = "vreg_l4m_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7m_2p9: ldo7 {
+ regulator-name = "vreg_l7m_2p9";
+ regulator-min-microvolt = <2912000>;
+ regulator-max-microvolt = <2912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
};
};
@@ -824,14 +837,19 @@ &camss {
ports {
/*
* port0 => csiphy0
- * port1 => csiphy1
- * port2 => csiphy2
- * port3 => csiphy4
+ * port1 => csiphy4
*/
- port@3 {
- csiphy4_ep: endpoint@4 {
- reg = <4>;
- clock-lanes = <7>;
+ port@0 {
+ camss_csiphy0_inep: endpoint@0 {
+ reg = <0>;
+ data-lanes = <0>;
+ remote-endpoint = <&hm1092_ep>;
+ };
+ };
+
+ port@1 {
+ camss_csiphy4_inep: endpoint@0 {
+ reg = <0>;
data-lanes = <0 1>;
remote-endpoint = <&ov02c10_ep>;
};
@@ -869,18 +887,102 @@ port {
ov02c10_ep: endpoint {
data-lanes = <1 2>;
link-frequencies = /bits/ 64 <400000000>;
- remote-endpoint = <&csiphy4_ep>;
+ remote-endpoint = <&camss_csiphy4_inep>;
};
};
};
};
&csiphy4 {
- vdda-0p8-supply = <&vreg_l2c_0p8>;
+ vdda-0p9-supply = <&vreg_l2c_0p8>;
+ vdda-1p2-supply = <&vreg_l1c_1p2>;
+
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Sensor input: D-PHY lane routing for the OV02C10 */
+ port@0 {
+ reg = <0>;
+ endpoint {
+ data-lanes = <0 1>;
+ remote-endpoint = <&ov02c10_ep>;
+ };
+ };
+ };
+};
+
+&cci0 {
+ status = "okay";
+};
+
+&cci0_i2c0 {
+ /* Himax HM1092 mono NIR sensor (Windows-Hello IR camera) on CSIPHY0 */
+ camera@24 {
+ compatible = "himax,hm1092";
+ reg = <0x24>;
+
+ reset-gpios = <&tlmm 109 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&cam_ir_default>;
+ pinctrl-names = "default";
+
+ clocks = <&camcc CAM_CC_MCLK0_CLK>;
+ assigned-clocks = <&camcc CAM_CC_MCLK0_CLK>;
+ assigned-clock-rates = <24000000>;
+
+ orientation = <0>;
+
+ /* PM8550 IR illuminator, pulsed by the driver while streaming */
+ leds = <&ir_flash>;
+
+ avdd-supply = <&vreg_l7m_2p9>;
+ dvdd-supply = <&vreg_l7m_2p9>;
+ dovdd-supply = <&vreg_l4m_1p8>;
+
+ port {
+ hm1092_ep: endpoint {
+ data-lanes = <1>;
+ link-frequencies = /bits/ 64 <400000000>;
+ remote-endpoint = <&camss_csiphy0_inep>;
+ };
+ };
+ };
+};
+
+&csiphy0 {
+ vdda-0p9-supply = <&vreg_l2c_0p8>;
vdda-1p2-supply = <&vreg_l1c_1p2>;
- phy-type = <PHY_TYPE_DPHY>;
status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Sensor input: D-PHY lane routing for the HM1092 */
+ port@0 {
+ reg = <0>;
+ endpoint {
+ data-lanes = <0>;
+ remote-endpoint = <&hm1092_ep>;
+ };
+ };
+ };
+};
+
+&pm8550_flash {
+ status = "okay";
+
+ ir_flash: led-0 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_IR>;
+ led-sources = <4>;
+ led-max-microamp = <180000>;
+ flash-max-microamp = <700000>;
+ flash-max-timeout-us = <1280000>;
+ };
};
&i2c0 {
@@ -1384,6 +1486,22 @@ reset-n-pins {
};
};
+ cam_ir_default: cam-ir-default-state {
+ mclk-pins {
+ pins = "gpio96";
+ function = "cam_mclk";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ reset-n-pins {
+ pins = "gpio109";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
edp_reg_en: edp-reg-en-state {
pins = "gpio70";
function = "gpio";
--
2.53.0
^ permalink raw reply related
* [PATCH 4/9] MAINTAINERS: add entry for the Himax HM1092 sensor driver
From: Ramshouriesh @ 2026-06-10 11:09 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain, Bryan O'Donoghue,
Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy, Ramshouriesh
In-Reply-To: <20260610-a14-himax-hm1092-v1-0-0c9907da47ed@gmail.com>
Add a MAINTAINERS entry covering the Himax HM1092 NIR sensor driver and
its DT binding.
Signed-off-by: Ramshouriesh <rshouriesh@gmail.com>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index dadc54fe2bc8..ece71732e6dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11643,6 +11643,14 @@ L: linux-kernel@vger.kernel.org
S: Maintained
F: drivers/misc/hisi_hikey_usb.c
+HIMAX HM1092 SENSOR DRIVER
+M: Ramshouriesh <rshouriesh@gmail.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/himax,hm1092.yaml
+F: drivers/media/i2c/hm1092.c
+F: drivers/media/i2c/hm1092_regs.h
+
HIMAX HX83112B TOUCHSCREEN SUPPORT
M: Job Noorman <job@noorman.info>
L: linux-input@vger.kernel.org
--
2.53.0
^ permalink raw reply related
* [PATCH 3/9] media: i2c: hm1092: add Himax HM1092 mono NIR sensor driver
From: Ramshouriesh @ 2026-06-10 11:09 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain, Bryan O'Donoghue,
Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy, Ramshouriesh
In-Reply-To: <20260610-a14-himax-hm1092-v1-0-0c9907da47ed@gmail.com>
Add a v4l2 subdev driver for the Himax HM1092 monochrome near-IR sensor,
used as the Windows-Hello IR camera on the ASUS Zenbook A14.
The driver also drives the IR illuminator (a PM8550 flash LED referenced
through the generic "leds" property): while streaming it strobes the
illuminator at ~10 Hz, lighting the capture while keeping the average IR
LED power down.
Signed-off-by: Ramshouriesh <rshouriesh@gmail.com>
---
drivers/media/i2c/Kconfig | 14 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/hm1092.c | 685 ++++++++++++++++++++++++++++++++++++++++
drivers/media/i2c/hm1092_regs.h | 223 +++++++++++++
4 files changed, 923 insertions(+)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 5d173e0ecf42..8ee3ee15e9df 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -137,6 +137,20 @@ config VIDEO_HI847
To compile this driver as a module, choose M here: the
module will be called hi847.
+config VIDEO_HM1092
+ tristate "Himax HM1092 sensor support"
+ select V4L2_CCI_I2C
+ help
+ This is a Video4Linux2 sensor driver for the Himax
+ HM1092 1MP mono IR camera used for face authentication
+ on Snapdragon X laptops (ASUS Zenbook A14 etc.).
+
+ Register tables were reverse-engineered from the Qualcomm
+ Chromatix sensor module shipped in the Windows BSP.
+
+ To compile this driver as a module, choose M here: the
+ module will be called hm1092.
+
config VIDEO_IMX111
tristate "Sony IMX111 sensor support"
select V4L2_CCI_I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index e45359efe0e4..6507c173d0fa 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_VIDEO_GC2145) += gc2145.o
obj-$(CONFIG_VIDEO_HI556) += hi556.o
obj-$(CONFIG_VIDEO_HI846) += hi846.o
obj-$(CONFIG_VIDEO_HI847) += hi847.o
+obj-$(CONFIG_VIDEO_HM1092) += hm1092.o
obj-$(CONFIG_VIDEO_I2C) += video-i2c.o
obj-$(CONFIG_VIDEO_IMX111) += imx111.o
obj-$(CONFIG_VIDEO_IMX208) += imx208.o
diff --git a/drivers/media/i2c/hm1092.c b/drivers/media/i2c/hm1092.c
new file mode 100644
index 000000000000..90968ee29d81
--- /dev/null
+++ b/drivers/media/i2c/hm1092.c
@@ -0,0 +1,685 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Himax HM1092 image sensor driver draft.
+ *
+ * Register tables were extracted from Qualcomm Chromatix sensor module
+ * com.qti.sensormodule.hm1092.bin. Keep hm1092_regs.h next to this file, or
+ * fold the generated tables into this source before upstream submission.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/led-class-flash.h>
+#include <linux/leds.h>
+#include <linux/module.h>
+#include <linux/pm_runtime.h>
+#include <linux/regulator/consumer.h>
+#include <linux/workqueue.h>
+#include <media/v4l2-cci.h>
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-fwnode.h>
+
+#include "hm1092_regs.h"
+
+#define HM1092_LINK_FREQ_400MHZ 400000000ULL
+#define HM1092_MCLK 24000000
+#define HM1092_BITS_PER_SAMPLE 10
+
+#define HM1092_REG_STREAM CCI_REG8(0x0100)
+
+#define HM1092_FLASH_TIMEOUT_US 50000 /* 0.05 s on per pulse */
+#define HM1092_FLASH_REFIRE_MS 100 /* 0.1 s period -> 10 Hz blink */
+
+struct hm1092_mode {
+ u32 width;
+ u32 height;
+ u32 hts;
+ u32 vts;
+};
+
+static const struct hm1092_mode hm1092_mode_560x360 = {
+ .width = 560,
+ .height = 360,
+ .hts = 0x0650,
+ .vts = 0x02ee,
+};
+
+static const char * const hm1092_supply_names[] = {
+ "dovdd",
+ "avdd",
+ "dvdd",
+};
+
+static const char * const hm1092_test_pattern_menu[] = {
+ "Disabled",
+ "Mode 1",
+ "Mode 2",
+ "Mode 3",
+ "Mode 4",
+};
+
+static const s64 hm1092_link_freq_menu[] = {
+ HM1092_LINK_FREQ_400MHZ,
+};
+
+struct hm1092 {
+ struct device *dev;
+ struct v4l2_subdev sd;
+ struct media_pad pad;
+ struct v4l2_ctrl_handler ctrl_handler;
+ struct regmap *regmap;
+ struct clk *img_clk;
+ struct gpio_desc *reset;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(hm1092_supply_names)];
+ struct v4l2_ctrl *link_freq;
+ struct v4l2_ctrl *pixel_rate;
+ struct v4l2_ctrl *hblank;
+ struct v4l2_ctrl *vblank;
+ u8 mipi_lanes;
+
+ /* Optional IR illuminator driven while streaming (see flash notes). */
+ struct led_classdev_flash *flash;
+ struct delayed_work flash_work;
+};
+
+/*
+ * (Re)arm and fire the flash at full current. The qcom flash controller does an
+ * internal disable+enable on each strobe and the hardware safety-timeout turns
+ * the LED off on its own, so brightness/timeout must be programmed every time or
+ * the re-fire is a no-op. Re-firing well within the timeout keeps the LED lit
+ * continuously and near its (slightly declining) peak brightness.
+ */
+static void hm1092_flash_fire(struct hm1092 *hm1092)
+{
+ struct led_classdev_flash *flash = hm1092->flash;
+
+ /*
+ * Release the controller's flash-current accounting first (a bare
+ * re-strobe is treated as "current still in use" and re-fires at 0 mA),
+ * then re-arm at full current and strobe.
+ */
+ led_set_flash_strobe(flash, false);
+ led_set_flash_brightness(flash, flash->brightness.max);
+ led_set_flash_timeout(flash, HM1092_FLASH_TIMEOUT_US);
+ led_set_flash_strobe(flash, true);
+}
+
+static void hm1092_flash_enable(struct hm1092 *hm1092)
+{
+ if (!hm1092->flash)
+ return;
+
+ hm1092_flash_fire(hm1092);
+ schedule_delayed_work(&hm1092->flash_work,
+ msecs_to_jiffies(HM1092_FLASH_REFIRE_MS));
+}
+
+static void hm1092_flash_disable(struct hm1092 *hm1092)
+{
+ if (!hm1092->flash)
+ return;
+
+ cancel_delayed_work_sync(&hm1092->flash_work);
+ led_set_flash_strobe(hm1092->flash, false);
+}
+
+static void hm1092_flash_work(struct work_struct *work)
+{
+ struct hm1092 *hm1092 =
+ container_of(to_delayed_work(work), struct hm1092, flash_work);
+
+ hm1092_flash_fire(hm1092);
+ schedule_delayed_work(&hm1092->flash_work,
+ msecs_to_jiffies(HM1092_FLASH_REFIRE_MS));
+}
+
+static inline struct hm1092 *to_hm1092(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct hm1092, sd);
+}
+
+static int hm1092_write_regs(struct hm1092 *hm1092,
+ const struct hm1092_reg *regs, unsigned int len)
+{
+ int ret = 0;
+ unsigned int i;
+
+ for (i = 0; i < len; i++) {
+ cci_write(hm1092->regmap, CCI_REG8(regs[i].address),
+ regs[i].val, &ret);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int hm1092_set_test_pattern(struct hm1092 *hm1092, int pattern)
+{
+ switch (pattern) {
+ case 0:
+ return hm1092_write_regs(hm1092, hm1092_test_pattern_mode0,
+ ARRAY_SIZE(hm1092_test_pattern_mode0));
+ case 1:
+ return hm1092_write_regs(hm1092, hm1092_test_pattern_mode1,
+ ARRAY_SIZE(hm1092_test_pattern_mode1));
+ case 2:
+ return hm1092_write_regs(hm1092, hm1092_test_pattern_mode2,
+ ARRAY_SIZE(hm1092_test_pattern_mode2));
+ case 3:
+ return hm1092_write_regs(hm1092, hm1092_test_pattern_mode3,
+ ARRAY_SIZE(hm1092_test_pattern_mode3));
+ case 4:
+ return hm1092_write_regs(hm1092, hm1092_test_pattern_mode4,
+ ARRAY_SIZE(hm1092_test_pattern_mode4));
+ default:
+ return -EINVAL;
+ }
+}
+
+static int hm1092_set_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct hm1092 *hm1092 = container_of(ctrl->handler, struct hm1092,
+ ctrl_handler);
+ int ret = 0;
+
+ if (!pm_runtime_get_if_in_use(hm1092->dev))
+ return 0;
+
+ switch (ctrl->id) {
+ case V4L2_CID_TEST_PATTERN:
+ ret = hm1092_set_test_pattern(hm1092, ctrl->val);
+ break;
+ case V4L2_CID_ANALOGUE_GAIN:
+ case V4L2_CID_EXPOSURE:
+ /* TODO: write to the sensor's exposure/gain registers once
+ * we know which Chromatix middle*Addr fields point at them.
+ */
+ ret = 0;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ pm_runtime_put(hm1092->dev);
+
+ return ret;
+}
+
+static const struct v4l2_ctrl_ops hm1092_ctrl_ops = {
+ .s_ctrl = hm1092_set_ctrl,
+};
+
+static int hm1092_init_controls(struct hm1092 *hm1092)
+{
+ struct v4l2_ctrl_handler *ctrl_hdlr = &hm1092->ctrl_handler;
+ const struct hm1092_mode *mode = &hm1092_mode_560x360;
+ struct v4l2_fwnode_device_properties props;
+ s64 hblank, pixel_rate;
+ int ret;
+
+ v4l2_ctrl_handler_init(ctrl_hdlr, 6);
+
+ hm1092->link_freq = v4l2_ctrl_new_int_menu(ctrl_hdlr,
+ &hm1092_ctrl_ops,
+ V4L2_CID_LINK_FREQ,
+ 0, 0,
+ hm1092_link_freq_menu);
+ if (hm1092->link_freq)
+ hm1092->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
+
+ pixel_rate = div_u64(HM1092_LINK_FREQ_400MHZ * 2 * hm1092->mipi_lanes,
+ HM1092_BITS_PER_SAMPLE);
+ hm1092->pixel_rate = v4l2_ctrl_new_std(ctrl_hdlr, &hm1092_ctrl_ops,
+ V4L2_CID_PIXEL_RATE, 0,
+ pixel_rate, 1, pixel_rate);
+
+ hblank = mode->hts - mode->width;
+ hm1092->hblank = v4l2_ctrl_new_std(ctrl_hdlr, &hm1092_ctrl_ops,
+ V4L2_CID_HBLANK, hblank, hblank, 1,
+ hblank);
+ if (hm1092->hblank)
+ hm1092->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
+
+ hm1092->vblank = v4l2_ctrl_new_std(ctrl_hdlr, &hm1092_ctrl_ops,
+ V4L2_CID_VBLANK,
+ mode->vts - mode->height,
+ 0xffff - mode->height, 1,
+ mode->vts - mode->height);
+ if (hm1092->vblank)
+ hm1092->vblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
+
+ /* Mandatory controls for libcamera. Conservative defaults until we
+ * RE the exposure/gain register address layout from the Chromatix
+ * sensormodule (middleCoarseIntgTimeAddr / shortGlobalGainAddr).
+ */
+ v4l2_ctrl_new_std(ctrl_hdlr, &hm1092_ctrl_ops, V4L2_CID_ANALOGUE_GAIN,
+ 0x10, 0xff, 1, 0x10);
+ v4l2_ctrl_new_std(ctrl_hdlr, &hm1092_ctrl_ops, V4L2_CID_EXPOSURE,
+ 1, mode->vts - 4, 1, mode->vts - 4);
+
+ v4l2_ctrl_new_std_menu_items(ctrl_hdlr, &hm1092_ctrl_ops,
+ V4L2_CID_TEST_PATTERN,
+ ARRAY_SIZE(hm1092_test_pattern_menu) - 1,
+ 0, 0, hm1092_test_pattern_menu);
+
+ ret = v4l2_fwnode_device_parse(hm1092->dev, &props);
+ if (ret)
+ return ret;
+
+ v4l2_ctrl_new_fwnode_properties(ctrl_hdlr, &hm1092_ctrl_ops, &props);
+
+ if (ctrl_hdlr->error)
+ return ctrl_hdlr->error;
+
+ hm1092->sd.ctrl_handler = ctrl_hdlr;
+
+ return 0;
+}
+
+static void hm1092_update_pad_format(struct v4l2_mbus_framefmt *fmt)
+{
+ fmt->width = hm1092_mode_560x360.width;
+ fmt->height = hm1092_mode_560x360.height;
+ fmt->code = MEDIA_BUS_FMT_Y10_1X10;
+ fmt->field = V4L2_FIELD_NONE;
+}
+
+static int hm1092_enable_streams(struct v4l2_subdev *sd,
+ struct v4l2_subdev_state *state,
+ u32 pad, u64 streams_mask)
+{
+ struct hm1092 *hm1092 = to_hm1092(sd);
+ int ret;
+
+ ret = pm_runtime_resume_and_get(hm1092->dev);
+ if (ret)
+ return ret;
+
+ ret = hm1092_write_regs(hm1092, hm1092_init_regs,
+ ARRAY_SIZE(hm1092_init_regs));
+ if (ret) {
+ dev_err(hm1092->dev, "failed to write init registers\n");
+ goto out;
+ }
+
+ ret = __v4l2_ctrl_handler_setup(hm1092->sd.ctrl_handler);
+ if (ret)
+ goto out;
+
+ ret = hm1092_write_regs(hm1092, hm1092_start_streaming,
+ ARRAY_SIZE(hm1092_start_streaming));
+ if (ret)
+ dev_err(hm1092->dev, "failed to start streaming\n");
+ else
+ hm1092_flash_enable(hm1092);
+
+out:
+ if (ret)
+ pm_runtime_put(hm1092->dev);
+
+ return ret;
+}
+
+static int hm1092_disable_streams(struct v4l2_subdev *sd,
+ struct v4l2_subdev_state *state,
+ u32 pad, u64 streams_mask)
+{
+ struct hm1092 *hm1092 = to_hm1092(sd);
+ int ret = 0;
+
+ hm1092_flash_disable(hm1092);
+ cci_write(hm1092->regmap, HM1092_REG_STREAM, 0, &ret);
+ pm_runtime_put(hm1092->dev);
+
+ return ret;
+}
+
+static int hm1092_set_format(struct v4l2_subdev *sd,
+ struct v4l2_subdev_state *state,
+ struct v4l2_subdev_format *fmt)
+{
+ hm1092_update_pad_format(&fmt->format);
+ *v4l2_subdev_state_get_format(state, fmt->pad) = fmt->format;
+
+ return 0;
+}
+
+static int hm1092_enum_mbus_code(struct v4l2_subdev *sd,
+ struct v4l2_subdev_state *state,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ if (code->index)
+ return -EINVAL;
+
+ code->code = MEDIA_BUS_FMT_Y10_1X10;
+
+ return 0;
+}
+
+static int hm1092_enum_frame_size(struct v4l2_subdev *sd,
+ struct v4l2_subdev_state *state,
+ struct v4l2_subdev_frame_size_enum *fse)
+{
+ if (fse->index)
+ return -EINVAL;
+
+ if (fse->code != MEDIA_BUS_FMT_Y10_1X10)
+ return -EINVAL;
+
+ fse->min_width = hm1092_mode_560x360.width;
+ fse->max_width = hm1092_mode_560x360.width;
+ fse->min_height = hm1092_mode_560x360.height;
+ fse->max_height = hm1092_mode_560x360.height;
+
+ return 0;
+}
+
+static int hm1092_init_state(struct v4l2_subdev *sd,
+ struct v4l2_subdev_state *state)
+{
+ hm1092_update_pad_format(v4l2_subdev_state_get_format(state, 0));
+
+ return 0;
+}
+
+static const struct v4l2_subdev_video_ops hm1092_video_ops = {
+ .s_stream = v4l2_subdev_s_stream_helper,
+};
+
+static const struct v4l2_subdev_pad_ops hm1092_pad_ops = {
+ .set_fmt = hm1092_set_format,
+ .get_fmt = v4l2_subdev_get_fmt,
+ .enum_mbus_code = hm1092_enum_mbus_code,
+ .enum_frame_size = hm1092_enum_frame_size,
+ .enable_streams = hm1092_enable_streams,
+ .disable_streams = hm1092_disable_streams,
+};
+
+static const struct v4l2_subdev_ops hm1092_subdev_ops = {
+ .video = &hm1092_video_ops,
+ .pad = &hm1092_pad_ops,
+};
+
+static const struct media_entity_operations hm1092_entity_ops = {
+ .link_validate = v4l2_subdev_link_validate,
+};
+
+static const struct v4l2_subdev_internal_ops hm1092_internal_ops = {
+ .init_state = hm1092_init_state,
+};
+
+static int hm1092_check_hwcfg(struct hm1092 *hm1092)
+{
+ struct v4l2_fwnode_endpoint bus_cfg = {
+ .bus_type = V4L2_MBUS_CSI2_DPHY,
+ };
+ struct device *dev = hm1092->dev;
+ struct fwnode_handle *ep, *fwnode = dev_fwnode(dev);
+ unsigned long link_freq_bitmap;
+ int ret;
+
+ ep = fwnode_graph_get_endpoint_by_id(fwnode, 0, 0, 0);
+ if (!ep)
+ return dev_err_probe(dev, -EPROBE_DEFER,
+ "waiting for fwnode graph endpoint\n");
+
+ ret = v4l2_fwnode_endpoint_alloc_parse(ep, &bus_cfg);
+ fwnode_handle_put(ep);
+ if (ret)
+ return dev_err_probe(dev, ret, "parsing endpoint failed\n");
+
+ ret = v4l2_link_freq_to_bitmap(dev, bus_cfg.link_frequencies,
+ bus_cfg.nr_of_link_frequencies,
+ hm1092_link_freq_menu,
+ ARRAY_SIZE(hm1092_link_freq_menu),
+ &link_freq_bitmap);
+ if (ret)
+ goto out;
+
+ if (bus_cfg.bus.mipi_csi2.num_data_lanes != 1 &&
+ bus_cfg.bus.mipi_csi2.num_data_lanes != 2) {
+ ret = dev_err_probe(dev, -EINVAL,
+ "unsupported CSI2 data lanes: %u\n",
+ bus_cfg.bus.mipi_csi2.num_data_lanes);
+ goto out;
+ }
+
+ hm1092->mipi_lanes = bus_cfg.bus.mipi_csi2.num_data_lanes;
+
+out:
+ v4l2_fwnode_endpoint_free(&bus_cfg);
+ return ret;
+}
+
+static int hm1092_get_pm_resources(struct hm1092 *hm1092)
+{
+ unsigned int i;
+
+ hm1092->reset = devm_gpiod_get_optional(hm1092->dev, "reset",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(hm1092->reset))
+ return dev_err_probe(hm1092->dev, PTR_ERR(hm1092->reset),
+ "failed to get reset gpio\n");
+
+ for (i = 0; i < ARRAY_SIZE(hm1092_supply_names); i++)
+ hm1092->supplies[i].supply = hm1092_supply_names[i];
+
+ return devm_regulator_bulk_get(hm1092->dev,
+ ARRAY_SIZE(hm1092_supply_names),
+ hm1092->supplies);
+}
+
+static int hm1092_power_off(struct device *dev)
+{
+ struct v4l2_subdev *sd = dev_get_drvdata(dev);
+ struct hm1092 *hm1092 = to_hm1092(sd);
+
+ gpiod_set_value_cansleep(hm1092->reset, 1);
+ regulator_bulk_disable(ARRAY_SIZE(hm1092_supply_names),
+ hm1092->supplies);
+ clk_disable_unprepare(hm1092->img_clk);
+
+ return 0;
+}
+
+static int hm1092_power_on(struct device *dev)
+{
+ struct v4l2_subdev *sd = dev_get_drvdata(dev);
+ struct hm1092 *hm1092 = to_hm1092(sd);
+ int ret;
+
+ /*
+ * Sequence reverse-engineered from the Chromatix AeoB powerSetting:
+ * 1. enable all rails (~1 ms ramp per supply)
+ * 2. hold reset asserted
+ * 3. start MCLK and let the sensor clock for ~1 ms
+ * 4. release reset and wait 18 ms for the sensor to come up
+ */
+ ret = regulator_bulk_enable(ARRAY_SIZE(hm1092_supply_names),
+ hm1092->supplies);
+ if (ret)
+ return ret;
+ usleep_range(3000, 3500);
+
+ if (hm1092->reset)
+ gpiod_set_value_cansleep(hm1092->reset, 1);
+
+ ret = clk_prepare_enable(hm1092->img_clk);
+ if (ret) {
+ regulator_bulk_disable(ARRAY_SIZE(hm1092_supply_names),
+ hm1092->supplies);
+ return ret;
+ }
+ usleep_range(1000, 1200);
+
+ if (hm1092->reset)
+ gpiod_set_value_cansleep(hm1092->reset, 0);
+ usleep_range(18000, 19000);
+
+ return 0;
+}
+
+static void hm1092_remove(struct i2c_client *client)
+{
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct hm1092 *hm1092 = to_hm1092(sd);
+
+ v4l2_async_unregister_subdev(sd);
+ v4l2_subdev_cleanup(sd);
+ media_entity_cleanup(&sd->entity);
+ v4l2_ctrl_handler_free(sd->ctrl_handler);
+ pm_runtime_disable(hm1092->dev);
+ if (!pm_runtime_status_suspended(hm1092->dev)) {
+ hm1092_power_off(hm1092->dev);
+ pm_runtime_set_suspended(hm1092->dev);
+ }
+}
+
+/* Optional: grab the IR illuminator flash LED referenced by the "leds" phandle. */
+static int hm1092_get_flash(struct hm1092 *hm1092)
+{
+ struct led_classdev *cdev;
+
+ cdev = devm_of_led_get_optional(hm1092->dev, 0);
+ if (IS_ERR(cdev))
+ return dev_err_probe(hm1092->dev, PTR_ERR(cdev),
+ "failed to get IR illuminator LED\n");
+ if (!cdev)
+ return 0; /* no illuminator wired; capture still works */
+
+ if (!(cdev->flags & LED_DEV_CAP_FLASH)) {
+ dev_warn(hm1092->dev,
+ "'leds' phandle is not a flash LED; IR illuminator disabled\n");
+ return 0;
+ }
+
+ hm1092->flash = lcdev_to_flcdev(cdev);
+ INIT_DELAYED_WORK(&hm1092->flash_work, hm1092_flash_work);
+ dev_dbg(hm1092->dev, "IR illuminator flash linked (max %u uA)\n",
+ hm1092->flash->brightness.max);
+ return 0;
+}
+
+static int hm1092_probe(struct i2c_client *client)
+{
+ struct hm1092 *hm1092;
+ unsigned long freq;
+ int ret;
+
+ hm1092 = devm_kzalloc(&client->dev, sizeof(*hm1092), GFP_KERNEL);
+ if (!hm1092)
+ return -ENOMEM;
+
+ hm1092->dev = &client->dev;
+
+ ret = hm1092_get_flash(hm1092);
+ if (ret)
+ return ret;
+
+ hm1092->img_clk = devm_v4l2_sensor_clk_get(hm1092->dev, NULL);
+ if (IS_ERR(hm1092->img_clk))
+ return dev_err_probe(hm1092->dev, PTR_ERR(hm1092->img_clk),
+ "failed to get imaging clock\n");
+
+ freq = clk_get_rate(hm1092->img_clk);
+ if (freq != HM1092_MCLK)
+ return dev_err_probe(hm1092->dev, -EINVAL,
+ "external clock %lu is not supported\n",
+ freq);
+
+ v4l2_i2c_subdev_init(&hm1092->sd, client, &hm1092_subdev_ops);
+
+ ret = hm1092_check_hwcfg(hm1092);
+ if (ret)
+ return ret;
+
+ ret = hm1092_get_pm_resources(hm1092);
+ if (ret)
+ return ret;
+
+ hm1092->regmap = devm_cci_regmap_init_i2c(client, 16);
+ if (IS_ERR(hm1092->regmap))
+ return PTR_ERR(hm1092->regmap);
+
+ ret = hm1092_power_on(hm1092->dev);
+ if (ret)
+ return dev_err_probe(hm1092->dev, ret, "failed to power on\n");
+
+ ret = hm1092_init_controls(hm1092);
+ if (ret)
+ goto err_power_off;
+
+ hm1092->sd.internal_ops = &hm1092_internal_ops;
+ hm1092->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+ hm1092->sd.entity.ops = &hm1092_entity_ops;
+ hm1092->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+ hm1092->pad.flags = MEDIA_PAD_FL_SOURCE;
+ ret = media_entity_pads_init(&hm1092->sd.entity, 1, &hm1092->pad);
+ if (ret)
+ goto err_ctrls;
+
+ hm1092->sd.state_lock = hm1092->ctrl_handler.lock;
+ ret = v4l2_subdev_init_finalize(&hm1092->sd);
+ if (ret)
+ goto err_entity;
+
+ pm_runtime_set_active(hm1092->dev);
+ pm_runtime_enable(hm1092->dev);
+
+ /*
+ * The HM1092 has no async sub-devices: no privacy LED, no lens, and
+ * its IR illuminator is a directly-driven led-class-flash (see
+ * hm1092_get_flash()), not a v4l2-flash subdev. Register the plain
+ * subdev rather than v4l2_async_register_subdev_sensor(), whose
+ * automatic privacy-LED lookup would otherwise reject the "leds"
+ * phandle that points at the illuminator.
+ */
+ ret = v4l2_async_register_subdev(&hm1092->sd);
+ if (ret)
+ goto err_subdev;
+
+ pm_runtime_idle(hm1092->dev);
+ return 0;
+
+err_subdev:
+ pm_runtime_disable(hm1092->dev);
+ pm_runtime_set_suspended(hm1092->dev);
+ v4l2_subdev_cleanup(&hm1092->sd);
+err_entity:
+ media_entity_cleanup(&hm1092->sd.entity);
+err_ctrls:
+ v4l2_ctrl_handler_free(hm1092->sd.ctrl_handler);
+err_power_off:
+ hm1092_power_off(hm1092->dev);
+
+ return ret;
+}
+
+static DEFINE_RUNTIME_DEV_PM_OPS(hm1092_pm_ops, hm1092_power_off,
+ hm1092_power_on, NULL);
+
+static const struct of_device_id hm1092_of_match[] = {
+ { .compatible = "himax,hm1092" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, hm1092_of_match);
+
+static struct i2c_driver hm1092_i2c_driver = {
+ .driver = {
+ .name = "hm1092",
+ .pm = pm_sleep_ptr(&hm1092_pm_ops),
+ .of_match_table = hm1092_of_match,
+ },
+ .probe = hm1092_probe,
+ .remove = hm1092_remove,
+};
+
+module_i2c_driver(hm1092_i2c_driver);
+
+MODULE_DESCRIPTION("Himax HM1092 sensor driver draft");
+MODULE_LICENSE("GPL");
diff --git a/drivers/media/i2c/hm1092_regs.h b/drivers/media/i2c/hm1092_regs.h
new file mode 100644
index 000000000000..4df2d5b49d81
--- /dev/null
+++ b/drivers/media/i2c/hm1092_regs.h
@@ -0,0 +1,223 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* HM1092 register tables extracted from Qualcomm Chromatix sensor module.
+ * Source: com.qti.sensormodule.hm1092.bin
+ * Generator: hm1092-re/gen_hm1092_regs.py
+ * DO NOT HAND EDIT — regenerate from the bin.
+ */
+
+struct hm1092_reg {
+ u16 address;
+ u8 val;
+};
+
+static const struct hm1092_reg hm1092_init_regs[] = {
+ { 0x0103, 0x00 },
+ { 0x030a, 0x05 },
+ { 0x030d, 0x0c },
+ { 0x030f, 0x5a },
+ { 0x0307, 0x00 },
+ { 0x0309, 0x01 },
+ { 0x0387, 0x01 },
+ { 0x0100, 0x02 },
+ { 0x4265, 0x02 },
+ { 0x4002, 0x2b },
+ { 0x4001, 0x00 },
+ { 0x0101, 0x03 },
+ { 0x4024, 0x40 },
+ { 0x0203, 0xbe },
+ { 0x0202, 0x00 },
+ { 0x0341, 0xee },
+ { 0x0340, 0x02 },
+ { 0x0343, 0x50 },
+ { 0x0342, 0x06 },
+ { 0x0345, 0x30 },
+ { 0x0344, 0x00 },
+ { 0x0349, 0xad },
+ { 0x0348, 0x04 },
+ { 0x0347, 0x08 },
+ { 0x0346, 0x00 },
+ { 0x034b, 0xd5 },
+ { 0x034a, 0x02 },
+ { 0x5015, 0xb3 },
+ { 0x0350, 0x53 },
+ { 0x0361, 0x30 },
+ { 0x0360, 0x00 },
+ { 0x034d, 0x30 },
+ { 0x034c, 0x02 },
+ { 0x034f, 0x68 },
+ { 0x034e, 0x01 },
+ { 0x0390, 0x03 },
+ { 0x0383, 0x00 },
+ { 0x0387, 0x10 },
+ { 0x50dd, 0x01 },
+ { 0x50cb, 0x21 },
+ { 0x5005, 0x28 },
+ { 0x5004, 0x40 },
+ { 0x5007, 0x28 },
+ { 0x5006, 0x40 },
+ { 0x5011, 0x00 },
+ { 0x501d, 0x4c },
+ { 0x5013, 0x03 },
+ { 0x4131, 0x01 },
+ { 0x5283, 0x03 },
+ { 0x5282, 0xff },
+ { 0x5010, 0x20 },
+ { 0x4132, 0x20 },
+ { 0x50d5, 0xe0 },
+ { 0x50d7, 0x12 },
+ { 0x50bb, 0x14 },
+ { 0x50b7, 0x00 },
+ { 0x50b9, 0xff },
+ { 0x50b8, 0x70 },
+ { 0x50ba, 0xff },
+ { 0x50fa, 0x02 },
+ { 0x50b4, 0x00 },
+ { 0x50a2, 0x0b },
+ { 0x50ad, 0x07 },
+ { 0x50ac, 0x24 },
+ { 0x50af, 0x40 },
+ { 0x50ae, 0x20 },
+ { 0x50ab, 0x07 },
+ { 0x50aa, 0x22 },
+ { 0x50a7, 0x00 },
+ { 0x50a6, 0x00 },
+ { 0x5099, 0x11 },
+ { 0x509b, 0x03 },
+ { 0x50b3, 0x04 },
+ { 0x50a0, 0x30 },
+ { 0x5098, 0x00 },
+ { 0x52f2, 0x53 },
+ { 0x5209, 0x0c },
+ { 0x5216, 0x02 },
+ { 0x521e, 0x01 },
+ { 0x50e8, 0x00 },
+ { 0x5200, 0x60 },
+ { 0x5202, 0x00 },
+ { 0x5201, 0x80 },
+ { 0x5203, 0x01 },
+ { 0x5208, 0x0b },
+ { 0x520d, 0x40 },
+ { 0x520c, 0x15 },
+ { 0x5215, 0x04 },
+ { 0x50ea, 0x74 },
+ { 0x5214, 0x28 },
+ { 0x5218, 0x07 },
+ { 0x5217, 0x01 },
+ { 0x0310, 0x00 },
+ { 0x4b31, 0x06 },
+ { 0x4b3b, 0x02 },
+ { 0x4b45, 0x01 },
+ { 0x4b44, 0x0c },
+ { 0x4b47, 0x00 },
+ { 0x5101, 0x13 },
+ { 0x5100, 0x03 },
+ { 0x5103, 0x33 },
+ { 0x5102, 0x23 },
+ { 0x5105, 0x42 },
+ { 0x5104, 0x43 },
+ { 0x5106, 0x40 },
+ { 0x5119, 0x00 },
+ { 0x5118, 0x00 },
+ { 0x511b, 0x00 },
+ { 0x511a, 0x00 },
+ { 0x511d, 0x00 },
+ { 0x511c, 0x00 },
+ { 0x511e, 0x00 },
+ { 0x5131, 0x23 },
+ { 0x5130, 0x13 },
+ { 0x5133, 0x43 },
+ { 0x5132, 0x33 },
+ { 0x5135, 0x40 },
+ { 0x5134, 0x42 },
+ { 0x5136, 0x40 },
+ { 0x5149, 0x01 },
+ { 0x5148, 0x01 },
+ { 0x514b, 0x01 },
+ { 0x514a, 0x01 },
+ { 0x514d, 0x01 },
+ { 0x514c, 0x01 },
+ { 0x514e, 0x01 },
+ { 0x51c0, 0x00 },
+ { 0x51c6, 0x00 },
+ { 0x51cc, 0x00 },
+ { 0x51d2, 0x00 },
+ { 0x51d8, 0x00 },
+ { 0x51c1, 0x81 },
+ { 0x51c7, 0x81 },
+ { 0x51cd, 0x81 },
+ { 0x51d3, 0x81 },
+ { 0x51d9, 0x81 },
+ { 0x51c2, 0xec },
+ { 0x51c8, 0xec },
+ { 0x51ce, 0xec },
+ { 0x51d4, 0xec },
+ { 0x51da, 0xec },
+ { 0x51c3, 0x00 },
+ { 0x51c9, 0x00 },
+ { 0x51cf, 0x00 },
+ { 0x51d5, 0x00 },
+ { 0x51db, 0x00 },
+ { 0x51c4, 0x55 },
+ { 0x51ca, 0x55 },
+ { 0x51d0, 0x54 },
+ { 0x51d6, 0x53 },
+ { 0x51dc, 0x53 },
+ { 0x51c5, 0x44 },
+ { 0x51cb, 0x24 },
+ { 0x51d1, 0x24 },
+ { 0x51d7, 0x14 },
+ { 0x51dd, 0x14 },
+ { 0x51e0, 0x09 },
+ { 0x51e2, 0x04 },
+ { 0x51e4, 0x08 },
+ { 0x51e6, 0x08 },
+ { 0x51e1, 0x03 },
+ { 0x51e3, 0x03 },
+ { 0x51e5, 0x07 },
+ { 0x51e8, 0x04 },
+ { 0x51e7, 0x07 },
+ { 0x51e9, 0x46 },
+ { 0x51eb, 0x62 },
+ { 0x51ea, 0x43 },
+ { 0x51ed, 0x00 },
+ { 0x51ec, 0x61 },
+ { 0x51ee, 0x00 },
+ { 0x5206, 0x80 },
+ { 0x3110, 0x02 },
+ { 0x3704, 0x02 },
+ { 0x3704, 0x02 },
+ { 0x4b20, 0x9e },
+ { 0x4b18, 0x00 },
+ { 0x4b3e, 0x00 },
+ { 0x4b0e, 0x0e },
+ { 0x4800, 0xac },
+ { 0x0104, 0x01 },
+ { 0x0104, 0x00 },
+ { 0x4801, 0xae },
+ { 0x0000, 0x00 },
+ { 0x0037, 0x30 },
+};
+
+static const struct hm1092_reg hm1092_start_streaming[] = {
+ { 0x0100, 0x01 },
+};
+
+static const struct hm1092_reg hm1092_test_pattern_mode0[] = {
+ { 0x0601, 0x00 },
+};
+
+static const struct hm1092_reg hm1092_test_pattern_mode1[] = {
+ { 0x0601, 0x01 },
+};
+
+static const struct hm1092_reg hm1092_test_pattern_mode2[] = {
+ { 0x0601, 0x02 },
+};
+
+static const struct hm1092_reg hm1092_test_pattern_mode3[] = {
+ { 0x0601, 0x03 },
+};
+
+static const struct hm1092_reg hm1092_test_pattern_mode4[] = {
+ { 0x0601, 0x04 },
+};
--
2.53.0
^ permalink raw reply related
* [PATCH 2/9] media: dt-bindings: Add Himax HM1092 NIR sensor
From: Ramshouriesh @ 2026-06-10 11:09 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain, Bryan O'Donoghue,
Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy, Ramshouriesh
In-Reply-To: <20260610-a14-himax-hm1092-v1-0-0c9907da47ed@gmail.com>
Add a dt-binding schema for the Himax HM1092 1MP monochrome
near-infrared CMOS sensor, used as the face-authentication IR camera on
Snapdragon X laptops such as the ASUS Zenbook A14. The sensor streams
10-bit RAW over 1 or 2 MIPI CSI-2 data lanes.
The optional generic "leds" property (video-interface-devices.yaml)
associates an IR illuminator flash LED with the sensor, which the
driver strobes while streaming.
Signed-off-by: Ramshouriesh <rshouriesh@gmail.com>
---
.../bindings/media/i2c/himax,hm1092.yaml | 118 +++++++++++++++++++++
1 file changed, 118 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/i2c/himax,hm1092.yaml b/Documentation/devicetree/bindings/media/i2c/himax,hm1092.yaml
new file mode 100644
index 000000000000..085001493a20
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/himax,hm1092.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/himax,hm1092.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HM1092 Monochrome NIR Sensor
+
+maintainers:
+ - Ramshouriesh <rshouriesh@gmail.com>
+
+description:
+ The Himax HM1092 is a 1 megapixel monochrome near-infrared CMOS image
+ sensor with a MIPI CSI-2 interface, commonly used as the IR camera for
+ face authentication on laptops. It supports 10 bit RAW output at
+ 1288x728 over 1 or 2 CSI-2 data lanes. An optional infrared
+ illuminator LED may be associated with the sensor through the generic
+ "leds" property; the driver strobes it while the sensor is streaming
+ so the scene stays lit for IR capture.
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: himax,hm1092
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ avdd-supply:
+ description: Analogue circuit voltage supply.
+
+ dovdd-supply:
+ description: I/O circuit voltage supply.
+
+ dvdd-supply:
+ description: Digital circuit voltage supply.
+
+ reset-gpios:
+ maxItems: 1
+ description: Active low GPIO connected to the XSHUTDOWN pad.
+
+ leds:
+ description:
+ Optional phandle to an infrared illuminator flash LED strobed by
+ the driver while streaming.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ additionalProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 2
+ link-frequencies: true
+ remote-endpoint: true
+
+ required:
+ - data-lanes
+ - link-frequencies
+ - remote-endpoint
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@24 {
+ compatible = "himax,hm1092";
+ reg = <0x24>;
+
+ reset-gpios = <&tlmm 109 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam_ir_default>;
+
+ clocks = <&camcc 1>;
+ assigned-clocks = <&camcc 1>;
+ assigned-clock-rates = <24000000>;
+
+ orientation = <0>;
+
+ leds = <&ir_flash>;
+
+ avdd-supply = <&vreg_l7m_2p9>;
+ dvdd-supply = <&vreg_l7m_2p9>;
+ dovdd-supply = <&vreg_l4m_1p8>;
+
+ port {
+ hm1092_ep: endpoint {
+ data-lanes = <1>;
+ link-frequencies = /bits/ 64 <400000000>;
+ remote-endpoint = <&camss_csiphy0_inep>;
+ };
+ };
+ };
+ };
+...
--
2.53.0
^ permalink raw reply related
* [PATCH 1/9] arm64: dts: qcom: x1-asus-zenbook-a14: Add on OV02C10 RGB sensor on CSIPHY4
From: Ramshouriesh @ 2026-06-10 11:09 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain, Bryan O'Donoghue,
Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy, Ramshouriesh
In-Reply-To: <20260610-a14-himax-hm1092-v1-0-0c9907da47ed@gmail.com>
From: Aleksandrs Vinarskis <alex@vinarskis.com>
The device uses Omnivision ov02c10 RGB sensor. Reset GPIO, privacy LED
GPIO, LDOs are extracted from decompiled AeoB files.
Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
Signed-off-by: Ramshouriesh <rshouriesh@gmail.com>
---
arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi | 109 +++++++++++++++++++++-
1 file changed, 105 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi b/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
index 66d566808f58..388737eaa624 100644
--- a/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
@@ -8,6 +8,7 @@
#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/leds/common.h>
+#include <dt-bindings/phy/phy.h>
#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
@@ -108,14 +109,11 @@ leds {
pinctrl-0 = <&cam_indicator_en>;
pinctrl-names = "default";
- led-camera-indicator {
- label = "white:camera-indicator";
+ privacy_led: privacy-led {
function = LED_FUNCTION_INDICATOR;
color = <LED_COLOR_ID_WHITE>;
gpios = <&tlmm 110 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "none";
default-state = "off";
- /* Reuse as a panic indicator until we get a "camera on" trigger */
panic-indicator;
};
};
@@ -546,6 +544,13 @@ vreg_l6b_1p8: ldo6 {
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
};
+ vreg_l7b_2p8: ldo7 {
+ regulator-name = "vreg_l7b_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
vreg_l8b_3p0: ldo8 {
regulator-name = "vreg_l8b_3p0";
regulator-min-microvolt = <3072000>;
@@ -796,6 +801,86 @@ vreg_l3j_0p8: ldo3 {
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
};
};
+
+ regulators-8 {
+ compatible = "qcom,pm8010-rpmh-regulators";
+ qcom,pmic-id = "m";
+
+ vdd-l3-l4-supply = <&vreg_s4c_1p8>;
+ vdd-l7-supply = <&vreg_bob1>;
+
+ vreg_l3m_1p8: ldo3 {
+ regulator-name = "vreg_l3m_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+};
+
+&camss {
+ status = "okay";
+
+ ports {
+ /*
+ * port0 => csiphy0
+ * port1 => csiphy1
+ * port2 => csiphy2
+ * port3 => csiphy4
+ */
+ port@3 {
+ csiphy4_ep: endpoint@4 {
+ reg = <4>;
+ clock-lanes = <7>;
+ data-lanes = <0 1>;
+ remote-endpoint = <&ov02c10_ep>;
+ };
+ };
+ };
+};
+
+&cci1 {
+ status = "okay";
+};
+
+&cci1_i2c1 {
+ camera@36 {
+ compatible = "ovti,ov02c10";
+ reg = <0x36>;
+
+ reset-gpios = <&tlmm 237 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&cam_rgb_default>;
+ pinctrl-names = "default";
+
+ leds = <&privacy_led>;
+ led-names = "privacy";
+
+ clocks = <&camcc CAM_CC_MCLK4_CLK>;
+ assigned-clocks = <&camcc CAM_CC_MCLK4_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ orientation = <0>;
+
+ avdd-supply = <&vreg_l7b_2p8>;
+ dvdd-supply = <&vreg_l7b_2p8>;
+ dovdd-supply = <&vreg_l3m_1p8>;
+
+ port {
+ ov02c10_ep: endpoint {
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <400000000>;
+ remote-endpoint = <&csiphy4_ep>;
+ };
+ };
+ };
+};
+
+&csiphy4 {
+ vdda-0p8-supply = <&vreg_l2c_0p8>;
+ vdda-1p2-supply = <&vreg_l1c_1p2>;
+ phy-type = <PHY_TYPE_DPHY>;
+
+ status = "okay";
};
&i2c0 {
@@ -1283,6 +1368,22 @@ cam_indicator_en: cam-indicator-en-state {
bias-disable;
};
+ cam_rgb_default: cam-rgb-default-state {
+ mclk-pins {
+ pins = "gpio100";
+ function = "cam_aon";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ reset-n-pins {
+ pins = "gpio237";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
edp_reg_en: edp-reg-en-state {
pins = "gpio70";
function = "gpio";
--
2.53.0
^ permalink raw reply related
* [PATCH 0/9] media/arm64: HM1092 IR camera and ASUS Zenbook A14 (X1P42100) camera support
From: Ramshouriesh @ 2026-06-10 11:09 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain, Bryan O'Donoghue,
Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy, Ramshouriesh
The ASUS Zenbook A14 (Qualcomm X1P42100, "Purwa") has two front cameras
behind the SoC CAMSS: an OV02C10 RGB sensor and a Himax HM1092 mono NIR
sensor used for face unlock. This series adds a driver for the HM1092 and
the device tree to wire both sensors up on the A14.
The HM1092 binding, driver and MAINTAINERS entry do not depend on the
rest of the series and can go through the media tree on their own.
The remaining DTS and PHY patches are the A14 camera enablement. They sit
on top of several series that are not in mainline yet, listed below. With
those applied the series builds on next-20260609: the A14 dtb and every
module it touches (hm1092, qcom-camss including csiphy, and the
qcom-mipi-csi2 phy) compile and work: both sensors probe and stream
frames on the A14.
Prerequisites, in the order they apply:
1. phy: dphy: Extend phy_configure_opts_mipi_dphy to support position
and polarity (Bryan O'Donoghue, v1)
https://lore.kernel.org/all/20260325-dphy-params-extension-v1-0-c6df5599284a@linaro.org/
2. clk: qcom: videocc and camcc for X1P42100 (Jagadeesh Kona, v5)
https://lore.kernel.org/all/20260507-purwa-videocc-camcc-v5-0-fc3af4130282@oss.qualcomm.com/
3. phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver (Bryan O'Donoghue, v8)
https://lore.kernel.org/all/20260523-x1e-csi2-phy-v8-0-a85668459521@linaro.org/
4. media: dt-bindings and PHY updates for CAMSS on x1e80100 (Bryan O'Donoghue, v11)
https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-0-5b93415be6dd@linaro.org/
5. arm64: dts: qcom: x1e/Hamoa camera DTSI (Bryan O'Donoghue, v3)
https://lore.kernel.org/all/20260326-x1e-camss-csi2-phy-dtsi-v3-0-1d5a9306116a@linaro.org/
6. media: qcom: camss: Add support for X1P42100 camss (Wenmeng Liu, v2)
https://lore.kernel.org/all/20260511-purwa_camss-v2-0-22608ab9126c@oss.qualcomm.com/
From the videocc/camcc series only the CAMCC block (patch 6/6) is still
needed; its clock drivers and bindings are already in linux-next. That
patch adds the camcc node and sets the Purwa camcc and videocc compatibles.
From the x1e/Hamoa camera DTSI series only the CCI and CAMSS-block patches
are needed; its CAMCC block duplicates the videocc/camcc series, and the
x1e80100 board patches do not apply to the A14.
Patch 1 adds the OV02C10 node. It is Aleksandrs Vinarskis' work, carried
here with his Signed-off-by so the A14 camera support stays one chain.
Signed-off-by: Ramshouriesh <rshouriesh@gmail.com>
---
Aleksandrs Vinarskis (1):
arm64: dts: qcom: x1-asus-zenbook-a14: Add on OV02C10 RGB sensor on CSIPHY4
Ramshouriesh (8):
media: dt-bindings: Add Himax HM1092 NIR sensor
media: i2c: hm1092: add Himax HM1092 mono NIR sensor driver
MAINTAINERS: add entry for the Himax HM1092 sensor driver
arm64: dts: qcom: x1-asus-zenbook-a14: add HM1092 IR camera and wire cameras to camss
arm64: dts/media: qcom: keep PLL8 out of Purwa camss hot path
arm64: dts: qcom: hamoa: reorder csiphy power-domains for v8 CSI2-PHY
dt-bindings: phy: qcom: add MIPI CSI2 mode constants
phy: qcom-mipi-csi2: accept PHY_QCOM_CSI2_MODE_DPHY phy-cell
.../bindings/media/i2c/himax,hm1092.yaml | 118 ++++
MAINTAINERS | 9 +
arch/arm64/boot/dts/qcom/hamoa.dtsi | 32 +-
arch/arm64/boot/dts/qcom/purwa.dtsi | 12 +
arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi | 227 ++++++-
drivers/media/i2c/Kconfig | 14 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/hm1092.c | 685 +++++++++++++++++++++
drivers/media/i2c/hm1092_regs.h | 223 +++++++
drivers/media/platform/qcom/camss/camss.c | 16 +-
drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c | 3 +-
include/dt-bindings/phy/phy-qcom-mipi-csi2.h | 15 +
12 files changed, 1326 insertions(+), 29 deletions(-)
---
base-commit: 49e02880ec0a8c378e811bc9d85da188d7c6204c
change-id: 20260609-a14-himax-hm1092-bbcbe0229afe
prerequisite-message-id: <20260325-dphy-params-extension-v1-0-c6df5599284a@linaro.org>
prerequisite-patch-id: 471e9403130bb3e65cea1d2365d75ef664662306
prerequisite-patch-id: 075fa72fba3c4f51138b88972e6a5e240038d90c
prerequisite-patch-id: 4edca361ad7d370a338641d1ebb5ca65b114a244
prerequisite-patch-id: 32dd1b55ba678d00088b376e33e12d9da6241aca
prerequisite-patch-id: 24424189b11acee204622997908d85a0efbb2503
prerequisite-message-id: <20260523-x1e-csi2-phy-v8-0-a85668459521@linaro.org>
prerequisite-patch-id: dc660c63d4382e84af51241381727954bd5ed013
prerequisite-patch-id: 237410e8df475d80bede4590288b6b053b1483e5
prerequisite-message-id: <20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-0-5b93415be6dd@linaro.org>
prerequisite-patch-id: 6e8e67cd3ab96a602971bbeeb7dfdeaf3f1426a2
prerequisite-patch-id: bbf431fcabc17c30fa5e804eb4accb8275198b37
prerequisite-patch-id: a7fbea14628b62a8de096dea420473b283010aba
prerequisite-patch-id: b6b6c4e7a5818e1b93fe2758902bd32d2be48509
prerequisite-patch-id: 4f11e3d079a484008a03ce750952d6e2933c0253
prerequisite-patch-id: 5f5504fd7b5eee72c3fb8c045fa57219fd2f0456
prerequisite-patch-id: 570b65b326f4c684d813f6ebeda152378dc2a47f
prerequisite-patch-id: bc5b9321c124abd961ae1f60610dc46701dc80ac
prerequisite-patch-id: 6d36feaa3a210039f87ea47aa74423a670260fb6
prerequisite-message-id: <20260511-purwa_camss-v2-0-22608ab9126c@oss.qualcomm.com>
prerequisite-patch-id: 9430f9db2ca3486da39606aa806db3c1973ad2d1
prerequisite-patch-id: d90c86fbd38851530f9480562647703c32a86a91
prerequisite-patch-id: baa498638bf0da1bdc25a3c5e827c351d3b78e79
Best regards,
--
Ramshouriesh <rshouriesh@gmail.com>
^ permalink raw reply
* Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions
From: Arnd Bergmann @ 2026-06-10 11:09 UTC (permalink / raw)
To: Josua Mayer, Frank Li, sashiko-reviews@lists.linux.dev
Cc: Conor Dooley, Rob Herring, Frank Li, devicetree@vger.kernel.org,
imx@lists.linux.dev
In-Reply-To: <d8373e08-bbd0-4a6c-849b-628c49fc2ec4@solid-run.com>
On Wed, Jun 10, 2026, at 12:36, Josua Mayer wrote:
> Am 10.06.26 um 09:43 schrieb Arnd Bergmann:
>> On Wed, Jun 10, 2026, at 00:13, Frank Li wrote:
>>
>> If everything goes well otherwise, this PR should still make
>> it in time, but it would be nice to avoid such minute
>> excitement in the future.
>
> Thank you for discussing this issue in detail!
>
> If you need me to send a fixup, kindly let me know.
I think that would be best, yes. Then Frank can apply
the patch on top and send the updated pull request.
Arnd
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: PCI: qcom,pcie-ipq9574: Add IPQ9650 compatible
From: sashiko-bot @ 2026-06-10 11:08 UTC (permalink / raw)
To: Kathiravan Thirumoorthy; +Cc: devicetree, linux-pci, robh, conor+dt
In-Reply-To: <20260610-ipq9650_pcie_binding-v2-1-69e27a1fbf1c@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The schema modification fails to make the global interrupt mandatory for IPQ9650 when `msi-map` is used.
--
commit 27378ca447659c2b32e287fcda248ae3808316af
Author: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
dt-bindings: PCI: qcom,pcie-ipq9574: Add IPQ9650 compatible
This commit adds the IPQ9650 PCIe compatible string to the IPQ9574 binding
and updates the constraints to make the global interrupt required for the
IPQ9650 controller.
> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ipq9574.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ipq9574.yaml
> --- a/Documentation/devicetree/bindings/pci/qcom,pcie-ipq9574.yaml
> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ipq9574.yaml
[ ... ]
> @@ -82,6 +83,18 @@ required:
>
> allOf:
> - $ref: qcom,pcie-common.yaml#
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - qcom,pcie-ipq9650
> + then:
> + properties:
> + interrupts:
> + minItems: 9
> + interrupt-names:
> + minItems: 9
[Severity: Medium]
The commit message mentions making the global interrupt required for IPQ9650,
but does this block actually enforce its presence?
Since qcom,pcie-common.yaml allows interrupts and interrupt-names to be
omitted entirely if an msi-map property is present, a node could omit
the interrupts property completely. If omitted, the minItems constraints
here are skipped, and the node will silently pass validation without
providing the global interrupt.
Should interrupts and interrupt-names also be explicitly added to a
required list within this then block to ensure they cannot be bypassed?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-ipq9650_pcie_binding-v2-0-69e27a1fbf1c@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH RFC v7 6/9] PM / devfreq: Add a governor for tracking remote device frequencies
From: sashiko-bot @ 2026-06-10 11:08 UTC (permalink / raw)
To: Pragnesh Papaniya; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260610-rfc_v7_scmi_memlat-v7-6-f3f68c608f25@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] DEVFREQ_GOV_FLAG_TRACK_REMOTE inappropriately clamps the tracked frequency to local PM QoS limits and bypasses OPP rounding, breaking statistics and tracepoints.
- [High] Unloading an `IMMUTABLE` governor bypasses the immutable restriction, allowing incompatible governors to bind and crash the kernel via a missing `.target` callback check.
- [Medium] Missing validation of `get_cur_freq` during governor start causes unbounded dmesg log spam.
Pre-existing issues:
- [High] Time-of-Check to Time-of-Use (TOCTOU) race conditions and unprotected reads during governor removal lead to NULL pointer dereferences or Use-After-Free crashes.
--
commit a561d57fcfe231ac7e70741f77838221fbcf0815
Author: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
PM / devfreq: Add a governor for tracking remote device frequencies
This commit adds a new "remote" devfreq governor that uses the track_remote
flag to expose a remote device's frequency to userspace. It deliberately
does not advertise the target frequency attribute since the kernel cannot
set it on a remote-managed device.
> diff --git a/drivers/devfreq/governor_remote.c b/drivers/devfreq/governor_remote.c
> new file mode 100644
> index 0000000000000..df3819757e56f
> --- /dev/null
> +++ b/drivers/devfreq/governor_remote.c
> @@ -0,0 +1,73 @@
[ ... ]
> +static int devfreq_remote_track_handler(struct devfreq *devfreq, unsigned int event, void *data)
> +{
> + switch (event) {
> + case DEVFREQ_GOV_START:
> + devfreq_monitor_start(devfreq);
> + break;
[Severity: Medium]
Will this cause unbounded dmesg log spam if a device fails to provide the
get_cur_freq callback?
If a device registers with the remote governor but lacks the
devfreq->profile->get_cur_freq callback, the governor successfully starts.
On every polling interval, devfreq_monitor() calls update_devfreq(), which
invokes devfreq_remote_track_func(). This returns -ENXIO, causing
update_devfreq() to log 'dvfs failed with (-6) error' to the console.
Since the delayed work is re-queued unconditionally, this will spam the log.
Should DEVFREQ_GOV_START validate the presence of get_cur_freq and return
-EINVAL if it is missing?
[ ... ]
> +static struct devfreq_governor devfreq_remote_track = {
> + .name = DEVFREQ_GOV_REMOTE,
> + .attrs = DEVFREQ_GOV_ATTR_POLLING_INTERVAL
> + | DEVFREQ_GOV_ATTR_TIMER,
> + .flags = DEVFREQ_GOV_FLAG_IMMUTABLE
> + | DEVFREQ_GOV_FLAG_TRACK_REMOTE,
[Severity: High]
Does the use of DEVFREQ_GOV_FLAG_TRACK_REMOTE here cause the tracked
frequency to be clamped and bypass OPP rounding?
When the remote governor returns the actual frequency via get_target_freq(),
devfreq_update_target() incorrectly clamps this observed frequency against the
local PM QoS min_freq and max_freq bounds.
The clamped frequency is then passed to devfreq_set_target(). Because
DEVFREQ_GOV_FLAG_TRACK_REMOTE is set, devfreq_set_target() bypasses the
profile->target() callback and the frequency is never rounded to a valid
discrete OPP.
This clamped, unrounded frequency is recorded into trans_stat, time_in_state,
and tracepoints, causing them to report false data if the remote device
operates outside local bounds.
Furthermore, because the frequency typically doesn't match a discrete
freq_table entry, devfreq_update_status() returns -EINVAL, spamming the
log with 'Couldn't update frequency transition information'.
[ ... ]
> +static void __exit devfreq_remote_track_exit(void)
> +{
> + int ret;
> +
> + ret = devfreq_remove_governor(&devfreq_remote_track);
[Severity: High]
Can unloading this module bypass the DEVFREQ_GOV_FLAG_IMMUTABLE restriction
and lead to a NULL pointer dereference?
Devices using the remote governor omit the .target callback because
frequencies are managed externally. The governor uses
DEVFREQ_GOV_FLAG_IMMUTABLE to prevent users from switching to a governor that
would invoke the missing callback.
When this module is unloaded, devfreq_remove_governor() forcefully stops it
and clears devfreq->governor. The core forgets the device was immutable,
allowing a user to bind a non-remote governor via sysfs.
When the new governor calls devfreq_update_target(), it eventually invokes
devfreq_set_target().
Since devfreq_set_target() unconditionally calls devfreq->profile->target()
without checking if it is NULL, would this result in a kernel panic?
[Severity: High]
This isn't a bug introduced by this patch, but does calling
devfreq_remove_governor() here expose a race condition leading to a
use-after-free or NULL pointer dereference?
Devfreq governor modules are not pinned with try_module_get() as the
devfreq_governor struct lacks an owner field, meaning they can be unloaded
while devices are actively using them.
devfreq_remove_governor() sets devfreq->governor = NULL while holding
devfreq_list_lock but without acquiring devfreq->lock.
Concurrently, execution paths like devfreq_update_target() read or check
devfreq->governor while holding only devfreq->lock.
If a concurrent PM QoS notifier or sysfs write passes the
if (!devfreq->governor) check, and the governor module is removed immediately
after, the subsequent call to devfreq->governor->get_target_freq() will
dereference a NULL pointer or execute unmapped module text.
> + if (ret)
> + pr_err("%s: failed to remove governor %d\n", __func__, ret);
> +}
> +module_exit(devfreq_remote_track_exit);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-rfc_v7_scmi_memlat-v7-0-f3f68c608f25@oss.qualcomm.com?part=6
^ permalink raw reply
* [PATCH v2 2/2] dt-bindings: PCI: qcom,pcie-ipq9574: Document the ipq5210 pcie controller
From: Kathiravan Thirumoorthy @ 2026-06-10 11:00 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson
Cc: linux-arm-msm, linux-pci, devicetree, linux-kernel,
Kathiravan Thirumoorthy, Varadarajan Narayanan
In-Reply-To: <20260610-ipq9650_pcie_binding-v2-0-69e27a1fbf1c@oss.qualcomm.com>
From: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
Document the ipq5210 PCIe controller using ipq9574 as fallback compatible.
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
Documentation/devicetree/bindings/pci/qcom,pcie-ipq9574.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ipq9574.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ipq9574.yaml
index e92acddb969e..533079811881 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie-ipq9574.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ipq9574.yaml
@@ -17,6 +17,7 @@ properties:
- qcom,pcie-ipq9574
- items:
- enum:
+ - qcom,pcie-ipq5210
- qcom,pcie-ipq5332
- qcom,pcie-ipq5424
- qcom,pcie-ipq9650
@@ -88,6 +89,7 @@ allOf:
compatible:
contains:
enum:
+ - qcom,pcie-ipq5210
- qcom,pcie-ipq9650
then:
properties:
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: PCI: qcom,pcie-ipq9574: Add IPQ9650 compatible
From: Kathiravan Thirumoorthy @ 2026-06-10 11:00 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson
Cc: linux-arm-msm, linux-pci, devicetree, linux-kernel,
Kathiravan Thirumoorthy
In-Reply-To: <20260610-ipq9650_pcie_binding-v2-0-69e27a1fbf1c@oss.qualcomm.com>
Add the IPQ9650 PCIe compatible to the IPQ9574 binding, as the IPQ9650
controller is compatible with IPQ9574 and uses it as the fallback.
While at it, make the global interrupt as required for IPQ9650.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
.../devicetree/bindings/pci/qcom,pcie-ipq9574.yaml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ipq9574.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ipq9574.yaml
index 4be342cc04e1..e92acddb969e 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie-ipq9574.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ipq9574.yaml
@@ -19,6 +19,7 @@ properties:
- enum:
- qcom,pcie-ipq5332
- qcom,pcie-ipq5424
+ - qcom,pcie-ipq9650
- const: qcom,pcie-ipq9574
reg:
@@ -82,6 +83,18 @@ required:
allOf:
- $ref: qcom,pcie-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,pcie-ipq9650
+ then:
+ properties:
+ interrupts:
+ minItems: 9
+ interrupt-names:
+ minItems: 9
unevaluatedProperties: false
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] Add PCIe binding for IPQ9650 and IPQ5210
From: Kathiravan Thirumoorthy @ 2026-06-10 11:00 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson
Cc: linux-arm-msm, linux-pci, devicetree, linux-kernel,
Kathiravan Thirumoorthy, Varadarajan Narayanan
Add the IPQ9650 and IPQ5210 PCIe compatible to the IPQ9574 binding, as the
IPQ9650 and IPQ5210 controller is compatible with IPQ9574 and uses it as
the fallback.
Make the global interrupt is required for these SoCs.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
Changes in v2:
- Made the global interrupt as required
- Incorporated the IPQ5210 binding change into this series to avoid
conflicts
- Link to v1: https://patch.msgid.link/20260602-ipq9650_pcie_binding-v1-1-486a535da8c5@oss.qualcomm.com
To: Bjorn Helgaas <bhelgaas@google.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: Krzysztof Wilczyński <kwilczynski@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Bjorn Andersson <andersson@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Kathiravan Thirumoorthy (1):
dt-bindings: PCI: qcom,pcie-ipq9574: Add IPQ9650 compatible
Varadarajan Narayanan (1):
dt-bindings: PCI: qcom,pcie-ipq9574: Document the ipq5210 pcie controller
.../devicetree/bindings/pci/qcom,pcie-ipq9574.yaml | 15 +++++++++++++++
1 file changed, 15 insertions(+)
---
base-commit: 49e02880ec0a8c378e811bc9d85da188d7c6204c
change-id: 20260521-ipq9650_pcie_binding-1c76095954d9
Best regards,
--
Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
^ permalink raw reply
* [PATCH] dt-bindings: iio: accel: Convert lis302 binding to YAML schema
From: Md Shofiqul Islam @ 2026-06-10 11:00 UTC (permalink / raw)
To: linux-iio, devicetree
Cc: jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt, krzk,
linux-kernel, Md Shofiqul Islam
Convert the STMicroelectronics LIS302DL/LIS3LV02D accelerometer device
tree binding from plain text format to YAML schema format.
The binding covers two variants matched via their respective bus drivers:
- SPI: st,lis302dl-spi (drivers/misc/lis3lv02d/lis3lv02d_spi.c)
- I2C: st,lis3lv02d (drivers/misc/lis3lv02d/lis3lv02d_i2c.c)
Document all vendor-specific properties read by the driver via
of_property_read_*(), including click detection, IRQ routing, free-fall/
wake-up engines, high-pass filtering, axis remapping, output data rate,
and self-test limits.
Also correct the click threshold property names: the driver reads
"st,click-threshold-{x,y,z}" but the old .txt documented them as
"st,click-thresh-{x,y,z}".
Validated with: make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
---
.../devicetree/bindings/iio/accel/lis302.txt | 119 ------
.../bindings/iio/accel/st,lis302dl.yaml | 343 ++++++++++++++++++
2 files changed, 343 insertions(+), 119 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/accel/lis302.txt
create mode 100644 Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
diff --git a/Documentation/devicetree/bindings/iio/accel/lis302.txt b/Documentation/devicetree/bindings/iio/accel/lis302.txt
deleted file mode 100644
index 457539647f36..000000000000
--- a/Documentation/devicetree/bindings/iio/accel/lis302.txt
+++ /dev/null
@@ -1,119 +0,0 @@
-LIS302 accelerometer devicetree bindings
-
-This device is matched via its bus drivers, and has a number of properties
-that apply in on the generic device (independent from the bus).
-
-
-Required properties for the SPI bindings:
- - compatible: should be set to "st,lis3lv02d-spi"
- - reg: the chipselect index
- - spi-max-frequency: maximal bus speed, should be set to 1000000 unless
- constrained by external circuitry
- - interrupts: the interrupt generated by the device
-
-Required properties for the I2C bindings:
- - compatible: should be set to "st,lis3lv02d"
- - reg: i2c slave address
- - Vdd-supply: The input supply for Vdd
- - Vdd_IO-supply: The input supply for Vdd_IO
-
-
-Optional properties for all bus drivers:
-
- - st,click-single-{x,y,z}: if present, tells the device to issue an
- interrupt on single click events on the
- x/y/z axis.
- - st,click-double-{x,y,z}: if present, tells the device to issue an
- interrupt on double click events on the
- x/y/z axis.
- - st,click-thresh-{x,y,z}: set the x/y/z axis threshold
- - st,click-click-time-limit: click time limit, from 0 to 127.5msec
- with step of 0.5 msec
- - st,click-latency: click latency, from 0 to 255 msec with
- step of 1 msec.
- - st,click-window: click window, from 0 to 255 msec with
- step of 1 msec.
- - st,irq{1,2}-disable: disable IRQ 1/2
- - st,irq{1,2}-ff-wu-1: raise IRQ 1/2 on FF_WU_1 condition
- - st,irq{1,2}-ff-wu-2: raise IRQ 1/2 on FF_WU_2 condition
- - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready condition
- - st,irq{1,2}-click: raise IRQ 1/2 on click condition
- - st,irq-open-drain: consider IRQ lines open-drain
- - st,irq-active-low: make IRQ lines active low
- - st,wu-duration-1: duration register for Free-Fall/Wake-Up
- interrupt 1
- - st,wu-duration-2: duration register for Free-Fall/Wake-Up
- interrupt 2
- - st,wakeup-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for
- upper/lower limit
- - st,wakeup-threshold: set wakeup threshold
- - st,wakeup2-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for
- upper/lower limit for second wakeup
- engine.
- - st,wakeup2-threshold: set wakeup threshold for second wakeup
- engine.
- - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
- highpass cut-off frequency
- - st,hipass{1,2}-disable: disable highpass 1/2.
- - st,default-rate=: set the default rate
- - st,axis-{x,y,z}=: set the axis to map to the three coordinates.
- Negative values can be used for inverted axis.
- - st,{min,max}-limit-{x,y,z} set the min/max limits for x/y/z axis
- (used by self-test)
-
-
-Example for a SPI device node:
-
- accelerometer@0 {
- compatible = "st,lis302dl-spi";
- reg = <0>;
- spi-max-frequency = <1000000>;
- interrupt-parent = <&gpio>;
- interrupts = <104 0>;
-
- st,click-single-x;
- st,click-single-y;
- st,click-single-z;
- st,click-thresh-x = <10>;
- st,click-thresh-y = <10>;
- st,click-thresh-z = <10>;
- st,irq1-click;
- st,irq2-click;
- st,wakeup-x-lo;
- st,wakeup-x-hi;
- st,wakeup-y-lo;
- st,wakeup-y-hi;
- st,wakeup-z-lo;
- st,wakeup-z-hi;
- };
-
-Example for a I2C device node:
-
- lis331dlh: accelerometer@18 {
- compatible = "st,lis331dlh", "st,lis3lv02d";
- reg = <0x18>;
- Vdd-supply = <&lis3_reg>;
- Vdd_IO-supply = <&lis3_reg>;
-
- st,click-single-x;
- st,click-single-y;
- st,click-single-z;
- st,click-thresh-x = <10>;
- st,click-thresh-y = <10>;
- st,click-thresh-z = <10>;
- st,irq1-click;
- st,irq2-click;
- st,wakeup-x-lo;
- st,wakeup-x-hi;
- st,wakeup-y-lo;
- st,wakeup-y-hi;
- st,wakeup-z-lo;
- st,wakeup-z-hi;
- st,min-limit-x = <120>;
- st,min-limit-y = <120>;
- st,min-limit-z = <140>;
- st,max-limit-x = <550>;
- st,max-limit-y = <550>;
- st,max-limit-z = <750>;
- };
-
diff --git a/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml b/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
new file mode 100644
index 000000000000..befc419f7f39
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
@@ -0,0 +1,343 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/accel/st,lis302dl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics LIS302DL/LIS3LV02D 3-Axis Accelerometer
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+description: |
+ STMicroelectronics LIS302DL (SPI) and LIS3LV02D (I2C) 3-axis MEMS
+ accelerometers. Supports click detection, free-fall/wake-up interrupts,
+ high-pass filtering, axis remapping, and self-test functions.
+
+ Driver located at drivers/misc/lis3lv02d/.
+
+properties:
+ compatible:
+ enum:
+ - st,lis302dl-spi
+ - st,lis3lv02d
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ Vdd-supply:
+ description: Main power supply regulator (I2C variant).
+
+ Vdd_IO-supply:
+ description: I/O power supply regulator (I2C variant).
+
+ st,click-single-x:
+ type: boolean
+ description: Enable single-click detection on X axis.
+
+ st,click-double-x:
+ type: boolean
+ description: Enable double-click detection on X axis.
+
+ st,click-single-y:
+ type: boolean
+ description: Enable single-click detection on Y axis.
+
+ st,click-double-y:
+ type: boolean
+ description: Enable double-click detection on Y axis.
+
+ st,click-single-z:
+ type: boolean
+ description: Enable single-click detection on Z axis.
+
+ st,click-double-z:
+ type: boolean
+ description: Enable double-click detection on Z axis.
+
+ st,click-threshold-x:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Click detection threshold for X axis.
+
+ st,click-threshold-y:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Click detection threshold for Y axis.
+
+ st,click-threshold-z:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Click detection threshold for Z axis.
+
+ st,click-time-limit:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Click time limit, 0 to 127.5 ms in 0.5 ms steps.
+
+ st,click-latency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Click latency, 0 to 255 ms in 1 ms steps.
+
+ st,click-window:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Click window, 0 to 255 ms in 1 ms steps.
+
+ st,irq1-disable:
+ type: boolean
+ description: Disable IRQ1 pin.
+
+ st,irq1-ff-wu-1:
+ type: boolean
+ description: Route free-fall/wake-up 1 event to IRQ1 pin.
+
+ st,irq1-ff-wu-2:
+ type: boolean
+ description: Route free-fall/wake-up 2 event to IRQ1 pin.
+
+ st,irq1-data-ready:
+ type: boolean
+ description: Route data-ready event to IRQ1 pin.
+
+ st,irq1-click:
+ type: boolean
+ description: Route click event to IRQ1 pin.
+
+ st,irq2-disable:
+ type: boolean
+ description: Disable IRQ2 pin.
+
+ st,irq2-ff-wu-1:
+ type: boolean
+ description: Route free-fall/wake-up 1 event to IRQ2 pin.
+
+ st,irq2-ff-wu-2:
+ type: boolean
+ description: Route free-fall/wake-up 2 event to IRQ2 pin.
+
+ st,irq2-data-ready:
+ type: boolean
+ description: Route data-ready event to IRQ2 pin.
+
+ st,irq2-click:
+ type: boolean
+ description: Route click event to IRQ2 pin.
+
+ st,irq-open-drain:
+ type: boolean
+ description: Configure IRQ lines as open-drain.
+
+ st,irq-active-low:
+ type: boolean
+ description: Configure IRQ lines as active-low.
+
+ st,wu-duration-1:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Duration register for free-fall/wake-up interrupt 1.
+
+ st,wu-duration-2:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Duration register for free-fall/wake-up interrupt 2.
+
+ st,wakeup-x-lo:
+ type: boolean
+ description: Enable wake-up on X axis lower threshold crossing.
+
+ st,wakeup-x-hi:
+ type: boolean
+ description: Enable wake-up on X axis upper threshold crossing.
+
+ st,wakeup-y-lo:
+ type: boolean
+ description: Enable wake-up on Y axis lower threshold crossing.
+
+ st,wakeup-y-hi:
+ type: boolean
+ description: Enable wake-up on Y axis upper threshold crossing.
+
+ st,wakeup-z-lo:
+ type: boolean
+ description: Enable wake-up on Z axis lower threshold crossing.
+
+ st,wakeup-z-hi:
+ type: boolean
+ description: Enable wake-up on Z axis upper threshold crossing.
+
+ st,wakeup-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Threshold for wake-up engine 1.
+
+ st,wakeup2-x-lo:
+ type: boolean
+ description: Enable wake-up engine 2 on X axis lower threshold.
+
+ st,wakeup2-x-hi:
+ type: boolean
+ description: Enable wake-up engine 2 on X axis upper threshold.
+
+ st,wakeup2-y-lo:
+ type: boolean
+ description: Enable wake-up engine 2 on Y axis lower threshold.
+
+ st,wakeup2-y-hi:
+ type: boolean
+ description: Enable wake-up engine 2 on Y axis upper threshold.
+
+ st,wakeup2-z-lo:
+ type: boolean
+ description: Enable wake-up engine 2 on Z axis lower threshold.
+
+ st,wakeup2-z-hi:
+ type: boolean
+ description: Enable wake-up engine 2 on Z axis upper threshold.
+
+ st,wakeup2-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Threshold for wake-up engine 2.
+
+ st,highpass-cutoff-hz:
+ enum: [1, 2, 4, 8]
+ description: High-pass filter cut-off frequency in Hz.
+
+ st,hipass1-disable:
+ type: boolean
+ description: Disable high-pass filter 1.
+
+ st,hipass2-disable:
+ type: boolean
+ description: Disable high-pass filter 2.
+
+ st,axis-x:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: |
+ Map physical X axis. Negative values invert the direction.
+ Valid range -3 to 3, excluding 0.
+
+ st,axis-y:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: |
+ Map physical Y axis. Negative values invert the direction.
+ Valid range -3 to 3, excluding 0.
+
+ st,axis-z:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: |
+ Map physical Z axis. Negative values invert the direction.
+ Valid range -3 to 3, excluding 0.
+
+ st,default-rate:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Default output data rate in Hz.
+
+ st,min-limit-x:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: Minimum self-test limit for X axis.
+
+ st,min-limit-y:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: Minimum self-test limit for Y axis.
+
+ st,min-limit-z:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: Minimum self-test limit for Z axis.
+
+ st,max-limit-x:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: Maximum self-test limit for X axis.
+
+ st,max-limit-y:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: Maximum self-test limit for Y axis.
+
+ st,max-limit-z:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: Maximum self-test limit for Z axis.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - st,lis302dl-spi
+ then:
+ required:
+ - spi-max-frequency
+ - interrupts
+ - if:
+ properties:
+ compatible:
+ enum:
+ - st,lis3lv02d
+ then:
+ required:
+ - Vdd-supply
+ - Vdd_IO-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ accelerometer@0 {
+ compatible = "st,lis302dl-spi";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ interrupt-parent = <&gpio>;
+ interrupts = <104 IRQ_TYPE_EDGE_RISING>;
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,click-threshold-x = <10>;
+ st,click-threshold-y = <10>;
+ st,click-threshold-z = <10>;
+ st,irq1-click;
+ st,irq2-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ };
+ };
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ accelerometer@18 {
+ compatible = "st,lis3lv02d";
+ reg = <0x18>;
+ Vdd-supply = <&lis3_reg>;
+ Vdd_IO-supply = <&lis3_reg>;
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,click-threshold-x = <10>;
+ st,click-threshold-y = <10>;
+ st,click-threshold-z = <10>;
+ st,irq1-click;
+ st,irq2-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ st,min-limit-x = <120>;
+ st,min-limit-y = <120>;
+ st,min-limit-z = <140>;
+ st,max-limit-x = <550>;
+ st,max-limit-y = <550>;
+ st,max-limit-z = <750>;
+ };
+ };
+...
--
2.51.1
^ permalink raw reply related
* Re: [PATCH 2/3] mfd: 88pm886: Initialize battery page
From: Lee Jones @ 2026-06-10 10:58 UTC (permalink / raw)
To: Duje Mihanović
Cc: Karel Balej, devicetree, phone-devel, ~postmarketos/upstreaming,
linux-kernel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown
In-Reply-To: <ZyFElwT1QjOADA-7NXdGRw@gmail.com>
On Mon, 08 Jun 2026, Duje Mihanović wrote:
> On Monday, 8 June 2026 10:55:24 Central European Summer Time Lee Jones wrote:
> > On Sun, 07 Jun 2026, Duje Mihanović wrote:
>
> [...]
>
> > > Lee, do you by chance know how to proceed here?
> >
> > You can move them.
> >
> > Please take into consideration data-size as well, rather than blindly
> > following RCT. Larger items (structs) at the top down to smaller (ints
> > and bools) as the bottom. Luckily the larger (data size) items also end
> > up being longer (string).
>
> Am I to consider the sizes of the pointers or the structs they point to?
No - group all structs in RCT.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v4 2/3] arm: dts: nuvoton: npcm7xx: Drop redundant FIU clock-names
From: Andrew Jeffery @ 2026-06-10 10:49 UTC (permalink / raw)
To: Tomer Maimon, broonie, robh, krzk+dt, conor+dt
Cc: openbmc, linux-spi, devicetree, linux-kernel, avifishman70,
tali.perry1, venture, yuenn, benjaminfair
In-Reply-To: <20260609163919.3321228-3-tmaimon77@gmail.com>
On Tue, 2026-06-09 at 19:39 +0300, Tomer Maimon wrote:
> The NPCM7xx FIU controller driver gets its single clock with
> devm_clk_get_enabled(dev, NULL) and does not perform a named
> clock lookup. Drop the redundant clock-names properties from the
> FIU controller nodes so the DTS describes only the resources the
> driver actually uses.
The devicetree is a description of the hardware in the form documented
by the bindings. Generally it's not right to discuss Linux drivers
here: they're only relevant in the context of Linux, but the devicetree
binding governs devicetrees over multiple projects.
From a quick look it seems that these names are not described in the
corresponding binding, therefore no drivers should be using them and as
such they can (and should) be dropped. A driver would only be worth
mentioning if it did use the undocumented names (as that would be a
complication).
Can you please rework the description?
Andrew
>
> Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
> ---
> arch/arm/boot/dts/nuvoton/nuvoton-common-npcm7xx.dtsi | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/nuvoton/nuvoton-common-npcm7xx.dtsi b/arch/arm/boot/dts/nuvoton/nuvoton-common-npcm7xx.dtsi
> index a16450abea0e..83cd10b47273 100644
> --- a/arch/arm/boot/dts/nuvoton/nuvoton-common-npcm7xx.dtsi
> +++ b/arch/arm/boot/dts/nuvoton/nuvoton-common-npcm7xx.dtsi
> @@ -193,7 +193,6 @@ fiu0: spi@fb000000 {
> reg = <0xfb000000 0x1000>;
> reg-names = "control";
> clocks = <&clk NPCM7XX_CLK_SPI0>;
> - clock-names = "clk_spi0";
> status = "disabled";
> };
>
> @@ -204,7 +203,6 @@ fiu3: spi@c0000000 {
> reg = <0xc0000000 0x1000>;
> reg-names = "control";
> clocks = <&clk NPCM7XX_CLK_SPI3>;
> - clock-names = "clk_spi3";
> pinctrl-names = "default";
> pinctrl-0 = <&spi3_pins>;
> status = "disabled";
> @@ -217,7 +215,6 @@ fiux: spi@fb001000 {
> reg = <0xfb001000 0x1000>;
> reg-names = "control";
> clocks = <&clk NPCM7XX_CLK_SPIX>;
> - clock-names = "clk_spix";
> status = "disabled";
> };
>
^ permalink raw reply
* Re: [net-next 0/9] ravb: Add gPTP support for Gen4
From: Krzysztof Kozlowski @ 2026-06-10 10:47 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
In-Reply-To: <20260610103812.GE2465390@ragnatech.se>
On 10/06/2026 12:38, Niklas Söderlund wrote:
> Hi Krzysztof,
>
> On 2026-06-10 12:27:55 +0200, Krzysztof Kozlowski wrote:
>> On 10/06/2026 12:24, Niklas Söderlund wrote:
>>> Hello,
>>>
>>> This series is the second part cleaning up how PTP timer support is
>>> implemented on R-Car Gen4. Currently there is partial support for it in
>>> some of the Ethernet devices that can use it, but not all.
>>>
>>
>> Second series doing the same...
>>
>> Please use standard email subjects, so with the PATCH keyword in the
>> title. `git format-patch -vX` helps here to create proper versioned
>> patches. Another useful tool is b4. Skipping the PATCH keyword makes
>> filtering of emails more difficult thus making the review process less
>> convenient.
>
> I'm sorry about that, but as this (and the previous) series targets
> netdev where as I understand it the convection is to use net-next, or
> net, to indicate which tree it targets. When not posting to netdev I
> indeed use -vX.
>
> I'm not sure how to resolve these two. Would [PATCH,net-next,vX 0/9]
> make life easier for you?
Look at mailing list - it will guide you. b4 also solves that for you,
so just don't do something completely different.
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox