* Re: [PATCH 2/4] phy: qcom-qusb2: Fix SM6115 init sequence
From: Dmitry Baryshkov @ 2026-06-10 13:20 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Iskren Chernev, Greg Kroah-Hartman,
Bjorn Andersson, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
In-Reply-To: <20260610-topic-8996_61x5_qusb2phy-v1-2-d7135980e78f@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 02:04:15PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> I don't know where the existing one came from, but it's apparently
> wrong, according to both docs and a downstream DT [1]. Fix it up.
>
> The updated values also happen to match SM6125, which will allow us
> to fix that platform too.
>
> [1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/bengal-usb.dtsi#145
> Fixes: 7756f1d6369e ("phy: qcom-qusb2: Add configuration for SM4250 and SM6115")
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/4] Fix up QUSB2 PHY description for MSM8996/SM61[12]5
From: Dmitry Baryshkov @ 2026-06-10 13:20 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Konrad Dybcio, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng, Iskren Chernev,
Greg Kroah-Hartman, Bjorn Andersson, linux-arm-msm, linux-phy,
devicetree, linux-kernel
In-Reply-To: <852caded-eacf-4ac1-8fe5-83dd9285ef11@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 03:13:01PM +0200, Konrad Dybcio wrote:
> On 6/10/26 3:03 PM, Dmitry Baryshkov wrote:
> > On Wed, Jun 10, 2026 at 02:49:31PM +0200, Konrad Dybcio wrote:
> >> On 6/10/26 2:04 PM, Konrad Dybcio wrote:
> >>> The MSM8996 QUSB2PHY was not being guaranteed a power source.
> >>> The SM6125's QUSB2PHY was believed to be idential as the 96 one. It
> >>> wasn't. This series tackles that, freeing us of some dt checker
> >>> errors about vdd-supply not found on MSM8996 boards.
> >>>
> >>> Compile-tested only, but docs confirm my findings..
> >>>
> >>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> >>> ---
> >>> Konrad Dybcio (4):
> >>> dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
> >>> phy: qcom-qusb2: Fix SM6115 init sequence
> >>> arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs
> >>> arm64: dts: qcom: sm6125: Fix QUSB2 compatible
> >>>
> >>> .../devicetree/bindings/phy/qcom,qusb2-phy.yaml | 31 ++++++++++++++++++++--
> >>> arch/arm64/boot/dts/qcom/msm8996.dtsi | 10 +++++++
> >>> arch/arm64/boot/dts/qcom/sm6125.dtsi | 3 ++-
> >>> drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 +--
> >>> 4 files changed, 43 insertions(+), 5 deletions(-)
> >>> ---
> >>
> >> Note that msm8996pro may need even more looking into, but that's a
> >> story for another day
> >
> > JFYI, MSM8996 Pro is being used in the DRM / Mesa CI. If there is an
> > important difference, it would be nice to get it sorted out too.
>
> reg 96 pro
> 0x80 0xF8 0xD0 [!] QUSB2PHY_PORT_TUNE1
> 0x84 0xB3 0xB3
> 0x88 0x83 0x83
> 0x8C 0xC0 0xC0
> 0x90 none 0x02 [!] QUSB2PHY_PORT_TUNE5
> 0x08 0x30 0x30
> 0x0C 0x79 0x79
> 0x10 0x21 0x21
> 0x9C 0x14 0x14
> 0x1C 0x9F 0x9F
> 0x18 0x00 0x00
>
> apparently this is indeed SoC-specific (via docs) but also apparently
> may not be very important (although should be fixed regardless as
> some designs may rely on this)
Would you send a patch, please?
>
> Konrad
>
> --
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/4] Fix up QUSB2 PHY description for MSM8996/SM61[12]5
From: Konrad Dybcio @ 2026-06-10 13:13 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Konrad Dybcio, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng, Iskren Chernev,
Greg Kroah-Hartman, Bjorn Andersson, linux-arm-msm, linux-phy,
devicetree, linux-kernel
In-Reply-To: <cnyhnyoce6v4d5roijrceuzd3ujvvw7ozklulaxkibptvjancm@cqbqu2aa7bz6>
On 6/10/26 3:03 PM, Dmitry Baryshkov wrote:
> On Wed, Jun 10, 2026 at 02:49:31PM +0200, Konrad Dybcio wrote:
>> On 6/10/26 2:04 PM, Konrad Dybcio wrote:
>>> The MSM8996 QUSB2PHY was not being guaranteed a power source.
>>> The SM6125's QUSB2PHY was believed to be idential as the 96 one. It
>>> wasn't. This series tackles that, freeing us of some dt checker
>>> errors about vdd-supply not found on MSM8996 boards.
>>>
>>> Compile-tested only, but docs confirm my findings..
>>>
>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>> ---
>>> Konrad Dybcio (4):
>>> dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
>>> phy: qcom-qusb2: Fix SM6115 init sequence
>>> arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs
>>> arm64: dts: qcom: sm6125: Fix QUSB2 compatible
>>>
>>> .../devicetree/bindings/phy/qcom,qusb2-phy.yaml | 31 ++++++++++++++++++++--
>>> arch/arm64/boot/dts/qcom/msm8996.dtsi | 10 +++++++
>>> arch/arm64/boot/dts/qcom/sm6125.dtsi | 3 ++-
>>> drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 +--
>>> 4 files changed, 43 insertions(+), 5 deletions(-)
>>> ---
>>
>> Note that msm8996pro may need even more looking into, but that's a
>> story for another day
>
> JFYI, MSM8996 Pro is being used in the DRM / Mesa CI. If there is an
> important difference, it would be nice to get it sorted out too.
reg 96 pro
0x80 0xF8 0xD0 [!] QUSB2PHY_PORT_TUNE1
0x84 0xB3 0xB3
0x88 0x83 0x83
0x8C 0xC0 0xC0
0x90 none 0x02 [!] QUSB2PHY_PORT_TUNE5
0x08 0x30 0x30
0x0C 0x79 0x79
0x10 0x21 0x21
0x9C 0x14 0x14
0x1C 0x9F 0x9F
0x18 0x00 0x00
apparently this is indeed SoC-specific (via docs) but also apparently
may not be very important (although should be fixed regardless as
some designs may rely on this)
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/4] Fix up QUSB2 PHY description for MSM8996/SM61[12]5
From: Dmitry Baryshkov @ 2026-06-10 13:03 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Konrad Dybcio, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng, Iskren Chernev,
Greg Kroah-Hartman, Bjorn Andersson, linux-arm-msm, linux-phy,
devicetree, linux-kernel
In-Reply-To: <b05e860e-ace5-4399-bbd9-493f7bbfe74d@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 02:49:31PM +0200, Konrad Dybcio wrote:
> On 6/10/26 2:04 PM, Konrad Dybcio wrote:
> > The MSM8996 QUSB2PHY was not being guaranteed a power source.
> > The SM6125's QUSB2PHY was believed to be idential as the 96 one. It
> > wasn't. This series tackles that, freeing us of some dt checker
> > errors about vdd-supply not found on MSM8996 boards.
> >
> > Compile-tested only, but docs confirm my findings..
> >
> > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > ---
> > Konrad Dybcio (4):
> > dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
> > phy: qcom-qusb2: Fix SM6115 init sequence
> > arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs
> > arm64: dts: qcom: sm6125: Fix QUSB2 compatible
> >
> > .../devicetree/bindings/phy/qcom,qusb2-phy.yaml | 31 ++++++++++++++++++++--
> > arch/arm64/boot/dts/qcom/msm8996.dtsi | 10 +++++++
> > arch/arm64/boot/dts/qcom/sm6125.dtsi | 3 ++-
> > drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 +--
> > 4 files changed, 43 insertions(+), 5 deletions(-)
> > ---
>
> Note that msm8996pro may need even more looking into, but that's a
> story for another day
JFYI, MSM8996 Pro is being used in the DRM / Mesa CI. If there is an
important difference, it would be nice to get it sorted out too.
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/4] phy: qcom-qusb2: Fix SM6115 init sequence
From: Abel Vesa @ 2026-06-10 12:57 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Iskren Chernev, Greg Kroah-Hartman,
Bjorn Andersson, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
In-Reply-To: <20260610-topic-8996_61x5_qusb2phy-v1-2-d7135980e78f@oss.qualcomm.com>
On 26-06-10 14:04:15, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> I don't know where the existing one came from, but it's apparently
> wrong, according to both docs and a downstream DT [1]. Fix it up.
>
> The updated values also happen to match SM6125, which will allow us
> to fix that platform too.
>
> [1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/bengal-usb.dtsi#145
> Fixes: 7756f1d6369e ("phy: qcom-qusb2: Add configuration for SM4250 and SM6115")
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: sm6125: Fix QUSB2 compatible
From: Dmitry Baryshkov @ 2026-06-10 12:53 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Iskren Chernev, Greg Kroah-Hartman,
Bjorn Andersson, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
In-Reply-To: <20260610-topic-8996_61x5_qusb2phy-v1-4-d7135980e78f@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 02:04:17PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> There are a couple issues with the current description:
>
> 1) The msm8996 compatible is wholly reused, without a SM6125-specific
> primary compatible
> 2) MSM8996 has a different power setup (VDD powered through a RPMPD
> power-domain vs a regulator)
> 3) MSM8996 uses a different init sequence
>
> As part of fixing all of them, use a SM6125-specific compatible with a
> SM6115 fallback.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/sm6125.dtsi | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/4] Fix up QUSB2 PHY description for MSM8996/SM61[12]5
From: Konrad Dybcio @ 2026-06-10 12:49 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng, Iskren Chernev,
Greg Kroah-Hartman, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260610-topic-8996_61x5_qusb2phy-v1-0-d7135980e78f@oss.qualcomm.com>
On 6/10/26 2:04 PM, Konrad Dybcio wrote:
> The MSM8996 QUSB2PHY was not being guaranteed a power source.
> The SM6125's QUSB2PHY was believed to be idential as the 96 one. It
> wasn't. This series tackles that, freeing us of some dt checker
> errors about vdd-supply not found on MSM8996 boards.
>
> Compile-tested only, but docs confirm my findings..
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> Konrad Dybcio (4):
> dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
> phy: qcom-qusb2: Fix SM6115 init sequence
> arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs
> arm64: dts: qcom: sm6125: Fix QUSB2 compatible
>
> .../devicetree/bindings/phy/qcom,qusb2-phy.yaml | 31 ++++++++++++++++++++--
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 10 +++++++
> arch/arm64/boot/dts/qcom/sm6125.dtsi | 3 ++-
> drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 +--
> 4 files changed, 43 insertions(+), 5 deletions(-)
> ---
Note that msm8996pro may need even more looking into, but that's a
story for another day
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
From: sashiko-bot @ 2026-06-10 12:25 UTC (permalink / raw)
To: Konrad Dybcio
Cc: vkoul, linux-phy, neil.armstrong, olteanv, robh, conor+dt,
devicetree
In-Reply-To: <20260610-topic-8996_61x5_qusb2phy-v1-1-d7135980e78f@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Driver/Schema Mismatch: Driver unconditionally requests 'vdd' regulator while schema removes it for MSM8996
--
commit 3e28a2c0425272ba6818b0dca5f1d04b00a00662
Author: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
This commit adds a specific compatible string for SM6125 with an SM6115
fallback. It also updates the MSM8996 bindings to require power domains
and operating performance points instead of a vdd-supply.
> diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
> index 39851ba9de436..807d64aee547c 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
[ ... ]
> @@ -182,6 +190,22 @@ allOf:
> qcom,preemphasis-width: false
> qcom,hsdisc-trim-value: false
>
> + # On MSM8996, VDD is supplied via the MX power domain
> + - if:
> + properties:
> + compatible:
> + const: qcom,msm8996-qusb2-phy
> + then:
> + required:
> + - power-domains
> + - required-opps
> + else:
> + properties:
> + power-domains: false
> + required-opps: false
> + required:
> + - vdd-supply
[ ... ]
> @@ -196,10 +220,13 @@ examples:
> <&gcc GCC_RX1_USB2_CLKREF_CLK>;
> clock-names = "cfg_ahb", "ref";
>
> - vdd-supply = <&pm8994_l28>;
[Severity: Medium]
Does this removal of vdd-supply for MSM8996 create a mismatch with the
existing qusb2 driver?
Looking at qusb2_phy_probe() in drivers/phy/qualcomm/phy-qcom-qusb2.c, the
driver unconditionally requests all regulators defined in
qusb2_phy_vreg_names, which includes the vdd supply:
drivers/phy/qualcomm/phy-qcom-qusb2.c:qusb2_phy_probe()
num = ARRAY_SIZE(qphy->vregs);
for (i = 0; i < num; i++)
qphy->vregs[i].supply = qusb2_phy_vreg_names[i];
ret = devm_regulator_bulk_get(dev, num, qphy->vregs);
If a device tree omits vdd-supply to follow this new schema intent, will
the driver fail to probe with -ENODEV or log an unwanted warning when
falling back to a dummy regulator?
Should the driver be updated to handle the vdd regulator as optional for
hardware variants that use power domains?
> vdda-pll-supply = <&pm8994_l12>;
> vdda-phy-dpdm-supply = <&pm8994_l24>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-topic-8996_61x5_qusb2phy-v1-0-d7135980e78f@oss.qualcomm.com?part=1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 7/9] arm64: dts: qcom: hamoa: reorder csiphy power-domains for v8 CSI2-PHY
From: Bryan O'Donoghue @ 2026-06-10 12:24 UTC (permalink / raw)
To: Ramshouriesh, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy
In-Reply-To: <20260610-a14-himax-hm1092-v1-7-0c9907da47ed@gmail.com>
On 10/06/2026 12:09, Ramshouriesh wrote:
> The v8 phy-qcom-mipi-csi2 binding mandates power-domain-names ordered
> "mmcx", "mx" (MMCX first)
Feels like it probably shouldn't.
strings > magic indexes. Thanks for finding.
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 4/9] MAINTAINERS: add entry for the Himax HM1092 sensor driver
From: Bryan O'Donoghue @ 2026-06-10 12:24 UTC (permalink / raw)
To: Ramshouriesh, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy
In-Reply-To: <20260610-a14-himax-hm1092-v1-4-0c9907da47ed@gmail.com>
On 10/06/2026 12:09, Ramshouriesh wrote:
> 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
>
Splitting this will cause checkpatch grumbles.
Squash down into the previous patch.
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/9] media: dt-bindings: Add Himax HM1092 NIR sensor
From: Bryan O'Donoghue @ 2026-06-10 12:21 UTC (permalink / raw)
To: Ramshouriesh, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy
In-Reply-To: <20260610-a14-himax-hm1092-v1-2-0c9907da47ed@gmail.com>
On 10/06/2026 12:09, Ramshouriesh wrote:
> 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>
Firstname/lastname ?
> ---
> .../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>;
You probably mean data-lanes = <1 2> here no ?
> + link-frequencies = /bits/ 64 <400000000>;
> + remote-endpoint = <&camss_csiphy0_inep>;
> + };
> + };
> + };
> + };
> +...
>
> --
> 2.53.0
>
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs
From: sashiko-bot @ 2026-06-10 12:18 UTC (permalink / raw)
To: Konrad Dybcio
Cc: vkoul, neil.armstrong, olteanv, linux-phy, robh, conor+dt,
devicetree
In-Reply-To: <20260610-topic-8996_61x5_qusb2phy-v1-3-d7135980e78f@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Adding the VDD_MX power domain interacts brokenly with the PHY driver's runtime PM implementation, permanently pinning the VDD_MX power rail and causing a severe battery drain regression during system idle.
--
commit f3735b6dfcc42f0f55443d0f81c7b256532b0e25
Author: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs
This commit adds the VDD_MX power rail description to the QUSB2 PHYs in the
msm8996 device tree. It explicitly sets the power domain and required OPPs
for both primary and secondary PHY nodes.
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 2f67e665996f3..b7cd1928335c8 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -3192,7 +3192,12 @@ hsusb_phy1: phy@7411000 {
> clock-names = "cfg_ahb", "ref";
>
> resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
> +
> + power-domains = <&rpmpd MSM8996_VDDMX>;
> + required-opps = <&rpmpd_opp4>;
[Severity: High]
Does adding this power domain permanently pin the VDD_MX rail?
Looking at the driver in drivers/phy/qualcomm/phy-qcom-qusb2.c,
qusb2_phy_probe() sets up runtime PM like this:
pm_runtime_set_active(dev);
pm_runtime_forbid(dev);
ret = devm_pm_runtime_enable(dev);
Because the driver forbids runtime suspend by default, the device stays
permanently active.
If we attach the PM domain and require an OPP here, won't the generic PM
domain framework apply the OPP4 performance state permanently, preventing the
SoC from scaling down its logic voltage during system idle?
> +
> nvmem-cells = <&qusb2p_hstx_trim>;
> +
> status = "disabled";
> };
>
> @@ -3206,7 +3211,12 @@ hsusb_phy2: phy@7412000 {
> clock-names = "cfg_ahb", "ref";
>
> resets = <&gcc GCC_QUSB2PHY_SEC_BCR>;
> +
> + power-domains = <&rpmpd MSM8996_VDDMX>;
> + required-opps = <&rpmpd_opp4>;
> +
> nvmem-cells = <&qusb2s_hstx_trim>;
> +
> status = "disabled";
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-topic-8996_61x5_qusb2phy-v1-0-d7135980e78f@oss.qualcomm.com?part=3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 6/9] arm64: dts/media: qcom: keep PLL8 out of Purwa camss hot path
From: Krzysztof Kozlowski @ 2026-06-10 12:13 UTC (permalink / raw)
To: Ramshouriesh, 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
In-Reply-To: <20260610-a14-himax-hm1092-v1-6-0c9907da47ed@gmail.com>
On 10/06/2026 13:09, Ramshouriesh wrote:
> 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 ++++++++--------
You cannot combine such changes. DTS must be separate, see submitting
patches in DT, DTS coding style, SoC maintainer profile...
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/9] media: i2c: hm1092: add Himax HM1092 mono NIR sensor driver
From: Bryan O'Donoghue @ 2026-06-10 12:11 UTC (permalink / raw)
To: Ramshouriesh, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy
In-Reply-To: <20260610-a14-himax-hm1092-v1-3-0c9907da47ed@gmail.com>
On 10/06/2026 12:09, Ramshouriesh wrote:
> 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.
Drop references to PM8550 as its a qcomism and this is a i2c sensor.
>
> Signed-off-by: Ramshouriesh <rshouriesh@gmail.com>
And I think you can/should reference a series where this driver is used
but split the driver submission itself from the SoC/platform specific.
You want to target Sakari's tree - land the driver then enable the
platform code on top, so structure your patchworking around that strategy.
> ---
> 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.
Not specific to Qcom - sensor vendors target ISP vendors like Intel,
Qcom and others. You might easily say the same "this is used in IPU7"
for this sensor for all we know.
> +
> + 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;
reverse
xmas
tree for preference.
> +
> + 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;
This seems strange. Like you're returning zero for an error case.
> +
> + 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;
> + }
You have a hard-coded init sequence - does it really support both one
and two lane mode ?
Seems unlikely.
> +
> + 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;
\n> + usleep_range(3000, 3500);
Your comment says 1 ms so it needs an update.
> +
> + 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 */
Does checkpatch accept a comment on a line like that ?
> +
> + 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);
\n> + 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);
if (freq != ) {
// stuff goes here
}
> +
> + 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
This is great data.
> + * DO NOT HAND EDIT — regenerate from the bin.
This is not to be included in upstream though.
> + */
> +
> +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
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 4/4] arm64: dts: qcom: sm6125: Fix QUSB2 compatible
From: Konrad Dybcio @ 2026-06-10 12:04 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Iskren Chernev, Greg Kroah-Hartman,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260610-topic-8996_61x5_qusb2phy-v1-0-d7135980e78f@oss.qualcomm.com>
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
There are a couple issues with the current description:
1) The msm8996 compatible is wholly reused, without a SM6125-specific
primary compatible
2) MSM8996 has a different power setup (VDD powered through a RPMPD
power-domain vs a regulator)
3) MSM8996 uses a different init sequence
As part of fixing all of them, use a SM6125-specific compatible with a
SM6115 fallback.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm6125.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi b/arch/arm64/boot/dts/qcom/sm6125.dtsi
index 6e84c226948c..688548cef0f1 100644
--- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
@@ -681,7 +681,8 @@ gcc: clock-controller@1400000 {
};
hsusb_phy1: phy@1613000 {
- compatible = "qcom,msm8996-qusb2-phy";
+ compatible = "qcom,sm6125-qusb2-phy",
+ "qcom,sm6115-qusb2-phy";
reg = <0x01613000 0x180>;
#phy-cells = <0>;
--
2.54.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs
From: Konrad Dybcio @ 2026-06-10 12:04 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Iskren Chernev, Greg Kroah-Hartman,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260610-topic-8996_61x5_qusb2phy-v1-0-d7135980e78f@oss.qualcomm.com>
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
The QUSB2 PHYs are powered by (among others) the VDD_MX power rail.
Describe that in the DT.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 2f67e665996f..b7cd1928335c 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -3192,7 +3192,12 @@ hsusb_phy1: phy@7411000 {
clock-names = "cfg_ahb", "ref";
resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
+
+ power-domains = <&rpmpd MSM8996_VDDMX>;
+ required-opps = <&rpmpd_opp4>;
+
nvmem-cells = <&qusb2p_hstx_trim>;
+
status = "disabled";
};
@@ -3206,7 +3211,12 @@ hsusb_phy2: phy@7412000 {
clock-names = "cfg_ahb", "ref";
resets = <&gcc GCC_QUSB2PHY_SEC_BCR>;
+
+ power-domains = <&rpmpd MSM8996_VDDMX>;
+ required-opps = <&rpmpd_opp4>;
+
nvmem-cells = <&qusb2s_hstx_trim>;
+
status = "disabled";
};
--
2.54.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 2/4] phy: qcom-qusb2: Fix SM6115 init sequence
From: Konrad Dybcio @ 2026-06-10 12:04 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Iskren Chernev, Greg Kroah-Hartman,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260610-topic-8996_61x5_qusb2phy-v1-0-d7135980e78f@oss.qualcomm.com>
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
I don't know where the existing one came from, but it's apparently
wrong, according to both docs and a downstream DT [1]. Fix it up.
The updated values also happen to match SM6125, which will allow us
to fix that platform too.
[1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/bengal-usb.dtsi#145
Fixes: 7756f1d6369e ("phy: qcom-qusb2: Add configuration for SM4250 and SM6115")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index eb93015be841..c304ccd9f31f 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -233,9 +233,9 @@ static const struct qusb2_phy_init_tbl msm8998_init_tbl[] = {
static const struct qusb2_phy_init_tbl sm6115_init_tbl[] = {
QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE1, 0xf8),
- QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE2, 0x53),
+ QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE2, 0xb3),
QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE3, 0x81),
- QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE4, 0x17),
+ QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE4, 0xc0),
QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_TUNE, 0x30),
QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL1, 0x79),
--
2.54.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
From: Konrad Dybcio @ 2026-06-10 12:04 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Iskren Chernev, Greg Kroah-Hartman,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260610-topic-8996_61x5_qusb2phy-v1-0-d7135980e78f@oss.qualcomm.com>
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
SM6125 DT currently uses just the MSM8996 compatible (without a primary
SM6125-specific one). This is not only wrong for the reasons of
violating guidelines, but also happens to not be valid.
The MSM8996 PHY is quite similar, although it requies a different init
sequence (for arch reasons). MSM8996 also needs different power
plumbing, as the VDD supply is fed through VDD_MX (which we define as
a power domain rather than a regulator), unlike on SM6125.
The init sequence seems to have been "good enough", but now that the
bindings clearly diverge, add a new compatible for SM6125 with a SM6115
fallback (as they seem to be an exact match from the SW interface POV).
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
.../devicetree/bindings/phy/qcom,qusb2-phy.yaml | 31 ++++++++++++++++++++--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
index 39851ba9de43..807d64aee547 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
@@ -30,6 +30,9 @@ properties:
- qcom,sdm660-qusb2-phy
- qcom,sm4250-qusb2-phy
- qcom,sm6115-qusb2-phy
+ - items:
+ - const: qcom,sm6125-qusb2-phy
+ - const: qcom,sm6115-qusb2-phy
- items:
- enum:
- qcom,sc7180-qusb2-phy
@@ -57,6 +60,12 @@ properties:
- const: ref
- const: iface
+ power-domains:
+ maxItems: 1
+
+ required-opps:
+ maxItems: 1
+
vdd-supply:
description:
Phandle to 0.9V regulator supply to PHY digital circuit.
@@ -160,7 +169,6 @@ required:
- "#phy-cells"
- clocks
- clock-names
- - vdd-supply
- vdda-pll-supply
- vdda-phy-dpdm-supply
- resets
@@ -182,6 +190,22 @@ allOf:
qcom,preemphasis-width: false
qcom,hsdisc-trim-value: false
+ # On MSM8996, VDD is supplied via the MX power domain
+ - if:
+ properties:
+ compatible:
+ const: qcom,msm8996-qusb2-phy
+ then:
+ required:
+ - power-domains
+ - required-opps
+ else:
+ properties:
+ power-domains: false
+ required-opps: false
+ required:
+ - vdd-supply
+
additionalProperties: false
examples:
@@ -196,10 +220,13 @@ examples:
<&gcc GCC_RX1_USB2_CLKREF_CLK>;
clock-names = "cfg_ahb", "ref";
- vdd-supply = <&pm8994_l28>;
vdda-pll-supply = <&pm8994_l12>;
vdda-phy-dpdm-supply = <&pm8994_l24>;
resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
+
+ power-domains = <&rpmpd_mx>;
+ required-opps = <&rpmpd_opp4>;
+
nvmem-cells = <&qusb2p_hstx_trim>;
};
--
2.54.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 0/4] Fix up QUSB2 PHY description for MSM8996/SM61[12]5
From: Konrad Dybcio @ 2026-06-10 12:04 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Iskren Chernev, Greg Kroah-Hartman,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Konrad Dybcio
The MSM8996 QUSB2PHY was not being guaranteed a power source.
The SM6125's QUSB2PHY was believed to be idential as the 96 one. It
wasn't. This series tackles that, freeing us of some dt checker
errors about vdd-supply not found on MSM8996 boards.
Compile-tested only, but docs confirm my findings..
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
Konrad Dybcio (4):
dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
phy: qcom-qusb2: Fix SM6115 init sequence
arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs
arm64: dts: qcom: sm6125: Fix QUSB2 compatible
.../devicetree/bindings/phy/qcom,qusb2-phy.yaml | 31 ++++++++++++++++++++--
arch/arm64/boot/dts/qcom/msm8996.dtsi | 10 +++++++
arch/arm64/boot/dts/qcom/sm6125.dtsi | 3 ++-
drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 +--
4 files changed, 43 insertions(+), 5 deletions(-)
---
base-commit: 49e02880ec0a8c378e811bc9d85da188d7c6204c
change-id: 20260610-topic-8996_61x5_qusb2phy-ad052b99e9de
Best regards,
--
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 2/2] phy: qcom-qmp-pcie: Add support for ipq5210 PCIe phys
From: Varadarajan Narayanan @ 2026-06-10 11:16 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Varadarajan Narayanan
In-Reply-To: <20260610-pcie-phy-v3-0-334011b378d6@oss.qualcomm.com>
Add support for a PCIe phys found on Qualcomm ipq5210 platform.
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 129 +++++++++++++++++++++++++++++++
1 file changed, 129 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index 75afbd15aaf4..2bf00e0e125a 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -514,6 +514,89 @@ static const struct qmp_phy_init_tbl ipq8074_pcie_gen3_pcs_misc_tbl[] = {
QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_ENDPOINT_REFCLK_DRIVE, 0xc1),
};
+static const struct qmp_phy_init_tbl ipq5210_gen3x1_pcie_ep_serdes_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_PLL_BG_TIMER, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CLKBUFLR_EN, 0x18),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_SYSCLK_BUF_ENABLE, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_IVCO, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP1_MODE0, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP2_MODE0, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP1_MODE1, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP2_MODE1, 0x09),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_BG_TRIM, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_CP_CTRL_MODE0, 0x23),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_CP_CTRL_MODE1, 0x23),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_RCTRL_MODE0, 0x10),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_RCTRL_MODE1, 0x10),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_CCTRL_MODE0, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_CCTRL_MODE1, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CTRL_BY_PSM, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_SYSCLK_EN_SEL, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_RESETSM_CNTRL, 0x20),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP_EN, 0x42),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_DEC_START_MODE0, 0x19),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_DEC_START_MODE1, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN0_MODE0, 0xfe),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN1_MODE0, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN0_MODE1, 0xfe),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN1_MODE1, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE1_MODE0, 0x24),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE2_MODE0, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE1_MODE1, 0xb4),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE2_MODE1, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_HSCLK_SEL, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_CORE_CLK_EN, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_CMN_CONFIG, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_SVS_MODE_CLK_SEL, 0x05),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_CORECLK_DIV_MODE1, 0x08),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_SYS_CLK_CTRL, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_SYSCLK_EN_SEL, 0x10),
+};
+
+static const struct qmp_phy_init_tbl ipq5210_gen3x1_pcie_ep_rx_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FO_GAIN, 0x0c),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_GAIN, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x7f),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_PI_CONTROLS, 0x70),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL2, 0x61),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL3, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL4, 0x1e),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_IDAC_TSETTLE_LOW, 0xc0),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_IDAC_TSETTLE_HIGH, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQ_OFFSET_ADAPTOR_CNTRL1, 0x73),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_OFFSET_ADAPTOR_CNTRL2, 0x80),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_ENABLES, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_DEGLITCH_CNTRL, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_LOW, 0xf0),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH2, 0x2f),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH3, 0xd3),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH4, 0x40),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_LOW, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH2, 0xc8),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH3, 0x09),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH4, 0xb1),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_LOW, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH2, 0xc8),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH3, 0x09),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH4, 0xb1),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_DFE_EN_TIMER, 0x04),
+};
+
+static const struct qmp_phy_init_tbl ipq5210_gen3x1_pcie_ep_pcs_misc_tbl[] = {
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_POWER_STATE_CONFIG2, 0x04),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_POWER_STATE_CONFIG4, 0x07),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_L1P1_WAKEUP_DLY_TIME_AUXCLK_L, 0x01),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_L1P2_WAKEUP_DLY_TIME_AUXCLK_L, 0x01),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_EQ_CONFIG1, 0x11),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_PRESET_P10_PRE, 0x00),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_PRESET_P10_POST, 0x58),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_OSC_DTCT_CONFIG1, 0x02),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_OSC_DTCT_CONFIG4, 0xff),
+};
+
static const struct qmp_phy_init_tbl ipq9574_gen3x1_pcie_serdes_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CLKBUFLR_EN, 0x18),
QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CTRL_BY_PSM, 0x01),
@@ -3613,6 +3696,49 @@ static const struct qmp_phy_cfg ipq6018_pciephy_cfg = {
.phy_status = PHYSTATUS,
};
+static const struct qmp_phy_cfg ipq5210_gen3x1_pciephy_cfg = {
+ .lanes = 1,
+
+ .offsets = &qmp_pcie_offsets_v4x1,
+
+ .tbls = {
+ .serdes = ipq9574_gen3x1_pcie_serdes_tbl,
+ .serdes_num = ARRAY_SIZE(ipq9574_gen3x1_pcie_serdes_tbl),
+ .tx = ipq8074_pcie_gen3_tx_tbl,
+ .tx_num = ARRAY_SIZE(ipq8074_pcie_gen3_tx_tbl),
+ .rx = ipq9574_pcie_rx_tbl,
+ .rx_num = ARRAY_SIZE(ipq9574_pcie_rx_tbl),
+ .pcs = ipq9574_gen3x1_pcie_pcs_tbl,
+ .pcs_num = ARRAY_SIZE(ipq9574_gen3x1_pcie_pcs_tbl),
+ .pcs_misc = ipq9574_gen3x1_pcie_pcs_misc_tbl,
+ .pcs_misc_num = ARRAY_SIZE(ipq9574_gen3x1_pcie_pcs_misc_tbl),
+ },
+
+ .tbls_ep = &(const struct qmp_phy_cfg_tbls) {
+ .serdes = ipq5210_gen3x1_pcie_ep_serdes_tbl,
+ .serdes_num = ARRAY_SIZE(ipq5210_gen3x1_pcie_ep_serdes_tbl),
+ .tx = ipq6018_pcie_tx_tbl,
+ .tx_num = ARRAY_SIZE(ipq6018_pcie_tx_tbl),
+ .rx = ipq5210_gen3x1_pcie_ep_rx_tbl,
+ .rx_num = ARRAY_SIZE(ipq5210_gen3x1_pcie_ep_rx_tbl),
+ .pcs = ipq6018_pcie_pcs_tbl,
+ .pcs_num = ARRAY_SIZE(ipq6018_pcie_pcs_tbl),
+ .pcs_misc = ipq5210_gen3x1_pcie_ep_pcs_misc_tbl,
+ .pcs_misc_num = ARRAY_SIZE(ipq5210_gen3x1_pcie_ep_pcs_misc_tbl),
+ },
+
+ .reset_list = ipq8074_pciephy_reset_l,
+ .num_resets = ARRAY_SIZE(ipq8074_pciephy_reset_l),
+ .vreg_list = NULL,
+ .num_vregs = 0,
+ .regs = pciephy_v4_regs_layout,
+
+ .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
+ .phy_status = PHYSTATUS,
+
+ .pipe_clock_rate = 250000000,
+};
+
static const struct qmp_phy_cfg ipq9574_gen3x1_pciephy_cfg = {
.lanes = 1,
@@ -5404,6 +5530,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
}, {
.compatible = "qcom,glymur-qmp-gen5x4-pcie-phy",
.data = &glymur_qmp_gen5x4_pciephy_cfg,
+ }, {
+ .compatible = "qcom,ipq5210-qmp-gen3x1-pcie-phy",
+ .data = &ipq5210_gen3x1_pciephy_cfg,
}, {
.compatible = "qcom,ipq6018-qmp-pcie-phy",
.data = &ipq6018_pciephy_cfg,
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHY
From: Varadarajan Narayanan @ 2026-06-10 11:16 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Varadarajan Narayanan
In-Reply-To: <20260610-pcie-phy-v3-0-334011b378d6@oss.qualcomm.com>
Document the PCIe phys on the ipq5210 platform. The 2 lane phy uses the
ipq9574 as fallback. The single lane phy is documented separately.
The ipq5210 has one dual lane and one single lane PCIe phy.
The dual lane phy is similar to the dual lane phy present in ipq9574. Hence
qcom,ipq5210-qmp-gen3x2-pcie-phy is documented with ipq9574's dual lane phy
as fallback compatible.
The single lane phy (qcom,ipq5210-qmp-gen3x1-pcie-phy) is documented as
specific compatible.
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
index f60804687412..fc155ad5fa6d 100644
--- a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
@@ -17,6 +17,7 @@ properties:
compatible:
oneOf:
- enum:
+ - qcom,ipq5210-qmp-gen3x1-pcie-phy
- qcom,ipq6018-qmp-pcie-phy
- qcom,ipq8074-qmp-gen3-pcie-phy
- qcom,ipq8074-qmp-pcie-phy
@@ -28,6 +29,7 @@ properties:
- const: qcom,ipq9574-qmp-gen3x1-pcie-phy
- items:
- enum:
+ - qcom,ipq5210-qmp-gen3x2-pcie-phy
- qcom,ipq5424-qmp-gen3x2-pcie-phy
- const: qcom,ipq9574-qmp-gen3x2-pcie-phy
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 0/2] Enable the QMP PCIe PHY present in Qualcomm ipq5210 SoC
From: Varadarajan Narayanan @ 2026-06-10 11:16 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Varadarajan Narayanan
Document the bindings and update the driver to support
the PCIe phy present in Qualcomm ipq5210 SoC.
v3: Fix commit message for the bindings patch
Remove unused tables from the phy driver (ipq5210_gen3x1_pcie_ep_tx_tbl
and ipq5210_gen3x1_pcie_ep_pcs_tbl)
v2: https://lore.kernel.org/r/20260609-pcie-phy-v2-0-83bc80e79fa6@oss.qualcomm.com
Had incorrectly made both the phys as fallback. The single
lane phy is standalone and double lane uses ipq9574 as
fallback.
v1: https://lore.kernel.org/linux-arm-msm/20260514-pci-phy-v1-0-482429192746@oss.qualcomm.com/
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
Varadarajan Narayanan (2):
dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHY
phy: qcom-qmp-pcie: Add support for ipq5210 PCIe phys
.../bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml | 2 +
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 129 +++++++++++++++++++++
2 files changed, 131 insertions(+)
---
base-commit: a87737435cfa134f9cdcc696ba3080759d04cf72
change-id: 20260609-pcie-phy-99fcf91a02fd
prerequisite-change-id: 20260514-icc-ipq5210-0ab03f3a3e83:v1
prerequisite-patch-id: 0b6145b6635b18fe79fbbff5815041b43778c5ed
prerequisite-patch-id: 924c6ff7baf4283ac7991ee94c803a00fc5cece4
prerequisite-patch-id: c2fe1800fe769dccd37f94c19860a07f979e3c4c
Best regards,
--
Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ 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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ 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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox