[PATCH V2 0/4] Enable UFS MCQ support for SM8650 and SM8750

[PATCH V2 0/4] Enable UFS MCQ support for SM8650 and SM8750

[Ram Kumar Dwivedi]

This patch series enables Multi-Circular Queue (MCQ) support for the UFS 
host controller on Qualcomm SM8650 and SM8750 platforms. MCQ is a modern
queuing model that improves performance and scalability by allowing
multiple hardware queues.

Patch 1 updates the device tree bindings to allow the additional register
regions and reg-names required for MCQ operation.

Patches 2 and 3 update the device trees for SM8650 and SM8750 respectively
to enable MCQ by adding the necessary register mappings and MSI parent.

Patch 4 is streamlining UFS MCQ resource mapping with a single MCQ region
mapping.

Tested on SM8650 and SM8750.

Changes from v1: 
1. As per Krzysztof's suggestion, replaced mcq_vs and mcq_sqd DT mappings
   with a single MCQ region mapping.
2. Minor changes in commit messge as per Krzysztof's suggestion.

Nitin Rawat (1):
  ufs: ufs-qcom: Streamline UFS MCQ resource mapping

Palash Kambar (1):
  arm64: dts: qcom: sm8750: Enable MCQ support for UFS controller

Ram Kumar Dwivedi (2):
  dt-bindings: ufs: qcom: Document MCQ register space for UFS
  arm64: dts: qcom: sm8650: Enable MCQ support for UFS controller

 .../devicetree/bindings/ufs/qcom,ufs.yaml     |  16 +-
 arch/arm64/boot/dts/qcom/sm8650.dtsi          |   7 +-
 arch/arm64/boot/dts/qcom/sm8750.dtsi          |   8 +-
 drivers/ufs/host/ufs-qcom.c                   | 146 +++++++-----------
 drivers/ufs/host/ufs-qcom.h                   |  21 ++-
 5 files changed, 94 insertions(+), 104 deletions(-)

-- 
2.50.1

[PATCH V2 1/4] dt-bindings: ufs: qcom: Document MCQ register space for UFS

[Ram Kumar Dwivedi]

Document Multi-Circular Queue (MCQ) register space for
Qualcomm UFS controllers.

Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
---
 .../devicetree/bindings/ufs/qcom,ufs.yaml        | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
index 6c6043d9809e..daf681b0e23b 100644
--- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
@@ -89,9 +89,13 @@ properties:
     maxItems: 2
 
   reg-names:
-    items:
-      - const: std
-      - const: ice
+    oneOf:
+      - items:
+          - const: std
+          - const: ice
+      - items:
+          - const: ufs_mem
+          - const: mcq
 
   required-opps:
     maxItems: 1
@@ -177,9 +181,9 @@ allOf:
             - const: rx_lane1_sync_clk
         reg:
           minItems: 1
-          maxItems: 1
+          maxItems: 2
         reg-names:
-          maxItems: 1
+          maxItems: 2
 
   - if:
       properties:
@@ -280,7 +284,7 @@ allOf:
     then:
       properties:
         reg:
-          maxItems: 1
+          maxItems: 2
         clocks:
           minItems: 7
           maxItems: 8
-- 
2.50.1

[PATCH V2 2/4] arm64: dts: qcom: sm8650: Enable MCQ support for UFS controller

[Ram Kumar Dwivedi]

Enable Multi-Circular Queue (MCQ) support for the UFS host controller
on the Qualcomm SM8650 platform by updating the device tree node. This
includes adding new register region for MCQ and specifying the MSI parent
required for MCQ operation.

Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
---
 arch/arm64/boot/dts/qcom/sm8650.dtsi | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index e14d3d778b71..1885d88abc3a 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -3982,7 +3982,10 @@ ufs_mem_phy: phy@1d80000 {
 
 		ufs_mem_hc: ufshc@1d84000 {
 			compatible = "qcom,sm8650-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
-			reg = <0 0x01d84000 0 0x3000>;
+			reg = <0 0x01d84000 0 0x3000>,
+			      <0 0x1da0000 0 0x15000>;
+			reg-names = "ufs_mem",
+				    "mcq";
 
 			interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH 0>;
 
@@ -4020,6 +4023,8 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 
 			iommus = <&apps_smmu 0x60 0>;
 
+			msi-parent = <&gic_its 0x60>;
+
 			lanes-per-direction = <2>;
 			qcom,ice = <&ice>;
 
-- 
2.50.1

[PATCH V2 3/4] arm64: dts: qcom: sm8750: Enable MCQ support for UFS controller

[Ram Kumar Dwivedi]

From: Palash Kambar <quic_pkambar@quicinc.com>

Enable Multi-Circular Queue (MCQ) support for the UFS host controller
on the Qualcomm SM8750 platform by updating the device tree node. This
includes adding new register region for MCQ and specifying the MSI parent
required for MCQ operation.

Signed-off-by: Palash Kambar <quic_pkambar@quicinc.com>
Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
---
 arch/arm64/boot/dts/qcom/sm8750.dtsi | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index 4643705021c6..3cd701ca4020 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -3329,7 +3329,10 @@ ufs_mem_phy: phy@1d80000 {
 
 		ufs_mem_hc: ufs@1d84000 {
 			compatible = "qcom,sm8750-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
-			reg = <0x0 0x01d84000 0x0 0x3000>;
+			reg = <0x0 0x01d84000 0x0 0x3000>,
+			      <0x0 0x1da0000  0x0 0x2000>;
+			reg-names = "ufs_mem",
+				    "mcq";
 
 			interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
 
@@ -3363,11 +3366,12 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 					     "cpu-ufs";
 
 			power-domains = <&gcc GCC_UFS_PHY_GDSC>;
+
 			required-opps = <&rpmhpd_opp_nom>;
 
 			iommus = <&apps_smmu 0x60 0>;
 			dma-coherent;
-
+			msi-parent = <&gic_its 0x60>;
 			lanes-per-direction = <2>;
 
 			phys = <&ufs_mem_phy>;
-- 
2.50.1

[PATCH V2 4/4] ufs: ufs-qcom: Streamline UFS MCQ resource mapping

[Ram Kumar Dwivedi]

From: Nitin Rawat <quic_nitirawa@quicinc.com>

The current MCQ resource configuration involves multiple resource
mappings and dynamic resource allocation.

Simplify the resource mapping by directly mapping the single "mcq"
resource from device tree to hba->mcq_base instead of mapping multiple
separate resources (RES_UFS, RES_MCQ, RES_MCQ_SQD, RES_MCQ_VS).

It also uses predefined offsets for MCQ doorbell registers (SQD,
CQD, SQIS, CQIS) relative to the MCQ base,providing clearer memory
layout clarity.

Additionally update vendor-specific register offset UFS_MEM_CQIS_VS
offset from 0x8 to 0x4008 to align with the hardware programming guide.

The new approach assumes the device tree provides a single "mcq"
resource that encompasses the entire MCQ configuration space, making
the driver more maintainable and less prone to resource mapping errors.

Co-developed-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com>
---
 drivers/ufs/host/ufs-qcom.c | 146 +++++++++++++-----------------------
 drivers/ufs/host/ufs-qcom.h |  21 +++++-
 2 files changed, 72 insertions(+), 95 deletions(-)

diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 76fc70503a62..984d16b4075a 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -1910,116 +1910,73 @@ static void ufs_qcom_config_scaling_param(struct ufs_hba *hba,
 	hba->clk_scaling.suspend_on_no_request = true;
 }
 
-/* Resources */
-static const struct ufshcd_res_info ufs_res_info[RES_MAX] = {
-	{.name = "ufs_mem",},
-	{.name = "mcq",},
-	/* Submission Queue DAO */
-	{.name = "mcq_sqd",},
-	/* Submission Queue Interrupt Status */
-	{.name = "mcq_sqis",},
-	/* Completion Queue DAO */
-	{.name = "mcq_cqd",},
-	/* Completion Queue Interrupt Status */
-	{.name = "mcq_cqis",},
-	/* MCQ vendor specific */
-	{.name = "mcq_vs",},
-};
-
 static int ufs_qcom_mcq_config_resource(struct ufs_hba *hba)
 {
 	struct platform_device *pdev = to_platform_device(hba->dev);
-	struct ufshcd_res_info *res;
-	struct resource *res_mem, *res_mcq;
-	int i, ret;
-
-	memcpy(hba->res, ufs_res_info, sizeof(ufs_res_info));
-
-	for (i = 0; i < RES_MAX; i++) {
-		res = &hba->res[i];
-		res->resource = platform_get_resource_byname(pdev,
-							     IORESOURCE_MEM,
-							     res->name);
-		if (!res->resource) {
-			dev_info(hba->dev, "Resource %s not provided\n", res->name);
-			if (i == RES_UFS)
-				return -ENODEV;
-			continue;
-		} else if (i == RES_UFS) {
-			res_mem = res->resource;
-			res->base = hba->mmio_base;
-			continue;
-		}
+	struct resource *res;
 
-		res->base = devm_ioremap_resource(hba->dev, res->resource);
-		if (IS_ERR(res->base)) {
-			dev_err(hba->dev, "Failed to map res %s, err=%d\n",
-					 res->name, (int)PTR_ERR(res->base));
-			ret = PTR_ERR(res->base);
-			res->base = NULL;
-			return ret;
-		}
+	/* Map the MCQ configuration region */
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mcq");
+	if (!res) {
+		dev_err(hba->dev, "MCQ resource not found in device tree\n");
+		return -ENODEV;
 	}
 
-	/* MCQ resource provided in DT */
-	res = &hba->res[RES_MCQ];
-	/* Bail if MCQ resource is provided */
-	if (res->base)
-		goto out;
-
-	/* Explicitly allocate MCQ resource from ufs_mem */
-	res_mcq = devm_kzalloc(hba->dev, sizeof(*res_mcq), GFP_KERNEL);
-	if (!res_mcq)
-		return -ENOMEM;
-
-	res_mcq->start = res_mem->start +
-			 MCQ_SQATTR_OFFSET(hba->mcq_capabilities);
-	res_mcq->end = res_mcq->start + hba->nr_hw_queues * MCQ_QCFG_SIZE - 1;
-	res_mcq->flags = res_mem->flags;
-	res_mcq->name = "mcq";
-
-	ret = insert_resource(&iomem_resource, res_mcq);
-	if (ret) {
-		dev_err(hba->dev, "Failed to insert MCQ resource, err=%d\n",
-			ret);
-		return ret;
+	hba->mcq_base = devm_ioremap_resource(hba->dev, res);
+	if (IS_ERR(hba->mcq_base)) {
+		dev_err(hba->dev, "Failed to map MCQ region: %ld\n",
+			PTR_ERR(hba->mcq_base));
+		return PTR_ERR(hba->mcq_base);
 	}
 
-	res->base = devm_ioremap_resource(hba->dev, res_mcq);
-	if (IS_ERR(res->base)) {
-		dev_err(hba->dev, "MCQ registers mapping failed, err=%d\n",
-			(int)PTR_ERR(res->base));
-		ret = PTR_ERR(res->base);
-		goto ioremap_err;
-	}
-
-out:
-	hba->mcq_base = res->base;
 	return 0;
-ioremap_err:
-	res->base = NULL;
-	remove_resource(res_mcq);
-	return ret;
 }
 
 static int ufs_qcom_op_runtime_config(struct ufs_hba *hba)
 {
-	struct ufshcd_res_info *mem_res, *sqdao_res;
 	struct ufshcd_mcq_opr_info_t *opr;
 	int i;
+	u32 doorbell_offsets[OPR_MAX];
 
-	mem_res = &hba->res[RES_UFS];
-	sqdao_res = &hba->res[RES_MCQ_SQD];
-
-	if (!mem_res->base || !sqdao_res->base)
+	if (!hba->mcq_base) {
+		dev_err(hba->dev, "MCQ base not mapped\n");
 		return -EINVAL;
+	}
+
+	/*
+	 * Configure doorbell address offsets in MCQ configuration registers.
+	 * These values are offsets relative to mmio_base (UFS_HCI_BASE).
+	 *
+	 * Memory Layout:
+	 * - mmio_base = UFS_HCI_BASE
+	 * - mcq_base  = MCQ_CONFIG_BASE = mmio_base + (UFS_QCOM_MCQCAP_QCFGPTR * 0x200)
+	 * - Doorbell registers are at: mmio_base + (UFS_QCOM_MCQCAP_QCFGPTR * 0x200) +
+	 * -				UFS_QCOM_MCQ_SQD_OFFSET
+	 * - Which is also: mcq_base +  UFS_QCOM_MCQ_SQD_OFFSET
+	 */
+
+	doorbell_offsets[OPR_SQD] = UFS_QCOM_SQD_ADDR_OFFSET;
+	doorbell_offsets[OPR_SQIS] = UFS_QCOM_SQIS_ADDR_OFFSET;
+	doorbell_offsets[OPR_CQD] = UFS_QCOM_CQD_ADDR_OFFSET;
+	doorbell_offsets[OPR_CQIS] = UFS_QCOM_CQIS_ADDR_OFFSET;
 
+	/*
+	 * Configure MCQ operation registers.
+	 *
+	 * The doorbell registers are physically located within the MCQ region:
+	 * - doorbell_physical_addr = mmio_base + doorbell_offset
+	 * - doorbell_physical_addr = mcq_base + (doorbell_offset - MCQ_CONFIG_OFFSET)
+	 */
 	for (i = 0; i < OPR_MAX; i++) {
 		opr = &hba->mcq_opr[i];
-		opr->offset = sqdao_res->resource->start -
-			      mem_res->resource->start + 0x40 * i;
-		opr->stride = 0x100;
-		opr->base = sqdao_res->base + 0x40 * i;
+		opr->offset = doorbell_offsets[i];  /* Offset relative to mmio_base */
+		opr->stride = UFS_QCOM_MCQ_STRIDE;  /* 256 bytes between queues */
+
+		/*
+		 * Calculate the actual doorbell base address within MCQ region:
+		 * base = mcq_base + (doorbell_offset - MCQ_CONFIG_OFFSET)
+		 */
+		opr->base = hba->mcq_base + (opr->offset - UFS_QCOM_MCQ_CONFIG_OFFSET);
 	}
 
 	return 0;
@@ -2034,12 +1991,13 @@ static int ufs_qcom_get_hba_mac(struct ufs_hba *hba)
 static int ufs_qcom_get_outstanding_cqs(struct ufs_hba *hba,
 					unsigned long *ocqs)
 {
-	struct ufshcd_res_info *mcq_vs_res = &hba->res[RES_MCQ_VS];
-
-	if (!mcq_vs_res->base)
+	if (!hba->mcq_base) {
+		dev_err(hba->dev, "MCQ base not mapped\n");
 		return -EINVAL;
+	}
 
-	*ocqs = readl(mcq_vs_res->base + UFS_MEM_CQIS_VS);
+	/* Read from MCQ vendor-specific register in MCQ region */
+	*ocqs = readl(hba->mcq_base + UFS_MEM_CQIS_VS);
 
 	return 0;
 }
diff --git a/drivers/ufs/host/ufs-qcom.h b/drivers/ufs/host/ufs-qcom.h
index e0e129af7c16..533e3297045f 100644
--- a/drivers/ufs/host/ufs-qcom.h
+++ b/drivers/ufs/host/ufs-qcom.h
@@ -33,6 +33,25 @@
 #define DL_VS_CLK_CFG_MASK GENMASK(9, 0)
 #define DME_VS_CORE_CLK_CTRL_DME_HW_CGC_EN             BIT(9)
 
+/* Qualcomm MCQ Configuration */
+#define UFS_QCOM_MCQCAP_QCFGPTR     224  /* 0xE0 in hex */
+#define UFS_QCOM_MCQ_CONFIG_OFFSET  (UFS_QCOM_MCQCAP_QCFGPTR * 0x200)  /* 0x1C000 */
+
+/* Doorbell offsets within MCQ region (relative to MCQ_CONFIG_BASE) */
+#define UFS_QCOM_MCQ_SQD_OFFSET     0x5000
+#define UFS_QCOM_MCQ_CQD_OFFSET     0x5080
+#define UFS_QCOM_MCQ_SQIS_OFFSET    0x5040
+#define UFS_QCOM_MCQ_CQIS_OFFSET    0x50C0
+#define UFS_QCOM_MCQ_STRIDE         0x100
+
+/* Calculated doorbell address offsets (relative to mmio_base) */
+#define UFS_QCOM_SQD_ADDR_OFFSET    (UFS_QCOM_MCQ_CONFIG_OFFSET + UFS_QCOM_MCQ_SQD_OFFSET)
+#define UFS_QCOM_CQD_ADDR_OFFSET    (UFS_QCOM_MCQ_CONFIG_OFFSET + UFS_QCOM_MCQ_CQD_OFFSET)
+#define UFS_QCOM_SQIS_ADDR_OFFSET   (UFS_QCOM_MCQ_CONFIG_OFFSET + UFS_QCOM_MCQ_SQIS_OFFSET)
+#define UFS_QCOM_CQIS_ADDR_OFFSET   (UFS_QCOM_MCQ_CONFIG_OFFSET + UFS_QCOM_MCQ_CQIS_OFFSET)
+
+#define REG_UFS_MCQ_STRIDE          UFS_QCOM_MCQ_STRIDE
+
 /* QCOM UFS host controller vendor specific registers */
 enum {
 	REG_UFS_SYS1CLK_1US                 = 0xC0,
@@ -96,7 +115,7 @@ enum {
 };
 
 enum {
-	UFS_MEM_CQIS_VS		= 0x8,
+	UFS_MEM_CQIS_VS		= 0x4008,
 };
 
 #define UFS_CNTLR_2_x_x_VEN_REGS_OFFSET(x)	(0x000 + x)
-- 
2.50.1

Re: [PATCH V2 1/4] dt-bindings: ufs: qcom: Document MCQ register space for UFS

[Krzysztof Kozlowski]

On 11/08/2025 16:31, Ram Kumar Dwivedi wrote:
> Document Multi-Circular Queue (MCQ) register space for
> Qualcomm UFS controllers.
> 
> Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
> ---
>  .../devicetree/bindings/ufs/qcom,ufs.yaml        | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
> index 6c6043d9809e..daf681b0e23b 100644
> --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
> +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
> @@ -89,9 +89,13 @@ properties:
>      maxItems: 2
>  
>    reg-names:
> -    items:
> -      - const: std
> -      - const: ice
> +    oneOf:
> +      - items:
> +          - const: std
> +          - const: ice
> +      - items:
> +          - const: ufs_mem
> +          - const: mcq

No. Why are you sending this? You have been Cc-ed here:

https://lore.kernel.org/all/20250731-dt-bindings-ufs-qcom-v2-3-53bb634bf95a@linaro.org/

Above is neither correct nor aligned with what I told you.

Best regards,
Krzysztof

Re: [PATCH V2 2/4] arm64: dts: qcom: sm8650: Enable MCQ support for UFS controller

[Krzysztof Kozlowski]

On 11/08/2025 16:31, Ram Kumar Dwivedi wrote:
> Enable Multi-Circular Queue (MCQ) support for the UFS host controller
> on the Qualcomm SM8650 platform by updating the device tree node. This
> includes adding new register region for MCQ and specifying the MSI parent
> required for MCQ operation.
> 
> Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/sm8650.dtsi | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

Way you organize your patchset is confusing. Why DTS is in the middle?
It suggests dependency and this would be strong objection from me.

Please read carefully writing bindings, submitting patches in DT and SoC
maintainer profile.

Best regards,
Krzysztof

Re: [PATCH V2 1/4] dt-bindings: ufs: qcom: Document MCQ register space for UFS

[Bjorn Andersson]

On Mon, Aug 11, 2025 at 08:01:36PM +0530, Ram Kumar Dwivedi wrote:
> Document Multi-Circular Queue (MCQ) register space for
> Qualcomm UFS controllers.
> 
> Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
> ---
>  .../devicetree/bindings/ufs/qcom,ufs.yaml        | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
> index 6c6043d9809e..daf681b0e23b 100644
> --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
> +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
> @@ -89,9 +89,13 @@ properties:
>      maxItems: 2
>  
>    reg-names:
> -    items:
> -      - const: std
> -      - const: ice
> +    oneOf:
> +      - items:
> +          - const: std
> +          - const: ice
> +      - items:
> +          - const: ufs_mem
> +          - const: mcq

So you can either "std" and "ice", or "ufs_mem" and "mcq".

Does this imply that "std" changes name to "ufs_mem"? Why?
Is MCQ incompatible with ICE?


Please use the commit message to document why this is.

Regards,
Bjorn

>  
>    required-opps:
>      maxItems: 1
> @@ -177,9 +181,9 @@ allOf:
>              - const: rx_lane1_sync_clk
>          reg:
>            minItems: 1
> -          maxItems: 1
> +          maxItems: 2
>          reg-names:
> -          maxItems: 1
> +          maxItems: 2
>  
>    - if:
>        properties:
> @@ -280,7 +284,7 @@ allOf:
>      then:
>        properties:
>          reg:
> -          maxItems: 1
> +          maxItems: 2
>          clocks:
>            minItems: 7
>            maxItems: 8
> -- 
> 2.50.1
> 

Re: [PATCH V2 1/4] dt-bindings: ufs: qcom: Document MCQ register space for UFS

[Ram Kumar Dwivedi]

On 11-Aug-25 8:12 PM, Krzysztof Kozlowski wrote:
> On 11/08/2025 16:31, Ram Kumar Dwivedi wrote:
>> Document Multi-Circular Queue (MCQ) register space for
>> Qualcomm UFS controllers.
>>
>> Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
>> ---
>>  .../devicetree/bindings/ufs/qcom,ufs.yaml        | 16 ++++++++++------
>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
>> index 6c6043d9809e..daf681b0e23b 100644
>> --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
>> +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
>> @@ -89,9 +89,13 @@ properties:
>>      maxItems: 2
>>  
>>    reg-names:
>> -    items:
>> -      - const: std
>> -      - const: ice
>> +    oneOf:
>> +      - items:
>> +          - const: std
>> +          - const: ice
>> +      - items:
>> +          - const: ufs_mem
>> +          - const: mcq
> 
> No. Why are you sending this? You have been Cc-ed here:
> 
> https://lore.kernel.org/all/20250731-dt-bindings-ufs-qcom-v2-3-53bb634bf95a@linaro.org/

Hi Krzysztof,

I understand I was Cc-ed on the patch thread you linked. However, if I send my patch on top of yours before it’s merged, the kernel bot might flag it due to missing base changes. Please let me know if you're okay with that — I can proceed with pushing my patch on top of yours.

Thanks,
Ram.


> 
> Above is neither correct nor aligned with what I told you.
> 
> Best regards,
> Krzysztof

Re: [PATCH V2 1/4] dt-bindings: ufs: qcom: Document MCQ register space for UFS

[Ram Kumar Dwivedi]

On 11-Aug-25 8:32 PM, Bjorn Andersson wrote:
> On Mon, Aug 11, 2025 at 08:01:36PM +0530, Ram Kumar Dwivedi wrote:
>> Document Multi-Circular Queue (MCQ) register space for
>> Qualcomm UFS controllers.
>>
>> Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
>> ---
>>  .../devicetree/bindings/ufs/qcom,ufs.yaml        | 16 ++++++++++------
>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
>> index 6c6043d9809e..daf681b0e23b 100644
>> --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
>> +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
>> @@ -89,9 +89,13 @@ properties:
>>      maxItems: 2
>>  
>>    reg-names:
>> -    items:
>> -      - const: std
>> -      - const: ice
>> +    oneOf:
>> +      - items:
>> +          - const: std
>> +          - const: ice
>> +      - items:
>> +          - const: ufs_mem
>> +          - const: mcq
> 
> So you can either "std" and "ice", or "ufs_mem" and "mcq".
> 
> Does this imply that "std" changes name to "ufs_mem"? Why?

Hi Bjorn,

The "std" is renamed to "ufs_mem" to more accurately represent the memory-mapped region associated with UFS controller.



> Is MCQ incompatible with ICE?


Yes, MCQ is compatible with ICE. 
Actually there are 3 possible cases:
- Case 1: Older Targets (e.g., SM8150)
  The UFS controller node includes both "std" and "ice" in the reg-name.

- Case 2: Recent Non-MCQ Targets(SM8550)  
  ICE is defined in a separate node, outside the UFS node, and the `reg-name` is not specified.

- Case 3: MCQ-Enabled Targets(SM8650,SM8750 - Part of Current Patch)  
  The reg-name includes both "ufs_mem" and "mcq" regions.

In summary, across all three scenarios, the configuration may include:
- "std" and "ice" together,
- "ufs_mem" and "mcq" together, or
- no reg-name defined at all.




> 
> 
> Please use the commit message to document why this is.

I will mention this in commit message of next patch set.


Thanks,
Ram.



> 
> Regards,
> Bjorn
> 
>>  
>>    required-opps:
>>      maxItems: 1
>> @@ -177,9 +181,9 @@ allOf:
>>              - const: rx_lane1_sync_clk
>>          reg:
>>            minItems: 1
>> -          maxItems: 1
>> +          maxItems: 2
>>          reg-names:
>> -          maxItems: 1
>> +          maxItems: 2
>>  
>>    - if:
>>        properties:
>> @@ -280,7 +284,7 @@ allOf:
>>      then:
>>        properties:
>>          reg:
>> -          maxItems: 1
>> +          maxItems: 2
>>          clocks:
>>            minItems: 7
>>            maxItems: 8
>> -- 
>> 2.50.1
>>

Re: [PATCH V2 2/4] arm64: dts: qcom: sm8650: Enable MCQ support for UFS controller

[Ram Kumar Dwivedi]

On 11-Aug-25 8:13 PM, Krzysztof Kozlowski wrote:
> On 11/08/2025 16:31, Ram Kumar Dwivedi wrote:
>> Enable Multi-Circular Queue (MCQ) support for the UFS host controller
>> on the Qualcomm SM8650 platform by updating the device tree node. This
>> includes adding new register region for MCQ and specifying the MSI parent
>> required for MCQ operation.
>>
>> Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
>> ---
>>  arch/arm64/boot/dts/qcom/sm8650.dtsi | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> Way you organize your patchset is confusing. Why DTS is in the middle?
> It suggests dependency and this would be strong objection from me.

Hi Krzysztof,

My current patch submission order is as follows:

1.DT binding
2.Device tree
3.Driver changes

Please let me know if you'd prefer to rearrange the order and place the driver patch in the middle.


Regards,
Ram
> 
> Please read carefully writing bindings, submitting patches in DT and SoC
> maintainer profile.
> 
> Best regards,
> Krzysztof

Re: [PATCH V2 1/4] dt-bindings: ufs: qcom: Document MCQ register space for UFS

[Krzysztof Kozlowski]

On 11/08/2025 18:12, Ram Kumar Dwivedi wrote:
>>> +      - items:
>>> +          - const: ufs_mem
>>> +          - const: mcq
>>
>> No. Why are you sending this? You have been Cc-ed here:
>>
>> https://lore.kernel.org/all/20250731-dt-bindings-ufs-qcom-v2-3-53bb634bf95a@linaro.org/
> 
> Hi Krzysztof,
> 
> I understand I was Cc-ed on the patch thread you linked. However, if I send my patch on top of yours before it’s merged, the kernel bot might flag it due to missing base changes. Please let me know if you're okay with that — I can proceed with pushing my patch on top of yours.

I don't understand it. We discuss this patch. What is with that
conditional "if I send"? You already sent it.

Please wrap your replies to match mailing list style.

Best regards,
Krzysztof

Re: [PATCH V2 1/4] dt-bindings: ufs: qcom: Document MCQ register space for UFS

[Krzysztof Kozlowski]

On 11/08/2025 17:02, Bjorn Andersson wrote:
> On Mon, Aug 11, 2025 at 08:01:36PM +0530, Ram Kumar Dwivedi wrote:
>> Document Multi-Circular Queue (MCQ) register space for
>> Qualcomm UFS controllers.
>>
>> Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
>> ---
>>  .../devicetree/bindings/ufs/qcom,ufs.yaml        | 16 ++++++++++------
>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
>> index 6c6043d9809e..daf681b0e23b 100644
>> --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
>> +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
>> @@ -89,9 +89,13 @@ properties:
>>      maxItems: 2
>>  
>>    reg-names:
>> -    items:
>> -      - const: std
>> -      - const: ice
>> +    oneOf:
>> +      - items:
>> +          - const: std
>> +          - const: ice
>> +      - items:
>> +          - const: ufs_mem
>> +          - const: mcq
> 
> So you can either "std" and "ice", or "ufs_mem" and "mcq".
> 
> Does this imply that "std" changes name to "ufs_mem"? Why?
> Is MCQ incompatible with ICE?
I commented on v1 what has to be fixed. I also said I will provide the
actual fix and then this is sent ignoring my comments and ignoring my fix.

So no, this does not get fixed.

NAK.

Best regards,
Krzysztof

Re: [PATCH V2 2/4] arm64: dts: qcom: sm8650: Enable MCQ support for UFS controller

[Krzysztof Kozlowski]

On 11/08/2025 18:54, Ram Kumar Dwivedi wrote:
> 
> 
> On 11-Aug-25 8:13 PM, Krzysztof Kozlowski wrote:
>> On 11/08/2025 16:31, Ram Kumar Dwivedi wrote:
>>> Enable Multi-Circular Queue (MCQ) support for the UFS host controller
>>> on the Qualcomm SM8650 platform by updating the device tree node. This
>>> includes adding new register region for MCQ and specifying the MSI parent
>>> required for MCQ operation.
>>>
>>> Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
>>> ---
>>>  arch/arm64/boot/dts/qcom/sm8650.dtsi | 7 ++++++-
>>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> Way you organize your patchset is confusing. Why DTS is in the middle?
>> It suggests dependency and this would be strong objection from me.
> 
> Hi Krzysztof,
> 
> My current patch submission order is as follows:
> 
> 1.DT binding
> 2.Device tree
> 3.Driver changes

Why are you repeating the obvious? That order is INCORRECT and that is
why I commented.

> 
> Please let me know if you'd prefer to rearrange the order and place the driver patch in the middle.

I need to you read the documents I mentioned. It is your task to read
the docs, not asking me to quote them again because you do not bother
with that.


Best regards,
Krzysztof

Re: [PATCH V2 2/4] arm64: dts: qcom: sm8650: Enable MCQ support for UFS controller

[Dmitry Baryshkov]

On Mon, Aug 11, 2025 at 10:24:29PM +0530, Ram Kumar Dwivedi wrote:
> 
> 
> On 11-Aug-25 8:13 PM, Krzysztof Kozlowski wrote:
> > On 11/08/2025 16:31, Ram Kumar Dwivedi wrote:
> >> Enable Multi-Circular Queue (MCQ) support for the UFS host controller
> >> on the Qualcomm SM8650 platform by updating the device tree node. This
> >> includes adding new register region for MCQ and specifying the MSI parent
> >> required for MCQ operation.
> >>
> >> Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
> >> ---
> >>  arch/arm64/boot/dts/qcom/sm8650.dtsi | 7 ++++++-
> >>  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > Way you organize your patchset is confusing. Why DTS is in the middle?
> > It suggests dependency and this would be strong objection from me.
> 
> Hi Krzysztof,
> 
> My current patch submission order is as follows:
> 
> 1.DT binding
> 2.Device tree
> 3.Driver changes
> 
> Please let me know if you'd prefer to rearrange the order and place the driver patch in the middle.

THe recommended way is opposite:

- DT bindings
- Driver changes
- DT changes

This lets maintainers to pick up their parts with less troubles.

> 
> 
> Regards,
> Ram
> > 
> > Please read carefully writing bindings, submitting patches in DT and SoC
> > maintainer profile.
> > 
> > Best regards,
> > Krzysztof
> 

-- 
With best wishes
Dmitry

Re: [PATCH V2 2/4] arm64: dts: qcom: sm8650: Enable MCQ support for UFS controller

[Ram Kumar Dwivedi]

On 12-Aug-25 4:25 PM, Dmitry Baryshkov wrote:
> On Mon, Aug 11, 2025 at 10:24:29PM +0530, Ram Kumar Dwivedi wrote:
>>
>>
>> On 11-Aug-25 8:13 PM, Krzysztof Kozlowski wrote:
>>> On 11/08/2025 16:31, Ram Kumar Dwivedi wrote:
>>>> Enable Multi-Circular Queue (MCQ) support for the UFS host controller
>>>> on the Qualcomm SM8650 platform by updating the device tree node. This
>>>> includes adding new register region for MCQ and specifying the MSI parent
>>>> required for MCQ operation.
>>>>
>>>> Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
>>>> ---
>>>>  arch/arm64/boot/dts/qcom/sm8650.dtsi | 7 ++++++-
>>>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> Way you organize your patchset is confusing. Why DTS is in the middle?
>>> It suggests dependency and this would be strong objection from me.
>>
>> Hi Krzysztof,
>>
>> My current patch submission order is as follows:
>>
>> 1.DT binding
>> 2.Device tree
>> 3.Driver changes
>>
>> Please let me know if you'd prefer to rearrange the order and place the driver patch in the middle.
> 
> THe recommended way is opposite:
> 
> - DT bindings
> - Driver changes
> - DT changes
> 
> This lets maintainers to pick up their parts with less troubles.

Hi Dmitry and Krzysztof,

Thanks for the suggestion. I'll update the next patchset order to
follow the recommended structure:
1. DT bindings
2. Driver changes
3. DT changes

Appreciate the guidance.

Thanks,
Ram.

> 
>>
>>
>> Regards,
>> Ram
>>>
>>> Please read carefully writing bindings, submitting patches in DT and SoC
>>> maintainer profile.
>>>
>>> Best regards,
>>> Krzysztof
>>
>