* Re: [PATCH v3] dt-bindings: misc: add binding for Xilinx AXI-Stream FIFO
From: Aditya Chari S @ 2026-06-22 4:21 UTC (permalink / raw)
To: Krzysztof Kozlowski, robh, krzk+dt, conor+dt, gregkh
Cc: jacobsfeder, devicetree, linux-staging, linux-kernel,
michal.simek, lucas.fariamo08
In-Reply-To: <548d66ce-d01e-4c6a-a77e-7d61378a1c74@kernel.org>
Sorry about the pace - jumped from automated lint feedback straight to
a new version without waiting for an actual reviewer. Won't happen
again.
On the staging binding question - I found the driver-removal thread
from June 2 and read through it. Michal Simek's reply makes clear this
driver isn't going anywhere (their networking team has plans that
depend on it), and that there's already an in-flight binding
conversion from Lucas Faria Mendes that he's actively tracking. I
wasn't aware of that series when I started this.
Given that, I'll withdraw mine rather than duplicate work that's
already further along and already has the relevant maintainer's eyes
on it.
Thanks for pointing me toward the history.
Regards,
Aditya
^ permalink raw reply
* RE: [PATCH v4 00/16] spi: cadence-quadspi: add PHY tuning support
From: Mahapatra, Amit Kumar @ 2026-06-22 4:30 UTC (permalink / raw)
To: Santhosh Kumar K, broonie@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org,
miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com,
pratyush@kernel.org, mwalle@kernel.org,
takahiro.kuwano@infineon.com
Cc: linux-spi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
praneeth@ti.com, u-kumar1@ti.com, a-dutta@ti.com,
git (AMD-Xilinx), Amit Mohapatra
In-Reply-To: <20260618073725.84733-1-s-k6@ti.com>
AMD General
Hello Santosh,
> -----Original Message-----
> From: Santhosh Kumar K <s-k6@ti.com>
> Sent: Thursday, June 18, 2026 1:07 PM
> To: broonie@kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; miquel.raynal@bootlin.com; richard@nod.at;
> vigneshr@ti.com; pratyush@kernel.org; mwalle@kernel.org;
> takahiro.kuwano@infineon.com
> Cc: linux-spi@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-mtd@lists.infradead.org; praneeth@ti.com; u-
> kumar1@ti.com; a-dutta@ti.com; s-k6@ti.com
> Subject: [PATCH v4 00/16] spi: cadence-quadspi: add PHY tuning support
>
> This series implements PHY tuning support for the Cadence QSPI controller to
> enable reliable high-speed operations. Without PHY tuning, controllers use
> conservative timing that limits performance. PHY tuning calibrates RX/TX delay lines
> to find optimal data capture timing windows, enabling operation up to the controller's
> maximum frequency.
>
> Background:
> High-speed SPI memory controllers require precise timing calibration for reliable
> operation. At higher frequencies, board-to-board variations make fixed timing
> parameters inadequate. The Cadence QSPI controller includes a PHY interface with
> programmable delay lines (0-127 taps) for RX and TX paths, but these require
> runtime calibration to find the valid timing window.
>
> Approach:
> Add SDR/DDR PHY tuning algorithms for the Cadence controller:
>
> SDR Mode Tuning (1D search):
> - Searches for two consecutive valid RX delay windows
> - Selects the larger window and uses its midpoint for maximum margin
> - TX delay fixed at maximum (127) as it's less critical in SDR
>
> DDR Mode Tuning (2D search):
> - Finds RX boundaries (rxlow/rxhigh) using TX window sweeps
> - Finds TX boundaries (txlow/txhigh) at fixed RX positions
> - Defines valid region corners and detects gaps via binary search
> - Applies temperature compensation for optimal point selection
> - Handles single or dual passing regions with different strategies
Thank you for this series. I had a question regarding the Virtual Concat
driver patch series [1]. Now that it has been merged into the kernel and
enables support for multiple flash devices connected in stacked mode-where
each flash device is probed and configured independently-if both flash
parts are required to operate in DDR mode, each device would need to
perform tuning and store its tuning data separately.
Given this, should we consider this use case and adapt the tuning
architecture to support it?
I'd appreciate your thoughts on this.
[1] https://lore.kernel.org/all/20260204-mtd-virt-concat-v17-0-5e98239bb55b@bootlin.com/
Regards,
Amit
>
> Patch description:
> Infrastructure (1-5):
> - Patch 1: Add spi-max-post-config-frequency to describe maximum
> frequency achievable post controller configuration
> - Patch 2: Add spi-phy-pattern-partition phandle for
> NOR flash PHY tuning pattern location
> - Patch 3: Parse spi-max-post-config-frequency in spi.c; adds
> spi_device.post_config_max_speed_hz (0 when not set
> keeping all existing DT fully compatible)
> - Patch 4: Extend spi_mem_adjust_op_freq() with a bypass: if
> op->max_freq equals post_config_max_speed_hz, return
> immediately leaving op->max_freq unchanged. All other
> ops are capped to max_speed_hz
> - Patch 5: Add execute_tuning callback to spi_controller_mem_ops and
> spi_mem_execute_tuning() wrapper in SPI-MEM core
>
> Cadence QSPI Implementation (6-12):
> - Patch 6: Move cqspi_readdata_capture() earlier (preparatory)
> - Patch 7: Add DQS bit to cqspi_readdata_capture() (preparatory)
> - Patch 8: Add complete PHY tuning support: DLL management, pattern
> verification (NOR via spi-phy-pattern-partition phandle,
> NAND via write-to-cache), SDR 1D and DDR 2D search
> algorithms with temperature compensation, AM654-specific
> execute_tuning entry point;
> - Patch 9: Reject 2-byte-address DDR operations via a new
> CQSPI_NO_2BYTE_ADDR_PHY_DDR quirk flag to work around
> AM654 OSPI erratum i2383
> - Patch 10: Refactor direct read path for PHY support (preparatory)
> - Patch 11: Enable PHY for direct reads, split the transfer into an
> unaligned head, a 16-byte-aligned middle section with PHY
> active, and an unaligned tail
> - Patch 12: Enable PHY for indirect writes of at least
> CQSPI_PHY_MIN_INDIRECT_WRITE_LEN bytes
>
> MTD core (13-16):
> - Patch 13: Extract spinand_select_op_variant() into a shared helper
> spinand_op_find_best() with a skip_mask
> - Patch 14: Negotiate optimal PHY operating point before dirmap
> creation
> - Patch 15: Extract spi_nor_spimem_get_read_op() helper (preparatory)
> - Patch 16: Execute PHY tuning in spi_nor_probe() before creating
> dirmaps
>
> Testing:
> This series was tested on TI's
> AM62Ax SK with OSPI NAND flash and
> AM62Px SK with OSPI NOR flash:
>
> Read throughput:
> |----------------------------------------|
> | | non-PHY | PHY |
> |----------------------------------------|
> | OSPI NOR (8D) | 37.5 MB/s | 216 MB/s |
> |----------------------------------------|
> | OSPI NAND (8S) | 9.2 MB/s | 35.1 MB/s |
> |----------------------------------------|
>
> Write throughput:
> |----------------------------------------|
> | | non-PHY | PHY |
> |----------------------------------------|
> | OSPI NAND (8S) | 6 MB/s | 9.2 MB/s |
> |----------------------------------------|
>
> Test log: https://gist.github.com/santhosh21/fe98754e52970287eb9011154100b62d
> Repo: https://github.com/santhosh21/linux/commits/phy_tuning_v4/
>
> Changes in v4:
> - Add spi-max-post-config-frequency instead of extending spi-max-frequency
> to accept an optional second value
> - Replace spi_mem_apply_base_freq_cap() with spi_mem_adjust_op_freq()
> extension
> - For SPI NOR/NAND, execute PHY tuning before the dirmap creation
> - For SPI NAND, execute PHY tuning across all operation variants available,
> perform duration comparison, and select the best resulting variant
> by taking controller-specific restrictions into account
> - Move i2383 check from cqspi_supports_mem_op() to
> cqspi_am654_ospi_execute_tuning()
> - Rename cdns,phy-pattern-partition to spi-phy-pattern-partition,
> cqspi_phy_enable to cqspi_tune_phy and f_pdata->use_phy to use_tuned_phy
> - Remove redundant spi-max-frequency parsing in driver cqspi_of_get_flash_pdata()
> - Extract DMA refactoring into a preparatory patch
> - Rebase on v7.1
> - Collect tags from Miquel
> - Link to v3: https://lore.kernel.org/linux-spi/20260527175527.2247679-1-s-
> k6@ti.com/
>
> Changes in v3:
> - Drop spi-has-dqs DT property; DQS is now enabled automatically when
> the selected read operation uses DDR signalling (dtr flags in the op)
> - Extend spi-max-frequency to accept an optional second value forming a
> [base-freq, max-freq] pair; the presence of two values signals PHY
> tuning intent and encodes both the conservative base speed and the
> calibration target in one property
> - Add base_speed_hz to struct spi_device (spi.c/spi.h) and parse the
> two-element array there; single-value DT is fully backward-compatible
> - Move frequency enforcement from the cadence driver to core: new
> spi_mem_apply_base_freq_cap() called from spi_mem_exec_op() replaces
> the per-driver cqspi_op_matches_tuned() and non_phy_clk_rate field
> - Propagate the tuned max_freq to dirmap op templates after
> execute_tuning() succeeds; store persistent op templates in
> spi_nor.max_read_op and spinand.{max_read,max_write}_op so the
> frequency writeback survives across the probe call
> - Replace NOR pattern partition lookup by name with a
> cdns,phy-pattern-partition DT phandle pointing directly to the
> partition node
> - Add CQSPI_NO_2BYTE_ADDR_PHY_DDR quirk and reject 2-byte-address DDR
> ops in cqspi_supports_mem_op() to work around AM654 erratum i2383
> - Remove RFC tag
> - Rebase on v7.1-rc5
> - Collect tags from Miquel
> - Link to v2: https://lore.kernel.org/linux-spi/20260113141617.1905039-1-s-
> k6@ti.com/
>
> Changes in v2:
> - Restructure the .execute_tuning() call from spi-mem clients instead
> of mtdcore with best read_op and write_op (optional) passed
> - Add compatible-specific .execute_tuning() call which can be called by
> spi_mem_execute_tuning() if exists
> - Handle tuning requirement check by controller instead of spi-mem
> clients
> - Add support to write the phy_pattern to cache if relevant write_op
> is passed or get the partition offset which contains the phy_pattern
> - Add tuning algorithm for DDR mode
> - Add support for DQS
> - Restrict PHY frequency to tuned operations
> - Link to v1: https://lore.kernel.org/linux-spi/20250811193219.731851-1-s-
> k6@ti.com/
>
> Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
>
> Pratyush Yadav (1):
> mtd: spi-nor: extract read op template construction into helper
>
> Santhosh Kumar K (15):
> spi: dt-bindings: add spi-max-post-config-frequency property
> spi: dt-bindings: add spi-phy-pattern-partition property
> spi: parse spi-max-post-config-frequency into post_config_max_speed_hz
> spi: spi-mem: teach spi_mem_adjust_op_freq() about post-config ops
> spi: spi-mem: add execute_tuning callback and spi_mem_execute_tuning()
> spi: cadence-quadspi: move cqspi_readdata_capture earlier
> spi: cadence-quadspi: add DQS support to read data capture
> spi: cadence-quadspi: add PHY tuning support
> spi: cadence-quadspi: skip DDR PHY tuning for 2-byte-address ops
> (i2383)
> spi: cadence-quadspi: refactor direct read path for PHY support
> spi: cadence-quadspi: enable PHY for direct reads
> spi: cadence-quadspi: enable PHY for indirect writes
> mtd: spinand: extract variant ranking logic into
> spinand_op_find_best()
> mtd: spinand: negotiate optimal PHY operating point before dirmap
> creation
> mtd: spi-nor: run PHY tuning after init and update dirmap frequency
>
> .../bindings/spi/cdns,qspi-nor.yaml | 19 +
> .../bindings/spi/spi-peripheral-props.yaml | 13 +
> drivers/mtd/nand/spi/core.c | 246 +-
> drivers/mtd/spi-nor/core.c | 80 +-
> drivers/spi/spi-cadence-quadspi.c | 2265 +++++++++++++++--
> drivers/spi/spi-mem.c | 40 +
> drivers/spi/spi.c | 2 +
> include/linux/mtd/spi-nor.h | 3 +
> include/linux/mtd/spinand.h | 11 +
> include/linux/spi/spi-mem.h | 14 +
> include/linux/spi/spi.h | 3 +
> 11 files changed, 2493 insertions(+), 203 deletions(-)
>
> --
> 2.34.1
^ permalink raw reply
* [PATCH v6 0/8] clk: qcom: Add common clkref support and migrate Glymur and Mahua
From: Qiang Yu @ 2026-06-22 5:11 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu,
krishna.chundru, Konrad Dybcio
This series adds a common clkref_en implementation and converts glymur
and mahua to use it, along with the related binding and DTS updates.
The PCIe clkref clocks on Glymur and Mahua gate the QREF block which
provides reference clocks to the PCIe PHYs. QREF requires LDO supplies
and a reference voltage from the refgen block to operate. The refgen
block itself requires vdda-refgen_0p9 and vdda-refgen_1p2 LDOs to
function.
Previously, these QREF votes were done in PHY drivers. In earlier
discussion [1], the feedback was that this is the wrong ownership point:
those supplies are for the QREF controlled by clkref registers, not for
the PHY directly. Based on that feedback, this series keeps the
regulator handling with the clkref control path.
Another reason for this series is reuse. clkref_en registers may live in
different blocks across platforms (for example TCSR on Glymur, TLMM on
SM8750 [2]), while the behavior is the same. The common helper lets each
driver provide simple descriptors (name, offset, optional supplies) and
reuse shared registration and runtime logic.
Glymur and Mahua share the same QREF TX/RPT/RX component naming but
have different PCIe QREF topologies. Both are handled in tcsrcc-glymur.c
via match_data to select the correct descriptor table per compatible.
[1] https://lore.kernel.org/lkml/aEBfV2M-ZqDF7aRz@hovoldconsulting.com/
[2] https://lore.kernel.org/linux-arm-msm/20260202-topic-8750_tcsr-v1-0-cd7e6648c64f@oss.qualcomm.com/
Changes in v6:
- Split dt-bindings patch into two: one to move glymur-tcsr to its own
binding file, and one to add mahua support
- Use regmap_set_bits()/regmap_clear_bits() instead of regmap_update_bits()
in clk-ref.c
- Move clk_init_data from struct qcom_clk_ref to a stack variable in
qcom_clk_ref_register()
- Add Co-developed-by/Reviewed-by tags from Konrad Dybcio
- Add missing regulator supplies for EDP and USB clkref_en on glymur
- Link to v5: https://patch.msgid.link/20260602-tcsr_qref_0527-v5-0-8ea174a59d7e@oss.qualcomm.com
Changes in v5:
- Return 0 if regmap_read fail
- Add a separate file for glymur-tcsr and mahua-tcsr
- Link to v4: https://patch.msgid.link/20260527-tcsr_qref_0527-v4-0-ded83866c9d9@oss.qualcomm.com
Changes in v4:
- Add mahua QREF support (binding, driver, DTS) to avoid dtb check error
- Override pcie5_phy ref clock to RPMH_CXO_CLK on mahua since
TCSR_PCIE_1_CLKREF_EN is not available
- Rename regulator arrays to topology-based names and merge duplicates
- Remove else: false blocks from binding
- Sort supply properties alphabetically in binding and DTS
- Link to v3: https://lore.kernel.org/all/20260506-qref_vote_0506-v3-0-5ab71d2e6f16@oss.qualcomm.com/
Changes in v3:
- Fix dtb check error: allOf:0: 'then' is a dependency of 'if'.
- Link to v2: https://lore.kernel.org/all/20260420-vote_qref_in_tcsrcc-v2-0-589a23ae640a@oss.qualcomm.com/
Changes in v2:
- RFC tag dropped
- Changed back to additionalProperties: false
- Moved all Glymur supply properties into top-level properties so they are explicitly defined.
- Link to v1: https://lore.kernel.org/all/20260331-qref_vote-v1-0-3fd7fbf87864@oss.qualcomm.com/
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
Qiang Yu (8):
dt-bindings: clock: qcom: Move glymur TCSR to own binding
dt-bindings: clock: qcom,glymur-tcsr: Add mahua support
clk: qcom: Add generic clkref_en support
clk: qcom: tcsrcc-glymur: Add regulator supplies and migrate to clk_ref helper
clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support
arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR
arm64: dts: qcom: mahua: Add QREF regulator supplies to TCSR
arm64: dts: qcom: mahua: Switch pcie5_phy ref clock to RPMH_CXO_CLK
.../bindings/clock/qcom,glymur-tcsr.yaml | 146 +++++++
.../bindings/clock/qcom,sm8550-tcsr.yaml | 2 -
arch/arm64/boot/dts/qcom/glymur-crd.dts | 20 +
arch/arm64/boot/dts/qcom/mahua-crd.dts | 15 +
arch/arm64/boot/dts/qcom/mahua.dtsi | 13 +
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/clk-ref.c | 205 ++++++++++
drivers/clk/qcom/tcsrcc-glymur.c | 438 ++++++++++-----------
include/linux/clk/qcom.h | 67 ++++
9 files changed, 668 insertions(+), 239 deletions(-)
---
base-commit: 3ce97bd3c4f18608335e709c24d6a40e7036cab8
change-id: 20260621-tcsr_qref_0622-b091b8a06f49
Best regards,
--
Qiang Yu <qiang.yu@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v6 1/8] dt-bindings: clock: qcom: Move glymur TCSR to own binding
From: Qiang Yu @ 2026-06-22 5:11 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu,
krishna.chundru
In-Reply-To: <20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com>
The QREF block supplies reference clocks to PCIe PHYs and requires
dedicated LDO supplies to operate. The digital control interface for QREF
(clkref_en registers) resides in TCSR on glymur. Since QREF has no
dedicated DT node of its own, these supply properties are placed in the
TCSR node which acts as the control interface for QREF.
Add a dedicated binding file for qcom,glymur-tcsr and document the supply
properties.
Mark the relevant supplies as required per compatible using allOf/if/then
conditionals.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
.../bindings/clock/qcom,glymur-tcsr.yaml | 114 +++++++++++++++++++++
.../bindings/clock/qcom,sm8550-tcsr.yaml | 2 -
2 files changed, 114 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
new file mode 100644
index 000000000000..16fc6ab87f9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,glymur-tcsr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm TCSR Clock Controller on Glymur
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Taniya Das <taniya.das@oss.qualcomm.com>
+
+description: |
+ Qualcomm TCSR clock control module provides the clocks, resets and
+ power domains on Glymur
+
+ See also:
+ - include/dt-bindings/clock/qcom,glymur-tcsr.h
+
+properties:
+ compatible:
+ items:
+ - const: qcom,glymur-tcsr
+ - const: syscon
+
+ clocks:
+ items:
+ - description: TCXO pad clock
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+ vdda-qrefrpt0-0p9-supply: true
+ vdda-qrefrpt1-0p9-supply: true
+ vdda-qrefrpt2-0p9-supply: true
+ vdda-qrefrpt3-0p9-supply: true
+ vdda-qrefrpt4-0p9-supply: true
+ vdda-qrefrx0-0p9-supply: true
+ vdda-qrefrx1-0p9-supply: true
+ vdda-qrefrx2-0p9-supply: true
+ vdda-qrefrx4-0p9-supply: true
+ vdda-qrefrx5-0p9-supply: true
+ vdda-qreftx0-0p9-supply: true
+ vdda-qreftx0-1p2-supply: true
+ vdda-qreftx1-0p9-supply: true
+ vdda-refgen3-0p9-supply: true
+ vdda-refgen3-1p2-supply: true
+ vdda-refgen4-0p9-supply: true
+ vdda-refgen4-1p2-supply: true
+
+required:
+ - compatible
+ - clocks
+ - vdda-qrefrpt0-0p9-supply
+ - vdda-qrefrpt1-0p9-supply
+ - vdda-qrefrpt2-0p9-supply
+ - vdda-qrefrpt3-0p9-supply
+ - vdda-qrefrpt4-0p9-supply
+ - vdda-qrefrx0-0p9-supply
+ - vdda-qrefrx1-0p9-supply
+ - vdda-qrefrx2-0p9-supply
+ - vdda-qrefrx4-0p9-supply
+ - vdda-qrefrx5-0p9-supply
+ - vdda-qreftx0-0p9-supply
+ - vdda-qreftx0-1p2-supply
+ - vdda-qreftx1-0p9-supply
+ - vdda-refgen3-0p9-supply
+ - vdda-refgen3-1p2-supply
+ - vdda-refgen4-0p9-supply
+ - vdda-refgen4-1p2-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@1fd5000 {
+ compatible = "qcom,glymur-tcsr", "syscon";
+ reg = <0x0 0x1fd5000 0x0 0x21000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ vdda-qrefrpt0-0p9-supply = <&vreg_l1a>;
+ vdda-qrefrpt1-0p9-supply = <&vreg_l1a>;
+ vdda-qrefrpt2-0p9-supply = <&vreg_l1a>;
+ vdda-qrefrpt3-0p9-supply = <&vreg_l1a>;
+ vdda-qrefrpt4-0p9-supply = <&vreg_l1a>;
+ vdda-qrefrx0-0p9-supply = <&vreg_l1a>;
+ vdda-qrefrx1-0p9-supply = <&vreg_l1a>;
+ vdda-qrefrx2-0p9-supply = <&vreg_l1a>;
+ vdda-qrefrx4-0p9-supply = <&vreg_l1a>;
+ vdda-qrefrx5-0p9-supply = <&vreg_l1a>;
+ vdda-qreftx0-0p9-supply = <&vreg_l1a>;
+ vdda-qreftx0-1p2-supply = <&vreg_l2a>;
+ vdda-qreftx1-0p9-supply = <&vreg_l1a>;
+ vdda-refgen3-0p9-supply = <&vreg_l1a>;
+ vdda-refgen3-1p2-supply = <&vreg_l2a>;
+ vdda-refgen4-0p9-supply = <&vreg_l1a>;
+ vdda-refgen4-1p2-supply = <&vreg_l2a>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
index 08824f848973..19ae0634b922 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
@@ -16,7 +16,6 @@ description: |
See also:
- include/dt-bindings/clock/qcom,eliza-tcsr.h
- - include/dt-bindings/clock/qcom,glymur-tcsr.h
- include/dt-bindings/clock/qcom,hawi-tcsrcc.h
- include/dt-bindings/clock/qcom,nord-tcsrcc.h
- include/dt-bindings/clock/qcom,sm8550-tcsr.h
@@ -28,7 +27,6 @@ properties:
items:
- enum:
- qcom,eliza-tcsr
- - qcom,glymur-tcsr
- qcom,hawi-tcsrcc
- qcom,kaanapali-tcsr
- qcom,milos-tcsr
--
2.34.1
^ permalink raw reply related
* [PATCH v6 2/8] dt-bindings: clock: qcom,glymur-tcsr: Add mahua support
From: Qiang Yu @ 2026-06-22 5:11 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu,
krishna.chundru
In-Reply-To: <20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com>
Mahua shares the same QREF TX/RPT/RX component naming as Glymur, but
has a different topology: a single QREF block fed by REFGEN3 only,
rather than the two independent blocks fed by REFGEN3 and REFGEN4 on
Glymur.
Add qcom,mahua-tcsr compatible and document its required supply
properties.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
.../bindings/clock/qcom,glymur-tcsr.yaml | 68 ++++++++++++++++------
1 file changed, 50 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
index 16fc6ab87f9b..2b6422627165 100644
--- a/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
@@ -20,7 +20,9 @@ description: |
properties:
compatible:
items:
- - const: qcom,glymur-tcsr
+ - enum:
+ - qcom,glymur-tcsr
+ - qcom,mahua-tcsr
- const: syscon
clocks:
@@ -41,9 +43,11 @@ properties:
vdda-qrefrpt2-0p9-supply: true
vdda-qrefrpt3-0p9-supply: true
vdda-qrefrpt4-0p9-supply: true
+ vdda-qrefrpt5-0p9-supply: true
vdda-qrefrx0-0p9-supply: true
vdda-qrefrx1-0p9-supply: true
vdda-qrefrx2-0p9-supply: true
+ vdda-qrefrx3-0p9-supply: true
vdda-qrefrx4-0p9-supply: true
vdda-qrefrx5-0p9-supply: true
vdda-qreftx0-0p9-supply: true
@@ -54,26 +58,54 @@ properties:
vdda-refgen4-0p9-supply: true
vdda-refgen4-1p2-supply: true
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,glymur-tcsr
+ then:
+ required:
+ - vdda-qrefrpt0-0p9-supply
+ - vdda-qrefrpt1-0p9-supply
+ - vdda-qrefrpt2-0p9-supply
+ - vdda-qrefrpt3-0p9-supply
+ - vdda-qrefrpt4-0p9-supply
+ - vdda-qrefrx0-0p9-supply
+ - vdda-qrefrx1-0p9-supply
+ - vdda-qrefrx2-0p9-supply
+ - vdda-qrefrx4-0p9-supply
+ - vdda-qrefrx5-0p9-supply
+ - vdda-qreftx0-0p9-supply
+ - vdda-qreftx0-1p2-supply
+ - vdda-qreftx1-0p9-supply
+ - vdda-refgen3-0p9-supply
+ - vdda-refgen3-1p2-supply
+ - vdda-refgen4-0p9-supply
+ - vdda-refgen4-1p2-supply
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,mahua-tcsr
+ then:
+ required:
+ - vdda-qrefrpt0-0p9-supply
+ - vdda-qrefrpt1-0p9-supply
+ - vdda-qrefrpt2-0p9-supply
+ - vdda-qrefrpt3-0p9-supply
+ - vdda-qrefrpt4-0p9-supply
+ - vdda-qrefrpt5-0p9-supply
+ - vdda-qrefrx1-0p9-supply
+ - vdda-qrefrx2-0p9-supply
+ - vdda-qrefrx3-0p9-supply
+ - vdda-qreftx1-0p9-supply
+ - vdda-refgen3-0p9-supply
+ - vdda-refgen3-1p2-supply
+
required:
- compatible
- clocks
- - vdda-qrefrpt0-0p9-supply
- - vdda-qrefrpt1-0p9-supply
- - vdda-qrefrpt2-0p9-supply
- - vdda-qrefrpt3-0p9-supply
- - vdda-qrefrpt4-0p9-supply
- - vdda-qrefrx0-0p9-supply
- - vdda-qrefrx1-0p9-supply
- - vdda-qrefrx2-0p9-supply
- - vdda-qrefrx4-0p9-supply
- - vdda-qrefrx5-0p9-supply
- - vdda-qreftx0-0p9-supply
- - vdda-qreftx0-1p2-supply
- - vdda-qreftx1-0p9-supply
- - vdda-refgen3-0p9-supply
- - vdda-refgen3-1p2-supply
- - vdda-refgen4-0p9-supply
- - vdda-refgen4-1p2-supply
additionalProperties: false
--
2.34.1
^ permalink raw reply related
* [PATCH v6 3/8] clk: qcom: Add generic clkref_en support
From: Qiang Yu @ 2026-06-22 5:11 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu,
krishna.chundru
In-Reply-To: <20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com>
Before XO refclk is distributed to PCIe/USB/eDP PHYs, it passes through
a QREF block. QREF is powered by dedicated LDO rails, and the clkref_en
register controls whether refclk is gated through to the PHY side.
These clkref controls are different from typical GCC branch clocks:
- only a single enable bit is present, without branch-style config bits
- regulators must be voted before enable and unvoted after disable
Model this as a dedicated clk_ref clock type with custom clk_ops instead
of reusing struct clk_branch semantics.
Also provide a common registration/probe API so the same clkref model
can be reused regardless of where clkref_en registers are placed, e.g.
TCSR on glymur and TLMM on SM8750.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/clk-ref.c | 205 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/clk/qcom.h | 67 +++++++++++++++
3 files changed, 273 insertions(+)
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 58f9a5eb6fd7..4e7abe8d49e6 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -8,6 +8,7 @@ clk-qcom-y += clk-pll.o
clk-qcom-y += clk-rcg.o
clk-qcom-y += clk-rcg2.o
clk-qcom-y += clk-branch.o
+clk-qcom-y += clk-ref.o
clk-qcom-y += clk-regmap-divider.o
clk-qcom-y += clk-regmap-mux.o
clk-qcom-y += clk-regmap-mux-div.o
diff --git a/drivers/clk/qcom/clk-ref.c b/drivers/clk/qcom/clk-ref.c
new file mode 100644
index 000000000000..8132e510f43c
--- /dev/null
+++ b/drivers/clk/qcom/clk-ref.c
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2026, Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clk/qcom.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+
+#define QCOM_CLK_REF_EN_MASK BIT(0)
+
+struct qcom_clk_ref_provider {
+ struct qcom_clk_ref *refs;
+ size_t num_refs;
+};
+
+static inline struct qcom_clk_ref *to_qcom_clk_ref(struct clk_hw *hw)
+{
+ return container_of(hw, struct qcom_clk_ref, hw);
+}
+
+static const struct clk_parent_data qcom_clk_ref_parent_data = {
+ .index = 0,
+};
+
+static int qcom_clk_ref_prepare(struct clk_hw *hw)
+{
+ struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+ int ret;
+
+ if (!rclk->desc.num_regulators)
+ return 0;
+
+ ret = regulator_bulk_enable(rclk->desc.num_regulators, rclk->regulators);
+ if (ret)
+ pr_err("Failed to enable regulators for %s: %d\n",
+ clk_hw_get_name(hw), ret);
+
+ return ret;
+}
+
+static void qcom_clk_ref_unprepare(struct clk_hw *hw)
+{
+ struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+
+ if (rclk->desc.num_regulators)
+ regulator_bulk_disable(rclk->desc.num_regulators, rclk->regulators);
+}
+
+static int qcom_clk_ref_enable(struct clk_hw *hw)
+{
+ struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+ int ret;
+
+ ret = regmap_set_bits(rclk->regmap, rclk->desc.offset, QCOM_CLK_REF_EN_MASK);
+ if (ret)
+ return ret;
+
+ udelay(10);
+
+ return 0;
+}
+
+static void qcom_clk_ref_disable(struct clk_hw *hw)
+{
+ struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+
+ regmap_clear_bits(rclk->regmap, rclk->desc.offset, QCOM_CLK_REF_EN_MASK);
+ udelay(10);
+}
+
+static int qcom_clk_ref_is_enabled(struct clk_hw *hw)
+{
+ struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+ u32 val;
+ int ret;
+
+ ret = regmap_read(rclk->regmap, rclk->desc.offset, &val);
+ if (ret)
+ return 0;
+
+ return !!(val & QCOM_CLK_REF_EN_MASK);
+}
+
+static const struct clk_ops qcom_clk_ref_ops = {
+ .prepare = qcom_clk_ref_prepare,
+ .unprepare = qcom_clk_ref_unprepare,
+ .enable = qcom_clk_ref_enable,
+ .disable = qcom_clk_ref_disable,
+ .is_enabled = qcom_clk_ref_is_enabled,
+};
+
+static int qcom_clk_ref_register(struct device *dev, struct regmap *regmap,
+ struct qcom_clk_ref *clk_refs,
+ const struct qcom_clk_ref_desc *descs,
+ size_t num_clk_refs)
+{
+ const struct qcom_clk_ref_desc *desc;
+ struct clk_init_data init_data = {};
+ struct qcom_clk_ref *clk_ref;
+ size_t clk_idx;
+ unsigned int i;
+ int ret;
+
+ for (clk_idx = 0; clk_idx < num_clk_refs; clk_idx++) {
+ clk_ref = &clk_refs[clk_idx];
+ desc = &descs[clk_idx];
+
+ if (!desc->name)
+ continue;
+
+ clk_ref->regmap = regmap;
+ clk_ref->desc = *desc;
+
+ if (clk_ref->desc.num_regulators) {
+ clk_ref->regulators = devm_kcalloc(dev, clk_ref->desc.num_regulators,
+ sizeof(*clk_ref->regulators),
+ GFP_KERNEL);
+ if (!clk_ref->regulators)
+ return -ENOMEM;
+
+ for (i = 0; i < clk_ref->desc.num_regulators; i++)
+ clk_ref->regulators[i].supply =
+ clk_ref->desc.regulator_names[i];
+
+ ret = devm_regulator_bulk_get(dev, clk_ref->desc.num_regulators,
+ clk_ref->regulators);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to get regulators for %s\n",
+ clk_ref->desc.name);
+ }
+
+ init_data.name = clk_ref->desc.name;
+ init_data.parent_data = &qcom_clk_ref_parent_data;
+ init_data.num_parents = 1;
+ init_data.ops = &qcom_clk_ref_ops;
+ clk_ref->hw.init = &init_data;
+
+ ret = devm_clk_hw_register(dev, &clk_ref->hw);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct clk_hw *qcom_clk_ref_provider_get(struct of_phandle_args *clkspec, void *data)
+{
+ struct qcom_clk_ref_provider *provider = data;
+ unsigned int idx = clkspec->args[0];
+
+ if (idx >= provider->num_refs)
+ return ERR_PTR(-EINVAL);
+
+ if (!provider->refs[idx].regmap)
+ return ERR_PTR(-ENOENT);
+
+ return &provider->refs[idx].hw;
+}
+
+int qcom_clk_ref_probe(struct platform_device *pdev,
+ const struct regmap_config *config,
+ const struct qcom_clk_ref_desc *descs,
+ size_t num_clk_refs)
+{
+ struct qcom_clk_ref_provider *provider;
+ struct device *dev = &pdev->dev;
+ struct regmap *regmap;
+ void __iomem *base;
+ int ret;
+
+ base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ regmap = devm_regmap_init_mmio(dev, base, config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ provider = devm_kzalloc(dev, sizeof(*provider), GFP_KERNEL);
+ if (!provider)
+ return -ENOMEM;
+
+ provider->refs = devm_kcalloc(dev, num_clk_refs, sizeof(*provider->refs),
+ GFP_KERNEL);
+ if (!provider->refs)
+ return -ENOMEM;
+
+ provider->num_refs = num_clk_refs;
+
+ ret = qcom_clk_ref_register(dev, regmap, provider->refs, descs,
+ provider->num_refs);
+ if (ret)
+ return ret;
+
+ return devm_of_clk_add_hw_provider(dev, qcom_clk_ref_provider_get, provider);
+}
+EXPORT_SYMBOL_GPL(qcom_clk_ref_probe);
diff --git a/include/linux/clk/qcom.h b/include/linux/clk/qcom.h
new file mode 100644
index 000000000000..a89122a8f87b
--- /dev/null
+++ b/include/linux/clk/qcom.h
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2026, Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef __LINUX_CLK_QCOM_H
+#define __LINUX_CLK_QCOM_H
+
+#include <linux/clk-provider.h>
+#include <linux/errno.h>
+#include <linux/kconfig.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+struct device;
+struct platform_device;
+struct regulator_bulk_data;
+
+/**
+ * struct qcom_clk_ref_desc - descriptor for a clkref_en gate clock
+ * @name: clock name exposed to the common clock framework
+ * @offset: clkref_en register offset from the block base
+ * @regulator_names: optional supply names enabled while preparing the clock
+ * @num_regulators: number of entries in @regulator_names
+ */
+struct qcom_clk_ref_desc {
+ const char *name;
+ u32 offset;
+ const char * const *regulator_names;
+ unsigned int num_regulators;
+};
+
+/**
+ * struct qcom_clk_ref - per-clock data for a clkref_en gate clock
+ * @hw: common clock framework hardware clock handle
+ * @regmap: register map backing the clkref_en register
+ * @desc: clock descriptor copied at registration time
+ * @regulators: optional bulk regulator handles for @desc.regulator_names
+ */
+struct qcom_clk_ref {
+ struct clk_hw hw;
+ struct regmap *regmap;
+ struct qcom_clk_ref_desc desc;
+ struct regulator_bulk_data *regulators;
+};
+
+#if IS_ENABLED(CONFIG_COMMON_CLK_QCOM)
+
+int qcom_clk_ref_probe(struct platform_device *pdev,
+ const struct regmap_config *config,
+ const struct qcom_clk_ref_desc *descs,
+ size_t num_clk_refs);
+
+#else
+
+static inline int
+qcom_clk_ref_probe(struct platform_device *pdev,
+ const struct regmap_config *config,
+ const struct qcom_clk_ref_desc *descs,
+ size_t num_clk_refs)
+{
+ return -EOPNOTSUPP;
+}
+
+#endif
+
+#endif
--
2.34.1
^ permalink raw reply related
* [PATCH v6 4/8] clk: qcom: tcsrcc-glymur: Add regulator supplies and migrate to clk_ref helper
From: Qiang Yu @ 2026-06-22 5:11 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu,
krishna.chundru, Konrad Dybcio
In-Reply-To: <20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com>
Replace local clk_branch-based clkref definitions with descriptor-based
registration via qcom_clk_ref_probe().
This keeps the glymur driver focused on clock metadata and reuses common
runtime logic for regulator handling, enable/disable sequencing, and OF
provider wiring.
Co-developed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
drivers/clk/qcom/tcsrcc-glymur.c | 361 +++++++++++++--------------------------
1 file changed, 116 insertions(+), 245 deletions(-)
diff --git a/drivers/clk/qcom/tcsrcc-glymur.c b/drivers/clk/qcom/tcsrcc-glymur.c
index 9c0edebcdbb1..2db039342f30 100644
--- a/drivers/clk/qcom/tcsrcc-glymur.c
+++ b/drivers/clk/qcom/tcsrcc-glymur.c
@@ -4,277 +4,146 @@
*/
#include <linux/clk-provider.h>
+#include <linux/clk/qcom.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <dt-bindings/clock/qcom,glymur-tcsr.h>
-#include "clk-alpha-pll.h"
-#include "clk-branch.h"
-#include "clk-pll.h"
-#include "clk-rcg.h"
-#include "clk-regmap.h"
-#include "clk-regmap-divider.h"
-#include "clk-regmap-mux.h"
-#include "common.h"
-#include "gdsc.h"
-#include "reset.h"
-
-enum {
- DT_BI_TCXO_PAD,
+static const char * const glymur_tcsr_tx0_rx5_regulators[] = {
+ "vdda-refgen3-0p9",
+ "vdda-refgen3-1p2",
+ "vdda-qrefrx5-0p9",
+ "vdda-qreftx0-0p9",
+ "vdda-qreftx0-1p2",
};
-static struct clk_branch tcsr_edp_clkref_en = {
- .halt_reg = 0x60,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x60,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_edp_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
- },
+static const char * const glymur_tcsr_tx1_rpt0_rx0_regulators[] = {
+ "vdda-refgen4-0p9",
+ "vdda-refgen4-1p2",
+ "vdda-qreftx1-0p9",
+ "vdda-qrefrpt0-0p9",
+ "vdda-qrefrx0-0p9",
};
-static struct clk_branch tcsr_pcie_1_clkref_en = {
- .halt_reg = 0x48,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x48,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_pcie_1_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
- },
+static const char * const glymur_tcsr_tx1_rpt01_rx1_regulators[] = {
+ "vdda-refgen4-0p9",
+ "vdda-refgen4-1p2",
+ "vdda-qreftx1-0p9",
+ "vdda-qrefrpt0-0p9",
+ "vdda-qrefrpt1-0p9",
+ "vdda-qrefrx1-0p9",
};
-static struct clk_branch tcsr_pcie_2_clkref_en = {
- .halt_reg = 0x4c,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x4c,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_pcie_2_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
- },
+static const char * const glymur_tcsr_tx1_rpt012_rx2_regulators[] = {
+ "vdda-refgen4-0p9",
+ "vdda-refgen4-1p2",
+ "vdda-qreftx1-0p9",
+ "vdda-qrefrpt0-0p9",
+ "vdda-qrefrpt1-0p9",
+ "vdda-qrefrpt2-0p9",
+ "vdda-qrefrx2-0p9",
};
-static struct clk_branch tcsr_pcie_3_clkref_en = {
- .halt_reg = 0x54,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x54,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_pcie_3_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
- },
+static const char * const glymur_tcsr_tx1_rpt34_rx4_regulators[] = {
+ "vdda-refgen4-0p9",
+ "vdda-refgen4-1p2",
+ "vdda-qreftx1-0p9",
+ "vdda-qrefrpt3-0p9",
+ "vdda-qrefrpt4-0p9",
+ "vdda-qrefrx4-0p9",
};
-static struct clk_branch tcsr_pcie_4_clkref_en = {
- .halt_reg = 0x58,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x58,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_pcie_4_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
- },
+static const struct regmap_config tcsr_cc_glymur_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0x94,
+ .fast_io = true,
};
-static struct clk_branch tcsr_usb2_1_clkref_en = {
- .halt_reg = 0x6c,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x6c,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb2_1_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+static const struct qcom_clk_ref_desc tcsr_cc_glymur_clk_descs[] = {
+ [TCSR_EDP_CLKREF_EN] = {
+ .name = "tcsr_edp_clkref_en",
+ .offset = 0x60,
+ .regulator_names = glymur_tcsr_tx1_rpt0_rx0_regulators,
+ .num_regulators = ARRAY_SIZE(glymur_tcsr_tx1_rpt0_rx0_regulators),
},
-};
-
-static struct clk_branch tcsr_usb2_2_clkref_en = {
- .halt_reg = 0x70,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x70,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb2_2_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_PCIE_1_CLKREF_EN] = {
+ .name = "tcsr_pcie_1_clkref_en",
+ .offset = 0x48,
+ .regulator_names = glymur_tcsr_tx0_rx5_regulators,
+ .num_regulators = ARRAY_SIZE(glymur_tcsr_tx0_rx5_regulators),
},
-};
-
-static struct clk_branch tcsr_usb2_3_clkref_en = {
- .halt_reg = 0x74,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x74,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb2_3_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_PCIE_2_CLKREF_EN] = {
+ .name = "tcsr_pcie_2_clkref_en",
+ .offset = 0x4c,
+ .regulator_names = glymur_tcsr_tx1_rpt012_rx2_regulators,
+ .num_regulators = ARRAY_SIZE(glymur_tcsr_tx1_rpt012_rx2_regulators),
},
-};
-
-static struct clk_branch tcsr_usb2_4_clkref_en = {
- .halt_reg = 0x88,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x88,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb2_4_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_PCIE_3_CLKREF_EN] = {
+ .name = "tcsr_pcie_3_clkref_en",
+ .offset = 0x54,
+ .regulator_names = glymur_tcsr_tx1_rpt01_rx1_regulators,
+ .num_regulators = ARRAY_SIZE(glymur_tcsr_tx1_rpt01_rx1_regulators),
},
-};
-
-static struct clk_branch tcsr_usb3_0_clkref_en = {
- .halt_reg = 0x64,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x64,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb3_0_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_PCIE_4_CLKREF_EN] = {
+ .name = "tcsr_pcie_4_clkref_en",
+ .offset = 0x58,
+ .regulator_names = glymur_tcsr_tx1_rpt012_rx2_regulators,
+ .num_regulators = ARRAY_SIZE(glymur_tcsr_tx1_rpt012_rx2_regulators),
},
-};
-
-static struct clk_branch tcsr_usb3_1_clkref_en = {
- .halt_reg = 0x68,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x68,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb3_1_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_USB2_1_CLKREF_EN] = {
+ .name = "tcsr_usb2_1_clkref_en",
+ .offset = 0x6c,
+ .regulator_names = glymur_tcsr_tx1_rpt34_rx4_regulators,
+ .num_regulators = ARRAY_SIZE(glymur_tcsr_tx1_rpt34_rx4_regulators),
},
-};
-
-static struct clk_branch tcsr_usb4_1_clkref_en = {
- .halt_reg = 0x44,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x44,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb4_1_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_USB2_2_CLKREF_EN] = {
+ .name = "tcsr_usb2_2_clkref_en",
+ .offset = 0x70,
+ .regulator_names = glymur_tcsr_tx1_rpt01_rx1_regulators,
+ .num_regulators = ARRAY_SIZE(glymur_tcsr_tx1_rpt01_rx1_regulators),
},
-};
-
-static struct clk_branch tcsr_usb4_2_clkref_en = {
- .halt_reg = 0x5c,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x5c,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb4_2_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_USB2_3_CLKREF_EN] = {
+ .name = "tcsr_usb2_3_clkref_en",
+ .offset = 0x74,
+ .regulator_names = glymur_tcsr_tx1_rpt34_rx4_regulators,
+ .num_regulators = ARRAY_SIZE(glymur_tcsr_tx1_rpt34_rx4_regulators),
+ },
+ [TCSR_USB2_4_CLKREF_EN] = {
+ .name = "tcsr_usb2_4_clkref_en",
+ .offset = 0x88,
+ .regulator_names = glymur_tcsr_tx1_rpt34_rx4_regulators,
+ .num_regulators = ARRAY_SIZE(glymur_tcsr_tx1_rpt34_rx4_regulators),
+ },
+ [TCSR_USB3_0_CLKREF_EN] = {
+ .name = "tcsr_usb3_0_clkref_en",
+ .offset = 0x64,
+ .regulator_names = glymur_tcsr_tx1_rpt34_rx4_regulators,
+ .num_regulators = ARRAY_SIZE(glymur_tcsr_tx1_rpt34_rx4_regulators),
+ },
+ [TCSR_USB3_1_CLKREF_EN] = {
+ .name = "tcsr_usb3_1_clkref_en",
+ .offset = 0x68,
+ .regulator_names = glymur_tcsr_tx1_rpt34_rx4_regulators,
+ .num_regulators = ARRAY_SIZE(glymur_tcsr_tx1_rpt34_rx4_regulators),
+ },
+ [TCSR_USB4_1_CLKREF_EN] = {
+ .name = "tcsr_usb4_1_clkref_en",
+ .offset = 0x44,
+ .regulator_names = glymur_tcsr_tx0_rx5_regulators,
+ .num_regulators = ARRAY_SIZE(glymur_tcsr_tx0_rx5_regulators),
+ },
+ [TCSR_USB4_2_CLKREF_EN] = {
+ .name = "tcsr_usb4_2_clkref_en",
+ .offset = 0x5c,
+ .regulator_names = glymur_tcsr_tx1_rpt01_rx1_regulators,
+ .num_regulators = ARRAY_SIZE(glymur_tcsr_tx1_rpt01_rx1_regulators),
},
-};
-
-static struct clk_regmap *tcsr_cc_glymur_clocks[] = {
- [TCSR_EDP_CLKREF_EN] = &tcsr_edp_clkref_en.clkr,
- [TCSR_PCIE_1_CLKREF_EN] = &tcsr_pcie_1_clkref_en.clkr,
- [TCSR_PCIE_2_CLKREF_EN] = &tcsr_pcie_2_clkref_en.clkr,
- [TCSR_PCIE_3_CLKREF_EN] = &tcsr_pcie_3_clkref_en.clkr,
- [TCSR_PCIE_4_CLKREF_EN] = &tcsr_pcie_4_clkref_en.clkr,
- [TCSR_USB2_1_CLKREF_EN] = &tcsr_usb2_1_clkref_en.clkr,
- [TCSR_USB2_2_CLKREF_EN] = &tcsr_usb2_2_clkref_en.clkr,
- [TCSR_USB2_3_CLKREF_EN] = &tcsr_usb2_3_clkref_en.clkr,
- [TCSR_USB2_4_CLKREF_EN] = &tcsr_usb2_4_clkref_en.clkr,
- [TCSR_USB3_0_CLKREF_EN] = &tcsr_usb3_0_clkref_en.clkr,
- [TCSR_USB3_1_CLKREF_EN] = &tcsr_usb3_1_clkref_en.clkr,
- [TCSR_USB4_1_CLKREF_EN] = &tcsr_usb4_1_clkref_en.clkr,
- [TCSR_USB4_2_CLKREF_EN] = &tcsr_usb4_2_clkref_en.clkr,
-};
-
-static const struct regmap_config tcsr_cc_glymur_regmap_config = {
- .reg_bits = 32,
- .reg_stride = 4,
- .val_bits = 32,
- .max_register = 0x94,
- .fast_io = true,
-};
-
-static const struct qcom_cc_desc tcsr_cc_glymur_desc = {
- .config = &tcsr_cc_glymur_regmap_config,
- .clks = tcsr_cc_glymur_clocks,
- .num_clks = ARRAY_SIZE(tcsr_cc_glymur_clocks),
};
static const struct of_device_id tcsr_cc_glymur_match_table[] = {
@@ -285,7 +154,9 @@ MODULE_DEVICE_TABLE(of, tcsr_cc_glymur_match_table);
static int tcsr_cc_glymur_probe(struct platform_device *pdev)
{
- return qcom_cc_probe(pdev, &tcsr_cc_glymur_desc);
+ return qcom_clk_ref_probe(pdev, &tcsr_cc_glymur_regmap_config,
+ tcsr_cc_glymur_clk_descs,
+ ARRAY_SIZE(tcsr_cc_glymur_clk_descs));
}
static struct platform_driver tcsr_cc_glymur_driver = {
--
2.34.1
^ permalink raw reply related
* [PATCH v6 5/8] clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support
From: Qiang Yu @ 2026-06-22 5:11 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu,
krishna.chundru
In-Reply-To: <20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com>
Mahua is based on Glymur but uses a different QREF topology, requiring
distinct regulator lists and clock descriptors for its PCIe clock
references.
Add mahua-specific regulator arrays and clk descriptor table, and use
match_data to select the correct descriptor table per compatible string at
probe time.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
drivers/clk/qcom/tcsrcc-glymur.c | 99 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 96 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/qcom/tcsrcc-glymur.c b/drivers/clk/qcom/tcsrcc-glymur.c
index 2db039342f30..9af520b71f31 100644
--- a/drivers/clk/qcom/tcsrcc-glymur.c
+++ b/drivers/clk/qcom/tcsrcc-glymur.c
@@ -13,6 +13,11 @@
#include <dt-bindings/clock/qcom,glymur-tcsr.h>
+struct tcsrcc_glymur_data {
+ const struct qcom_clk_ref_desc *descs;
+ size_t num_descs;
+};
+
static const char * const glymur_tcsr_tx0_rx5_regulators[] = {
"vdda-refgen3-0p9",
"vdda-refgen3-1p2",
@@ -57,6 +62,25 @@ static const char * const glymur_tcsr_tx1_rpt34_rx4_regulators[] = {
"vdda-qrefrx4-0p9",
};
+static const char * const mahua_tcsr_tx1_rpt01_rx1_regulators[] = {
+ "vdda-refgen3-0p9",
+ "vdda-refgen3-1p2",
+ "vdda-qreftx1-0p9",
+ "vdda-qrefrpt0-0p9",
+ "vdda-qrefrpt1-0p9",
+ "vdda-qrefrx1-0p9",
+};
+
+static const char * const mahua_tcsr_tx1_rpt012_rx2_regulators[] = {
+ "vdda-refgen3-0p9",
+ "vdda-refgen3-1p2",
+ "vdda-qreftx1-0p9",
+ "vdda-qrefrpt0-0p9",
+ "vdda-qrefrpt1-0p9",
+ "vdda-qrefrpt2-0p9",
+ "vdda-qrefrx2-0p9",
+};
+
static const struct regmap_config tcsr_cc_glymur_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
@@ -146,17 +170,86 @@ static const struct qcom_clk_ref_desc tcsr_cc_glymur_clk_descs[] = {
},
};
+static const struct qcom_clk_ref_desc tcsr_cc_mahua_clk_descs[] = {
+ [TCSR_EDP_CLKREF_EN] = {
+ .name = "tcsr_edp_clkref_en",
+ .offset = 0x60,
+ },
+ [TCSR_PCIE_2_CLKREF_EN] = {
+ .name = "tcsr_pcie_2_clkref_en",
+ .offset = 0x4c,
+ .regulator_names = mahua_tcsr_tx1_rpt01_rx1_regulators,
+ .num_regulators = ARRAY_SIZE(mahua_tcsr_tx1_rpt01_rx1_regulators),
+ },
+ [TCSR_PCIE_3_CLKREF_EN] = {
+ .name = "tcsr_pcie_3_clkref_en",
+ .offset = 0x54,
+ .regulator_names = mahua_tcsr_tx1_rpt012_rx2_regulators,
+ .num_regulators = ARRAY_SIZE(mahua_tcsr_tx1_rpt012_rx2_regulators),
+ },
+ [TCSR_PCIE_4_CLKREF_EN] = {
+ .name = "tcsr_pcie_4_clkref_en",
+ .offset = 0x58,
+ .regulator_names = mahua_tcsr_tx1_rpt01_rx1_regulators,
+ .num_regulators = ARRAY_SIZE(mahua_tcsr_tx1_rpt01_rx1_regulators),
+ },
+ [TCSR_USB2_1_CLKREF_EN] = {
+ .name = "tcsr_usb2_1_clkref_en",
+ .offset = 0x6c,
+ },
+ [TCSR_USB2_2_CLKREF_EN] = {
+ .name = "tcsr_usb2_2_clkref_en",
+ .offset = 0x70,
+ },
+ [TCSR_USB2_3_CLKREF_EN] = {
+ .name = "tcsr_usb2_3_clkref_en",
+ .offset = 0x74,
+ },
+ [TCSR_USB2_4_CLKREF_EN] = {
+ .name = "tcsr_usb2_4_clkref_en",
+ .offset = 0x88,
+ },
+ [TCSR_USB3_0_CLKREF_EN] = {
+ .name = "tcsr_usb3_0_clkref_en",
+ .offset = 0x64,
+ },
+ [TCSR_USB3_1_CLKREF_EN] = {
+ .name = "tcsr_usb3_1_clkref_en",
+ .offset = 0x68,
+ },
+ [TCSR_USB4_1_CLKREF_EN] = {
+ .name = "tcsr_usb4_1_clkref_en",
+ .offset = 0x44,
+ },
+ [TCSR_USB4_2_CLKREF_EN] = {
+ .name = "tcsr_usb4_2_clkref_en",
+ .offset = 0x5c,
+ },
+};
+
+static const struct tcsrcc_glymur_data tcsr_cc_glymur_data = {
+ .descs = tcsr_cc_glymur_clk_descs,
+ .num_descs = ARRAY_SIZE(tcsr_cc_glymur_clk_descs),
+};
+
+static const struct tcsrcc_glymur_data tcsr_cc_mahua_data = {
+ .descs = tcsr_cc_mahua_clk_descs,
+ .num_descs = ARRAY_SIZE(tcsr_cc_mahua_clk_descs),
+};
+
static const struct of_device_id tcsr_cc_glymur_match_table[] = {
- { .compatible = "qcom,glymur-tcsr" },
+ { .compatible = "qcom,glymur-tcsr", .data = &tcsr_cc_glymur_data },
+ { .compatible = "qcom,mahua-tcsr", .data = &tcsr_cc_mahua_data },
{ }
};
MODULE_DEVICE_TABLE(of, tcsr_cc_glymur_match_table);
static int tcsr_cc_glymur_probe(struct platform_device *pdev)
{
+ const struct tcsrcc_glymur_data *data = device_get_match_data(&pdev->dev);
+
return qcom_clk_ref_probe(pdev, &tcsr_cc_glymur_regmap_config,
- tcsr_cc_glymur_clk_descs,
- ARRAY_SIZE(tcsr_cc_glymur_clk_descs));
+ data->descs, data->num_descs);
}
static struct platform_driver tcsr_cc_glymur_driver = {
--
2.34.1
^ permalink raw reply related
* [PATCH v6 6/8] arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR
From: Qiang Yu @ 2026-06-22 5:11 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu,
krishna.chundru
In-Reply-To: <20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com>
The TCSR clkref_en clocks gate the QREF block which provides reference
clocks to the PCIe PHYs. Wire up the LDO supplies required by the QREF
and refgen blocks on the CRD board.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur-crd.dts | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dts b/arch/arm64/boot/dts/qcom/glymur-crd.dts
index c98dfb3941fa..92b929ee3448 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dts
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dts
@@ -278,6 +278,26 @@ &smb2370_k_e2_eusb2_repeater {
vdd3-supply = <&vreg_l7b_e0_2p79>;
};
+&tcsr {
+ vdda-qrefrpt0-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrpt1-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrpt2-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrpt3-0p9-supply = <&vreg_l2h_e0_0p72>;
+ vdda-qrefrpt4-0p9-supply = <&vreg_l2h_e0_0p72>;
+ vdda-qrefrx0-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrx1-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrx2-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrx4-0p9-supply = <&vreg_l2h_e0_0p72>;
+ vdda-qrefrx5-0p9-supply = <&vreg_l3f_e0_0p72>;
+ vdda-qreftx0-0p9-supply = <&vreg_l3f_e0_0p72>;
+ vdda-qreftx0-1p2-supply = <&vreg_l4h_e0_1p2>;
+ vdda-qreftx1-0p9-supply = <&vreg_l1f_e1_0p82>;
+ vdda-refgen3-0p9-supply = <&vreg_l2f_e0_0p82>;
+ vdda-refgen3-1p2-supply = <&vreg_l4h_e0_1p2>;
+ vdda-refgen4-0p9-supply = <&vreg_l1f_e1_0p82>;
+ vdda-refgen4-1p2-supply = <&vreg_l4f_e1_1p08>;
+};
+
&tlmm {
edp_bl_en: edp-bl-en-state {
pins = "gpio18";
--
2.34.1
^ permalink raw reply related
* [PATCH v6 7/8] arm64: dts: qcom: mahua: Add QREF regulator supplies to TCSR
From: Qiang Yu @ 2026-06-22 5:11 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu,
krishna.chundru
In-Reply-To: <20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com>
Mahua has a different PCIe QREF topology from glymur. Override the TCSR
compatible to qcom,mahua-tcsr in mahua.dtsi, and wire up the required
LDO supplies for the PCIe clkref paths on the CRD board.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/mahua-crd.dts | 15 +++++++++++++++
arch/arm64/boot/dts/qcom/mahua.dtsi | 4 ++++
2 files changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/mahua-crd.dts b/arch/arm64/boot/dts/qcom/mahua-crd.dts
index 9c8244e892dd..8b42f5174b31 100644
--- a/arch/arm64/boot/dts/qcom/mahua-crd.dts
+++ b/arch/arm64/boot/dts/qcom/mahua-crd.dts
@@ -19,3 +19,18 @@ / {
model = "Qualcomm Technologies, Inc. Mahua CRD";
compatible = "qcom,mahua-crd", "qcom,mahua";
};
+
+&tcsr {
+ vdda-qrefrpt0-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrpt1-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrpt2-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrpt3-0p9-supply = <&vreg_l1f_e1_0p82>;
+ vdda-qrefrpt4-0p9-supply = <&vreg_l2h_e0_0p72>;
+ vdda-qrefrpt5-0p9-supply = <&vreg_l2h_e0_0p72>;
+ vdda-qrefrx1-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrx2-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrx3-0p9-supply = <&vreg_l2h_e0_0p72>;
+ vdda-qreftx1-0p9-supply = <&vreg_l1f_e1_0p82>;
+ vdda-refgen3-0p9-supply = <&vreg_l1f_e1_0p82>;
+ vdda-refgen3-1p2-supply = <&vreg_l4f_e1_1p08>;
+};
diff --git a/arch/arm64/boot/dts/qcom/mahua.dtsi b/arch/arm64/boot/dts/qcom/mahua.dtsi
index 22822b6b2e8b..eb45adc8a0a2 100644
--- a/arch/arm64/boot/dts/qcom/mahua.dtsi
+++ b/arch/arm64/boot/dts/qcom/mahua.dtsi
@@ -286,6 +286,10 @@ gpuss-4-critical {
};
};
+&tcsr {
+ compatible = "qcom,mahua-tcsr", "syscon";
+};
+
&tlmm {
compatible = "qcom,mahua-tlmm";
};
--
2.34.1
^ permalink raw reply related
* [PATCH v6 8/8] arm64: dts: qcom: mahua: Switch pcie5_phy ref clock to RPMH_CXO_CLK
From: Qiang Yu @ 2026-06-22 5:11 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu,
krishna.chundru
In-Reply-To: <20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com>
PCIe5 PHY on Mahua gets refclk from CXO0 pad directly, so no QREF
clkref_en voting is required. Override the clock list to use RPMH_CXO_CLK
directly instead.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/mahua.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/mahua.dtsi b/arch/arm64/boot/dts/qcom/mahua.dtsi
index eb45adc8a0a2..e6c059708912 100644
--- a/arch/arm64/boot/dts/qcom/mahua.dtsi
+++ b/arch/arm64/boot/dts/qcom/mahua.dtsi
@@ -115,6 +115,15 @@ &oobm_ss_noc {
compatible = "qcom,mahua-oobm-ss-noc", "qcom,glymur-oobm-ss-noc";
};
+&pcie5_phy {
+ clocks = <&gcc GCC_PCIE_PHY_5_AUX_CLK>,
+ <&gcc GCC_PCIE_5_CFG_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_PCIE_5_PHY_RCHNG_CLK>,
+ <&gcc GCC_PCIE_5_PIPE_CLK>,
+ <&gcc GCC_PCIE_5_PIPE_DIV2_CLK>;
+};
+
&pcie_east_anoc {
compatible = "qcom,mahua-pcie-east-anoc", "qcom,glymur-pcie-east-anoc";
};
--
2.34.1
^ permalink raw reply related
* RE: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level triggered.
From: Selvamani Rajagopal @ 2026-06-22 5:14 UTC (permalink / raw)
To: Parthiban.Veerasooran@microchip.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Piergiorgio Beruto
Cc: andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Conor.Dooley@microchip.com,
devicetree@vger.kernel.org
In-Reply-To: <CYYPR02MB9828CD98EEEB9B218A940E4483E32@CYYPR02MB9828.namprd02.prod.outlook.com>
>
> AI review bot Sashiko suggested one potential issue where skb pointers aren't protected.
> But those
> concerns are in transmit path. This crash seems to be in receive path. If you think that
> might help,
> I can generate a patch for that.
Parthiban,
I just submitted a patch for "net" tree. I was able to see one crash though. Crash signature
was different from yours. As I remember, yours is NULL pointer access. Mine was due to
trying to place the data beyond the "end" point.
Anyway, if you have time to spare and want to try and see if it fixes your crash, I would appreciate
the feedback..
https://patchwork.kernel.org/project/netdevbpf/list/?series=1114495
>
> What do you suggest? Since you are able to see the crash, would you have time to
> investigate?
>
> Sincerely
> Selva
^ permalink raw reply
* Re: [PATCH v6 2/8] dt-bindings: clock: qcom,glymur-tcsr: Add mahua support
From: sashiko-bot @ 2026-06-22 5:16 UTC (permalink / raw)
To: Qiang Yu; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260621-tcsr_qref_0622-v6-2-c939c22ded0c@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Medium] The binding defines clock and reset provider capabilities but fails to mandate `#clock-cells` and `#reset-cells` in the global `required` list.
--
commit e33e967e97849b6db5ce0ac256cca1e6c9d83b22
Author: Qiang Yu <qiang.yu@oss.qualcomm.com>
dt-bindings: clock: qcom,glymur-tcsr: Add mahua support
This commit adds the qcom,mahua-tcsr compatible string alongside the existing
Glymur binding. It updates the conditionals and required supply properties to
account for Mahua's single QREF block topology.
> diff --git a/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
> index 16fc6ab87f9b6..2b64226271657 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
> +++ b/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
[ ... ]
> required:
> - compatible
> - clocks
[Severity: Medium]
This is a pre-existing issue, but since this hardware acts as a clock and
reset provider, shouldn't properties like #clock-cells, #reset-cells, and reg
be included in this global required list? Without these mandated properties,
incomplete device tree nodes might silently pass schema validation and cause
runtime failures when consumers attempt to reference the clocks or resets.
> - - vdda-qrefrpt0-0p9-supply
> - - vdda-qrefrpt1-0p9-supply
[ ... ]
> - - vdda-refgen4-0p9-supply
> - - vdda-refgen4-1p2-supply
>
> additionalProperties: false
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com?part=2
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: misc: add binding for Xilinx AXI-Stream FIFO
From: Krzysztof Kozlowski @ 2026-06-22 5:18 UTC (permalink / raw)
To: Aditya Chari S, robh, krzk+dt, conor+dt, gregkh
Cc: jacobsfeder, devicetree, linux-staging, linux-kernel,
michal.simek, lucas.fariamo08
In-Reply-To: <CAKt_FXsiXv7dai+F7cT=GNvETa5_42su9G1ev8+_fph0Bg5EbA@mail.gmail.com>
On 22/06/2026 06:21, Aditya Chari S wrote:
> Sorry about the pace - jumped from automated lint feedback straight to
> a new version without waiting for an actual reviewer. Won't happen
> again.
>
> On the staging binding question - I found the driver-removal thread
> from June 2 and read through it. Michal Simek's reply makes clear this
> driver isn't going anywhere (their networking team has plans that
> depend on it), and that there's already an in-flight binding
> conversion from Lucas Faria Mendes that he's actively tracking. I
> wasn't aware of that series when I started this.
>
> Given that, I'll withdraw mine rather than duplicate work that's
> already further along and already has the relevant maintainer's eyes
> on it.
>
The main point is that driver is in staging, so we don't take bindings
for it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 1/8] dt-bindings: clock: qcom: Move glymur TCSR to own binding
From: sashiko-bot @ 2026-06-22 5:18 UTC (permalink / raw)
To: Qiang Yu; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260621-tcsr_qref_0622-v6-1-c939c22ded0c@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message claims to 'Mark the relevant supplies as required per compatible using allOf/if/then conditionals', but the implementation uses an unconditional global `required` list. The conditionals are actually introduced in the subsequent patch 'dt-bindings: clock: qcom,glymur-tcsr: Add mahua support', making the commit message for this patch inaccurate.
--
commit 76f46a44f2c67eac7f27a435d31cca7e4ee64c0c
Author: Qiang Yu <qiang.yu@oss.qualcomm.com>
dt-bindings: clock: qcom: Move glymur TCSR to own binding
This commit creates a dedicated binding file for the Qualcomm TCSR clock
controller on Glymur, moving it out of the shared sm8550-tcsr binding. It
also documents the supply properties required for the QREF block.
> Mark the relevant supplies as required per compatible using allOf/if/then
> conditionals.
[Severity: Medium]
Is this description accurate for this specific patch? The commit message
mentions using allOf/if/then conditionals to mark supplies as required per
compatible, but the required list introduced in qcom,glymur-tcsr.yaml is
unconditional and global.
Could this paragraph in the commit message have been intended for a
subsequent patch that introduces the allOf/if/then conditionals?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH v6 5/8] clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support
From: sashiko-bot @ 2026-06-22 5:21 UTC (permalink / raw)
To: Qiang Yu; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260621-tcsr_qref_0622-v6-5-c939c22ded0c@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing regulator specifications for non-PCIe clocks (EDP, USB) in Mahua TCSR descriptors
--
commit 6c7380c66661cd5b69976b7e56fdb61f281c6291
Author: Qiang Yu <qiang.yu@oss.qualcomm.com>
clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support
This commit adds Mahua-specific regulator arrays and clock descriptor tables
for PCIe clock references. It uses match_data to select the correct descriptor
table based on the compatible string during probe.
> diff --git a/drivers/clk/qcom/tcsrcc-glymur.c b/drivers/clk/qcom/tcsrcc-glymur.c
> index 2db039342f300..9af520b71f315 100644
> --- a/drivers/clk/qcom/tcsrcc-glymur.c
> +++ b/drivers/clk/qcom/tcsrcc-glymur.c
[ ... ]
> +static const struct qcom_clk_ref_desc tcsr_cc_mahua_clk_descs[] = {
> + [TCSR_EDP_CLKREF_EN] = {
> + .name = "tcsr_edp_clkref_en",
> + .offset = 0x60,
> + },
> + [TCSR_PCIE_2_CLKREF_EN] = {
> + .name = "tcsr_pcie_2_clkref_en",
> + .offset = 0x4c,
> + .regulator_names = mahua_tcsr_tx1_rpt01_rx1_regulators,
> + .num_regulators = ARRAY_SIZE(mahua_tcsr_tx1_rpt01_rx1_regulators),
> + },
[ ... ]
> + [TCSR_USB4_1_CLKREF_EN] = {
> + .name = "tcsr_usb4_1_clkref_en",
> + .offset = 0x44,
> + },
> + [TCSR_USB4_2_CLKREF_EN] = {
> + .name = "tcsr_usb4_2_clkref_en",
> + .offset = 0x5c,
> + },
> +};
[Severity: High]
Do we need regulator specifications for the non-PCIe clocks (EDP, USB2, USB3,
USB4) in this descriptor table?
Since this array only populates regulator_names for the PCIe clocks, the
non-PCIe entries are left with 0 regulators.
When the USB or eDP PHY drivers call clk_prepare_enable() on their clkrefs,
will qcom_clk_ref_prepare() just set the hardware register bit and silently
skip voting for the required LDOs?
If so, does this leave the QREF block unpowered for these peripherals and
prevent the PHYs from initializing?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com?part=5
^ permalink raw reply
* Re: [PATCH v6 6/8] arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR
From: sashiko-bot @ 2026-06-22 5:21 UTC (permalink / raw)
To: Qiang Yu; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260621-tcsr_qref_0622-v6-6-c939c22ded0c@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing regulator definitions for Mahua USB and EDP clock references, leading to unpowered PHY components.
--
commit e43024044dc26df2e1498b871bce2a3a9aa15cab
Author: Qiang Yu <qiang.yu@oss.qualcomm.com>
arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR
The TCSR clkref_en clocks gate the QREF block which provides reference
clocks to the PCIe PHYs. Wire up the LDO supplies required by the QREF
and refgen blocks on the CRD board.
> diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dts b/arch/arm64/boot/dts/qcom/glymur-crd.dts
> index c98dfb3941fa3..92b929ee3448c 100644
> --- a/arch/arm64/boot/dts/qcom/glymur-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/glymur-crd.dts
[ ... ]
> @@ -278,6 +278,26 @@ &smb2370_k_e2_eusb2_repeater {
> vdd3-supply = <&vreg_l7b_e0_2p79>;
> };
>
> +&tcsr {
> + vdda-qrefrpt0-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrpt1-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrpt2-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrpt3-0p9-supply = <&vreg_l2h_e0_0p72>;
> + vdda-qrefrpt4-0p9-supply = <&vreg_l2h_e0_0p72>;
> + vdda-qrefrx0-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrx1-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrx2-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrx4-0p9-supply = <&vreg_l2h_e0_0p72>;
> + vdda-qrefrx5-0p9-supply = <&vreg_l3f_e0_0p72>;
> + vdda-qreftx0-0p9-supply = <&vreg_l3f_e0_0p72>;
> + vdda-qreftx0-1p2-supply = <&vreg_l4h_e0_1p2>;
> + vdda-qreftx1-0p9-supply = <&vreg_l1f_e1_0p82>;
> + vdda-refgen3-0p9-supply = <&vreg_l2f_e0_0p82>;
> + vdda-refgen3-1p2-supply = <&vreg_l4h_e0_1p2>;
> + vdda-refgen4-0p9-supply = <&vreg_l1f_e1_0p82>;
> + vdda-refgen4-1p2-supply = <&vreg_l4f_e1_1p08>;
> +};
[Severity: High]
Does this setup overlook the regulator definitions for Mahua USB and EDP clock
references?
In drivers/clk/qcom/tcsrcc-glymur.c, the tcsr_cc_mahua_clk_descs array omits
.regulator_names and .num_regulators for all USB and EDP clocks:
drivers/clk/qcom/tcsrcc-glymur.c:tcsr_cc_mahua_clk_descs[] = {
[TCSR_EDP_CLKREF_EN] = {
.name = "tcsr_edp_clkref_en",
.offset = 0x60,
},
...
The qcom,mahua-tcsr DT binding and the Mahua CRD explicitly list and require
regulators for these blocks: vdda-qrefrpt3-0p9-supply,
vdda-qrefrpt4-0p9-supply, vdda-qrefrpt5-0p9-supply, and
vdda-qrefrx3-0p9-supply.
Because .num_regulators is 0 for these clocks, qcom_clk_ref_register() will
not call devm_regulator_bulk_get(), and qcom_clk_ref_prepare() will never
enable the regulators.
Can this cause a silent hardware failure where major peripherals like USB and
EDP PHYs are conceptually enabled but their corresponding TCSR QREF blocks
remain completely unpowered?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com?part=6
^ permalink raw reply
* Re: [PATCH v6 7/8] arm64: dts: qcom: mahua: Add QREF regulator supplies to TCSR
From: sashiko-bot @ 2026-06-22 5:22 UTC (permalink / raw)
To: Qiang Yu; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260621-tcsr_qref_0622-v6-7-c939c22ded0c@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The device tree patch wires up `vdda-qrefrpt3-0p9-supply`, `vdda-qrefrpt4-0p9-supply`, `vdda-qrefrpt5-0p9-supply`, and `vdda-qrefrx3-0p9-supply` for the Mahua TCSR node, and the DT binding explicitly lists them as required properties for `qcom,mahua-tcsr`. However, the driver implementation (`tcsrcc-glymur.c`) defines Mahua's regulator arrays (`mahua_tcsr_tx1_rpt01_rx1_regulators` and `mahua_tcsr_tx1_rpt012_rx2_regulators`) without including these supplies. As a result, no clock descriptors in `tcsr_cc_mahua_clk_descs` consume these regulators, and they will never be requested or enabled by the clock driver.
--
commit 9b4597bbc60b4b7a8b61f25b5d65fb4f6eb028c9
Author: Qiang Yu <qiang.yu@oss.qualcomm.com>
arm64: dts: qcom: mahua: Add QREF regulator supplies to TCSR
This commit wires up the required LDO supplies for the PCIe clkref paths
on the Mahua CRD board by overriding the TCSR compatible and adding the
regulators to the tcsr node.
> diff --git a/arch/arm64/boot/dts/qcom/mahua-crd.dts b/arch/arm64/boot/dts/qcom/mahua-crd.dts
> --- a/arch/arm64/boot/dts/qcom/mahua-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/mahua-crd.dts
[ ... ]
> @@ -19,3 +19,18 @@ / {
> model = "Qualcomm Technologies, Inc. Mahua CRD";
> compatible = "qcom,mahua-crd", "qcom,mahua";
> };
> +
> +&tcsr {
> + vdda-qrefrpt0-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrpt1-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrpt2-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrpt3-0p9-supply = <&vreg_l1f_e1_0p82>;
> + vdda-qrefrpt4-0p9-supply = <&vreg_l2h_e0_0p72>;
> + vdda-qrefrpt5-0p9-supply = <&vreg_l2h_e0_0p72>;
> + vdda-qrefrx1-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrx2-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrx3-0p9-supply = <&vreg_l2h_e0_0p72>;
[Severity: High]
Will these supplies actually be enabled by the clock driver?
While they are properly wired up here in the device tree, looking at the
underlying driver implementation in drivers/clk/qcom/tcsrcc-glymur.c, the
regulator arrays for Mahua seem to omit several of these supplies:
drivers/clk/qcom/tcsrcc-glymur.c:mahua_tcsr_tx1_rpt01_rx1_regulators[] = {
"vdda-refgen3-0p9",
"vdda-refgen3-1p2",
"vdda-qreftx1-0p9",
"vdda-qrefrpt0-0p9",
"vdda-qrefrpt1-0p9",
"vdda-qrefrx1-0p9",
};
Because vdda-qrefrpt3-0p9, vdda-qrefrpt4-0p9, vdda-qrefrpt5-0p9, and
vdda-qrefrx3-0p9 aren't included in the driver's regulator lists or
clock descriptors (tcsr_cc_mahua_clk_descs), it appears the driver will
never request or enable them.
Could this prevent the reference clock from reaching the PHY and cause
initialization failures for the dependent hardware block?
> + vdda-qreftx1-0p9-supply = <&vreg_l1f_e1_0p82>;
> + vdda-refgen3-0p9-supply = <&vreg_l1f_e1_0p82>;
> + vdda-refgen3-1p2-supply = <&vreg_l4f_e1_1p08>;
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com?part=7
^ permalink raw reply
* Re: [PATCH v6 3/8] clk: qcom: Add generic clkref_en support
From: sashiko-bot @ 2026-06-22 5:24 UTC (permalink / raw)
To: Qiang Yu; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260621-tcsr_qref_0622-v6-3-c939c22ded0c@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `qcom_clk_ref_probe` API maps memory resource 0 exclusively, preventing its reuse by parent drivers like TLMM that already map their register space.
- [Medium] Missing `args_count` validation in the clock provider getter leads to an uninitialized stack memory read.
--
commit 425b78640ada4c9c7a746a68fc9313af14a52bae
Author: Qiang Yu <qiang.yu@oss.qualcomm.com>
clk: qcom: Add generic clkref_en support
This patch introduces generic support for Qualcomm clkref_en clocks. It
provides a dedicated clk_ref clock type and a common registration API to be
reused across different blocks like TCSR and TLMM.
> diff --git a/drivers/clk/qcom/clk-ref.c b/drivers/clk/qcom/clk-ref.c
> new file mode 100644
> index 0000000000000..8132e510f43c0
> --- /dev/null
> +++ b/drivers/clk/qcom/clk-ref.c
[ ... ]
> +static struct clk_hw *qcom_clk_ref_provider_get(struct of_phandle_args *clkspec, void *data)
> +{
> + struct qcom_clk_ref_provider *provider = data;
> + unsigned int idx = clkspec->args[0];
[Severity: Medium]
What happens if the provider node is misconfigured with #clock-cells = <0>?
If clkspec->args_count is 0, won't this read uninitialized stack memory from
clkspec->args[0] and potentially grant access to a random valid clock?
Should this validate that clkspec->args_count is at least 1 before accessing
the arguments array?
> +
> + if (idx >= provider->num_refs)
> + return ERR_PTR(-EINVAL);
[ ... ]
> +int qcom_clk_ref_probe(struct platform_device *pdev,
> + const struct regmap_config *config,
> + const struct qcom_clk_ref_desc *descs,
> + size_t num_clk_refs)
> +{
> + struct qcom_clk_ref_provider *provider;
> + struct device *dev = &pdev->dev;
> + struct regmap *regmap;
> + void __iomem *base;
> + int ret;
> +
> + base = devm_platform_ioremap_resource(pdev, 0);
[Severity: Medium]
Will this fail with -EBUSY when used by TLMM?
The commit message mentions this API will be used for TLMM on SM8750. However,
devm_platform_ioremap_resource() requests exclusive ownership of the memory
region. The TLMM driver already maps its entire register space during probe.
If TLMM has already mapped the region, won't this subsequent attempt to map
the same region fail?
Would it be better to have the caller pass an already instantiated struct
regmap pointer instead of mapping the region inside the generic probe?
> + if (IS_ERR(base))
> + return PTR_ERR(base);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com?part=3
^ permalink raw reply
* Re: [PATCH v5] dt-bindings: misc: convert lis302.txt to YAML
From: Krzysztof Kozlowski @ 2026-06-22 5:27 UTC (permalink / raw)
To: Jad Keskes, Eric Piel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Jonathan Cameron, devicetree, linux-kernel
In-Reply-To: <20260619125902.893742-1-inasj268@gmail.com>
On 19/06/2026 14:59, Jad Keskes wrote:
> Replace the old lis302.txt with a YAML binding covering all four
> compatibles (st,lis3lv02d, st,lis302dl-spi, st,lis331dlh,
> st,lis33de) and their ~35 DT properties.
>
> The old txt documented st,click-thresh-* and st,click-click-time-limit
> but the code reads st,click-threshold-* and st,click-time-limit.
> Keep the old names as deprecated so existing DTBs don't break.
>
> Tested: dt_binding_check. dtbs_check against 7 omap/am335x DTBs
> (am335x-evm, am335x-evmsk, am335x-pepper, am437x-sk-evm, omap3-n900,
How can you test binding on a device? This is not possible.
> omap3-n950, omap3-gta04a3) — no misc schema errors. Pre-existing
> IIO schema errors on paired compatible nodes unchanged.
>
> Signed-off-by: Jad Keskes <inasj268@gmail.com>
> ---
Slow down. You sent five versions within one hour. You did not even wait
for any feedback, so what is the point?
This is already being done by other people.
https://lore.kernel.org/all/?q=dfn%3Alis302
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6] dt-bindings: misc: convert lis302.txt to YAML
From: Krzysztof Kozlowski @ 2026-06-22 5:27 UTC (permalink / raw)
To: Jad Keskes, Eric Piel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Jonathan Cameron, devicetree, linux-kernel
In-Reply-To: <20260619131448.906433-1-inasj268@gmail.com>
On 19/06/2026 15:14, Jad Keskes wrote:
> Replace the old lis302.txt with a YAML binding covering all four
> compatibles (st,lis3lv02d, st,lis302dl-spi, st,lis331dlh,
> st,lis33de) and their ~35 DT properties.
>
> The old txt documented st,click-thresh-* and st,click-click-time-limit
> but the code reads st,click-threshold-* and st,click-time-limit.
> Keep the old names as deprecated so existing DTBs don't break.
>
> Tested: dt_binding_check. dtbs_check against 7 omap/am335x DTBs
> (am335x-evm, am335x-evmsk, am335x-pepper, am437x-sk-evm, omap3-n900,
No. Impossible.
> omap3-n950, omap3-gta04a3) — no misc schema errors. Pre-existing
> IIO schema errors on paired compatible nodes unchanged.
>
> Signed-off-by: Jad Keskes <inasj268@gmail.com>
> ---
>
> v6:
> - ACTUALLY commit the changes this time (git add before git commit --amend)
> - Remove redundant select block
> - Remove Vdd-supply/Vdd_IO-supply: false from SPI branch
> - Split allOf into two independent if/then branches
> .../devicetree/bindings/iio/accel/lis302.txt | 119 ------
And ANOTHER version!
Slow down. You sent five versions within one hour. You did not even wait
for any feedback, so what is the point?
This is already being done by other people.
https://lore.kernel.org/all/?q=dfn%3Alis302
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Sherry Sun @ 2026-06-22 5:52 UTC (permalink / raw)
To: Frank Li (OSS), Sherry Sun (OSS)
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, Amitkumar Karwar, Neeraj Sanjay Kale,
marcel@holtmann.org, luiz.dentz@gmail.com, Hongxing Zhu,
l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com,
brgl@kernel.org, imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-pm@vger.kernel.org
In-Reply-To: <ajQ64ZswbmTceIGO@SMW015318>
> On Thu, Jun 18, 2026 at 06:10:40PM +0800, Sherry Sun (OSS) wrote:
> > From: Sherry Sun <sherry.sun@nxp.com>
> >
> > Use dw_pcie::skip_pwrctrl_off to avoid powering off devices during
> > suspend to preserve wakeup capability of the devices and also not to
> > power on the devices in the init path.
> > This allows controller power-off to be skipped when some devices(e.g.
> > M.2 cards key E without auxiliary power) required to support PCIe L2
> > link state and wake-up mechanisms.
> >
> > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > ---
> > drivers/pci/controller/dwc/pci-imx6.c | 36
> > +++++++++++++++++----------
> > 1 file changed, 23 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 0fa716d1ed75..ff5a9565dbbf 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -1382,16 +1382,20 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> *pp)
> > }
> > }
> >
> > - ret = pci_pwrctrl_create_devices(dev);
> > - if (ret) {
> > - dev_err(dev, "failed to create pwrctrl devices\n");
> > - goto err_reg_disable;
> > + if (!pci->suspended) {
> > + ret = pci_pwrctrl_create_devices(dev);
> > + if (ret) {
> > + dev_err(dev, "failed to create pwrctrl devices\n");
> > + goto err_reg_disable;
> > + }
>
> supposed create_devices only do once.
>
> pci_pwrctrl_power_on_devices() controller on and off for difference case.
>
Hi Frank,
Yes, pci_pwrctrl_create_devices() is currently only called once
during imx_pcie_probe.
pci_pwrctrl_power_on_devices() is called during imx_pcie_probe
and during suspend/resume (depending on skip_pwrctrl_off flag).
Best Regards
Sherry
> > }
> >
> > - ret = pci_pwrctrl_power_on_devices(dev);
> > - if (ret) {
> > - dev_err(dev, "failed to power on pwrctrl devices\n");
> > - goto err_pwrctrl_destroy;
> > + if (!pp->skip_pwrctrl_off) {
> > + ret = pci_pwrctrl_power_on_devices(dev);
> > + if (ret) {
> > + dev_err(dev, "failed to power on pwrctrl devices\n");
> > + goto err_pwrctrl_destroy;
> > + }
> > }
> >
> > ret = imx_pcie_clk_enable(imx_pcie); @@ -1460,9 +1464,10 @@
> static
> > int imx_pcie_host_init(struct dw_pcie_rp *pp)
> > err_clk_disable:
> > imx_pcie_clk_disable(imx_pcie);
> > err_pwrctrl_power_off:
> > - pci_pwrctrl_power_off_devices(dev);
> > + if (!pp->skip_pwrctrl_off)
> > + pci_pwrctrl_power_off_devices(dev);
> > err_pwrctrl_destroy:
> > - if (ret != -EPROBE_DEFER)
> > + if (ret != -EPROBE_DEFER && !pci->suspended)
> > pci_pwrctrl_destroy_devices(dev);
> > err_reg_disable:
> > if (imx_pcie->vpcie)
> > @@ -1482,7 +1487,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp
> *pp)
> > }
> > imx_pcie_clk_disable(imx_pcie);
> >
> > - pci_pwrctrl_power_off_devices(pci->dev);
> > + if (!pci->pp.skip_pwrctrl_off)
> > + pci_pwrctrl_power_off_devices(pci->dev);
> > if (imx_pcie->vpcie)
> > regulator_disable(imx_pcie->vpcie);
> > }
> > @@ -1990,12 +1996,16 @@ static int imx_pcie_probe(struct
> > platform_device *pdev) static void imx_pcie_shutdown(struct
> > platform_device *pdev) {
> > struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> > + struct dw_pcie *pci = imx_pcie->pci;
> > + struct dw_pcie_rp *pp = &pci->pp;
> >
> > /* bring down link, so bootloader gets clean state in case of reboot */
> > imx_pcie_assert_core_reset(imx_pcie);
> > imx_pcie_assert_perst(imx_pcie, true);
> > - pci_pwrctrl_power_off_devices(&pdev->dev);
> > - pci_pwrctrl_destroy_devices(&pdev->dev);
> > + if (!pp->skip_pwrctrl_off)
> > + pci_pwrctrl_power_off_devices(&pdev->dev);
> > + if (!pci->suspended)
> > + pci_pwrctrl_destroy_devices(&pdev->dev);
> > }
> >
> > static const struct imx_pcie_drvdata drvdata[] = {
> > --
> > 2.50.1
> >
> >
^ permalink raw reply
* [PATCH v3] arm64: dts: qcom: install DT overlays via dtbs_install
From: Vishwas Udupa @ 2026-06-22 5:52 UTC (permalink / raw)
To: andersson
Cc: vudupa, conor+dt, devicetree, kbajaj, konradybcio, krzk+dt,
linux-arm-msm, robh, snb, lminier, Vishwas Udupa
In-Reply-To: <20260428123725.3457865-1-vudupa@qti.qualcomm.com>
Overlay binaries (.dtbo) are currently only built implicitly as
dependencies of composite firmware images and are therefore absent from the
kernel install output.
Even when final DTBs are produced at build time, some distributions rely on
standalone DTBOs for runtime selection and application by bootloaders or
firmware. Without explicit install targets, DTBOs are not picked up by the
standard dtbs_install flow and therefore cannot be packaged alongside DTBs.
Add explicit dtb-$(CONFIG_ARCH_QCOM) entries for DT overlays defined in
this Makefile so they are installed via dtbs_install, matching existing DTB
install behaviour, while excluding EL2 DTBOs as they are not intended for
independent use and are only meaningful in conjunction with their base DTBs.
Signed-off-by: Vishwas Udupa <vishwas.udupa@oss.qualcomm.com>
---
Changes in v3:
- Address review feedback from sashiko on commit message
- Link to v2: https://lore.kernel.org/all/20260619180951.325272-1-vishwas.udupa@oss.qualcomm.com/
Changes in v2:
- Address review feedback from Krzysztof Kozlowski
- Drop inclusion of EL2 DTBOs
- Link to v1: https://lore.kernel.org/all/20260428123725.3457865-1-vudupa@qti.qualcomm.com/
arch/arm64/boot/dts/qcom/Makefile | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 4ba8e7306419..44ed2b591363 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -7,7 +7,9 @@ apq8016-sbc-usb-host-dtbs := apq8016-sbc.dtb apq8016-sbc-usb-host.dtbo
dtb-$(CONFIG_ARCH_QCOM) += sar2130p-qar2130p.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc-d3-camera-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc-d3-camera-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc-usb-host.dtb
+dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc-usb-host.dtbo
dtb-$(CONFIG_ARCH_QCOM) += apq8016-schneider-hmibsc.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8039-t2.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8094-sony-xperia-kitakami-karin_windy.dtb
@@ -47,13 +49,16 @@ lemans-evk-camera-csi1-imx577-dtbs := lemans-evk.dtb lemans-evk-camera-csi1-imx5
lemans-evk-camera-dtbs := lemans-evk.dtb lemans-evk-camera.dtbo
dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-camera-csi1-imx577.dtb
+dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-camera-csi1-imx577.dtbo
dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-camera.dtb
+dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-camera.dtbo
lemans-evk-el2-dtbs := lemans-evk.dtb lemans-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-el2.dtb
lemans-evk-ifp-mezzanine-dtbs := lemans-evk.dtb lemans-evk-ifp-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-ifp-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-ifp-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += mahua-crd.dtb
dtb-$(CONFIG_ARCH_QCOM) += milos-fairphone-fp6.dtb
dtb-$(CONFIG_ARCH_QCOM) += monaco-arduino-monza.dtb
@@ -61,12 +66,14 @@ dtb-$(CONFIG_ARCH_QCOM) += monaco-evk.dtb
monaco-evk-camera-imx577-dtbs := monaco-evk.dtb monaco-evk-camera-imx577.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-camera-imx577.dtb
+dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-camera-imx577.dtbo
monaco-evk-el2-dtbs := monaco-evk.dtb monaco-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-el2.dtb
monaco-evk-ifp-mezzanine-dtbs := monaco-evk.dtb monaco-evk-ifp-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-ifp-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-ifp-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += msm8216-samsung-fortuna3g.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-acer-a1-724.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-alcatel-idol347.dtb
@@ -175,7 +182,9 @@ qcs6490-rb3gen2-vision-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-vis
qcs6490-rb3gen2-industrial-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-industrial-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-industrial-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-industrial-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-vision-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-vision-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-thundercomm-minipc-g1iot.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-thundercomm-rubikpi3.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
@@ -199,6 +208,7 @@ dtb-$(CONFIG_ARCH_QCOM) += qrb2210-rb1.dtb
qrb2210-rb1-vision-mezzanine-dtbs := qrb2210-rb1.dtb qrb2210-rb1-vision-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qrb2210-rb1-vision-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qrb2210-rb1-vision-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qrb4210-rb2.dtb
dtb-$(CONFIG_ARCH_QCOM) += qrb5165-rb5.dtb
@@ -206,6 +216,7 @@ dtb-$(CONFIG_ARCH_QCOM) += qrb5165-rb5.dtb
qrb5165-rb5-vision-mezzanine-dtbs := qrb5165-rb5.dtb qrb5165-rb5-vision-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qrb5165-rb5-vision-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qrb5165-rb5-vision-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qru1000-idp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sa8155p-adp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sa8295p-adp.dtb
@@ -308,6 +319,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c.dtb
sdm845-db845c-navigation-mezzanine-dtbs := sdm845-db845c.dtb sdm845-db845c-navigation-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c-navigation-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c-navigation-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += sdm845-google-crosshatch.dtb
dtb-$(CONFIG_ARCH_QCOM) += sdm845-google-blueline.dtb
dtb-$(CONFIG_ARCH_QCOM) += sdm845-lg-judyln.dtb
@@ -372,7 +384,9 @@ sm8550-hdk-rear-camera-card-dtbs := sm8550-hdk.dtb sm8550-hdk-rear-camera-card.d
dtb-$(CONFIG_ARCH_QCOM) += sm8550-hdk-display-card-rear-camera-card.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-hdk-display-card.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sm8550-hdk-display-card.dtbo
dtb-$(CONFIG_ARCH_QCOM) += sm8550-hdk-rear-camera-card.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sm8550-hdk-rear-camera-card.dtbo
dtb-$(CONFIG_ARCH_QCOM) += sm8550-hdk.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-qrd.dtb
@@ -386,7 +400,9 @@ sm8650-hdk-rear-camera-card-dtbs := sm8650-hdk.dtb sm8650-hdk-rear-camera-card.d
dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk-display-card-rear-camera-card.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk-display-card.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk-display-card.dtbo
dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk-rear-camera-card.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk-rear-camera-card.dtbo
dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8650-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8650-qrd.dtb
@@ -395,12 +411,14 @@ dtb-$(CONFIG_ARCH_QCOM) += sm8750-qrd.dtb
dtb-$(CONFIG_ARCH_QCOM) += talos-evk.dtb
talos-evk-usb1-peripheral-dtbs := talos-evk.dtb talos-evk-usb1-peripheral.dtbo
dtb-$(CONFIG_ARCH_QCOM) += talos-evk-usb1-peripheral.dtb
+dtb-$(CONFIG_ARCH_QCOM) += talos-evk-usb1-peripheral.dtbo
dtb-$(CONFIG_ARCH_QCOM) += talos-evk-camera-imx577.dtbo
talos-evk-camera-imx577-dtbs := talos-evk.dtb talos-evk-camera-imx577.dtbo
dtb-$(CONFIG_ARCH_QCOM) += talos-evk-camera-imx577.dtb
talos-evk-lvds-auo,g133han01-dtbs := \
talos-evk.dtb talos-evk-lvds-auo,g133han01.dtbo
dtb-$(CONFIG_ARCH_QCOM) += talos-evk-lvds-auo,g133han01.dtb
+dtb-$(CONFIG_ARCH_QCOM) += talos-evk-lvds-auo,g133han01.dtbo
x1e001de-devkit-el2-dtbs := x1e001de-devkit.dtb x1-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += x1e001de-devkit.dtb x1e001de-devkit-el2.dtb
x1e78100-lenovo-thinkpad-t14s-el2-dtbs := x1e78100-lenovo-thinkpad-t14s.dtb x1-el2.dtbo
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] media: i2c: add imx576 image sensor driver
From: Himanshu Bhavani @ 2026-06-22 6:02 UTC (permalink / raw)
To: Laurent Pinchart
Cc: sakari.ailus@linux.intel.com, luca.weiss@fairphone.com,
Hardevsinh Palaniya, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Hans Verkuil, Hans de Goede, Vladimir Zapolskiy, Elgin Perumbilly,
Walter Werner Schneider, Kate Hsuan, Svyatoslav Ryhel,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
In-Reply-To: <20260620132749.GE3552167@killaraus.ideasonboard.com>
Hi Laurent,
>On Fri, Jun 19, 2026 at 06:24:32PM +0530, Himanshu Bhavani wrote:
>> Add a v4l2 subdevice driver for the Sony imx576 sensor.
>>
>> The Sony IMX576 image sensor with an active
>> array size of 5760 x 4312
>>
>> The following features are supported:
>> - Manual exposure an gain control support
>> - vblank/hblank control support
>> - Supported resolution: 2880 x 2156 30fps (SRGGB10)
>
>You've been asked in v1 to make this driver dynamically compute
>registers instead of hardcoding modes. Please do so in v3. Nack on v2.
As I mentioned earlier, I don't have the full datasheet yet, so I can't implement this now.
Link to discussion:
https://lore.kernel.org/linux-media/PN0P287MB2019AFCBDF0E24BFEF8E0E399A0F2@PN0P287MB2019.INDP287.PROD.OUTLOOK.COM/
Best regards,
Himanshu
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: lemans-evk: Describe the PCIe M.2 Key E connector
From: Wei Deng @ 2026-06-22 6:02 UTC (permalink / raw)
To: konrad.dybcio
Cc: andersson, robh, krzk+dt, conor+dt, mani, brgl, linux-arm-msm,
devicetree, linux-kernel, linux-pci, linux-pm, quic_chezhou,
cheng.jiang, shuai.zhang, jinwang.li, xiuzhuo.shang, mengshi.wu
In-Reply-To: <580db7de-321d-4f4e-99f9-3c9a1cc5a3f9@oss.qualcomm.com>
Hi Konrad,
On Thu, Jun 18, 2026 at 11:49:05AM +0200, Konrad Dybcio wrote:
> On 6/8/26 11:17 AM, Wei Deng wrote:
> > The lemans EVK has the PCIe M.2 Mechanical Key E connector to connect
> > wireless connectivity cards over PCIe and UART interfaces. Hence,
> > describe the connector node and link it with the PCIe 0 Root Port and
> > UART17 nodes through graph port/endpoint.
> >
> > Also add 'compatible = "pciclass,0604"' to the pcieport0 node in
> > lemans.dtsi to allow the PCI subsystem to associate the DT node with
> > the PCI-to-PCI bridge device.
>
> Ideally this would be a separate change
>
> Also, b4 can't grab this patch since there's something wrong with the
> threading (multiple series in a single thread) - please switch to using
> b4 for submissions yourself to avoid such mistakes.
>
> https://b4.docs.kernel.org/en/latest/
>
> Konrad
Thanks for the review. Agreed. Posting shortly.
--
Best Regards,
Wei Deng
^ 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