[PATCH 1/2] dmaengine: qcom_hidma: correct overriding message

[PATCH 1/2] dmaengine: qcom_hidma: correct overriding message

[Sinan Kaya]

A false overriding information is being presented during boot
under this scenario.

1. First object checks for kernel command line value against zero.
2. It doesn't find it, it sets the command line variable to the
value coming from ACPI/DT.
3. Second object is being probed.
4. Second object sees that the value of kernel command line
override is non-zero, it prints an overriding message even though
value matches ACPI/DT value.

hidma-mgmt QCOM8060:03: overriding max-write-burst-bytes: 1024

Add an additional check to verify that kernel command line value
is different from the ACPI/DT value.

Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/dma/qcom/hidma_mgmt.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index 5a0991b..d51cd34 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -227,7 +227,8 @@ static int hidma_mgmt_probe(struct platform_device *pdev)
 		goto out;
 	}
 
-	if (max_write_request) {
+	if (max_write_request &&
+			(max_write_request != mgmtdev->max_write_request)) {
 		dev_info(&pdev->dev, "overriding max-write-burst-bytes: %d\n",
 			max_write_request);
 		mgmtdev->max_write_request = max_write_request;
@@ -240,7 +241,8 @@ static int hidma_mgmt_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev, "max-read-burst-bytes missing\n");
 		goto out;
 	}
-	if (max_read_request) {
+	if (max_read_request &&
+			(max_read_request != mgmtdev->max_read_request)) {
 		dev_info(&pdev->dev, "overriding max-read-burst-bytes: %d\n",
 			max_read_request);
 		mgmtdev->max_read_request = max_read_request;
@@ -253,7 +255,8 @@ static int hidma_mgmt_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev, "max-write-transactions missing\n");
 		goto out;
 	}
-	if (max_wr_xactions) {
+	if (max_wr_xactions &&
+			(max_wr_xactions != mgmtdev->max_wr_xactions)) {
 		dev_info(&pdev->dev, "overriding max-write-transactions: %d\n",
 			max_wr_xactions);
 		mgmtdev->max_wr_xactions = max_wr_xactions;
@@ -266,7 +269,8 @@ static int hidma_mgmt_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev, "max-read-transactions missing\n");
 		goto out;
 	}
-	if (max_rd_xactions) {
+	if (max_rd_xactions &&
+			(max_rd_xactions != mgmtdev->max_rd_xactions)) {
 		dev_info(&pdev->dev, "overriding max-read-transactions: %d\n",
 			max_rd_xactions);
 		mgmtdev->max_rd_xactions = max_rd_xactions;
-- 
1.9.1

[PATCH 2/2] dmaengine: qcom_hidma: correct channel QOS register offset

[Sinan Kaya]

A regression was found while testing QOS with different channels.
The QOS register offset is 0x700 rather than 0x300.

Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/dma/qcom/hidma_mgmt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index d51cd34..c45e244 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -28,7 +28,7 @@
 
 #include "hidma_mgmt.h"
 
-#define HIDMA_QOS_N_OFFSET		0x300
+#define HIDMA_QOS_N_OFFSET		0x700
 #define HIDMA_CFG_OFFSET		0x400
 #define HIDMA_MAX_BUS_REQ_LEN_OFFSET	0x41C
 #define HIDMA_MAX_XACTIONS_OFFSET	0x420
-- 
1.9.1

[PATCH 1/2] dmaengine: qcom_hidma: correct overriding message

[Vinod Koul]

On Sun, Jul 16, 2017 at 10:30:37AM -0400, Sinan Kaya wrote:
> A false overriding information is being presented during boot
> under this scenario.
> 
> 1. First object checks for kernel command line value against zero.
> 2. It doesn't find it, it sets the command line variable to the
> value coming from ACPI/DT.
> 3. Second object is being probed.
> 4. Second object sees that the value of kernel command line
> override is non-zero, it prints an overriding message even though
> value matches ACPI/DT value.
> 
> hidma-mgmt QCOM8060:03: overriding max-write-burst-bytes: 1024
> 
> Add an additional check to verify that kernel command line value
> is different from the ACPI/DT value.

Applied both, thanks

-- 
~Vinod