diff mbox series

[v3,02/10] dma-engine: sun4i: Add has_reset option to quirk

Message ID 20241027180903.2035820-2-csokas.bence@prolan.hu (mailing list archive)
State Changes Requested
Headers show
Series None | expand

Commit Message

Csókás Bence Oct. 27, 2024, 6:08 p.m. UTC
From: Mesih Kilinc <mesihkilinc@gmail.com>

Allwinner suniv F1C100s has a reset bit for DMA in CCU. Sun4i do not
has this bit but in order to support suniv we need to add it. So add
support for reset bit.

Signed-off-by: Mesih Kilinc <mesihkilinc@gmail.com>
[ csokas.bence: Rebased and addressed comments ]
Signed-off-by: Csókás, Bence <csokas.bence@prolan.hu>
---

Notes:
    Changes in v2:
    * Call reset_control_deassert() unconditionally, as it supports optional resets
    * Use dev_err_probe()
    * Whitespace
    Changes in v3:
    * More dev_err_probe()

 drivers/dma/sun4i-dma.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

Comments

Krzysztof Kozlowski Oct. 27, 2024, 8:43 p.m. UTC | #1
On Sun, Oct 27, 2024 at 07:08:55PM +0100, Csókás, Bence wrote:
> From: Mesih Kilinc <mesihkilinc@gmail.com>
> 
> Allwinner suniv F1C100s has a reset bit for DMA in CCU. Sun4i do not
> has this bit but in order to support suniv we need to add it. So add
> support for reset bit.
> 
> Signed-off-by: Mesih Kilinc <mesihkilinc@gmail.com>
> [ csokas.bence: Rebased and addressed comments ]
> Signed-off-by: Csókás, Bence <csokas.bence@prolan.hu>
> ---
> 
> Notes:
>     Changes in v2:
>     * Call reset_control_deassert() unconditionally, as it supports optional resets
>     * Use dev_err_probe()
>     * Whitespace
>     Changes in v3:
>     * More dev_err_probe()

You did not build v2. Then you send v3... which you also did not build.

Please start at least compiling your own code. Then start testing it,
but without building it cannot obviously be even tested.

Best regards,
Krzysztof
Csókás Bence Oct. 28, 2024, 7:31 a.m. UTC | #2
Hi,

On 2024. 10. 27. 21:43, Krzysztof Kozlowski wrote:
> You did not build v2. Then you send v3... which you also did not build.
> 
> Please start at least compiling your own code. Then start testing it,
> but without building it cannot obviously be even tested.

I forgot to rebase an amend! before sending v2, which I corrected in v3. 
I *did* in fact build v3 (after the aforementioned correction) rebased 
on top of Linux 6.5, which is what I have available for my board. And I 
also *did* test with aplay and confirmed to have working audio. If you 
believe there are differences between 6.5 and master that break v3 of 
the patch, then please point those out as opposed to making accusations.

Bence
Krzysztof Kozlowski Oct. 28, 2024, 8:11 a.m. UTC | #3
On 28/10/2024 08:31, Csókás Bence wrote:
> Hi,
> 
> On 2024. 10. 27. 21:43, Krzysztof Kozlowski wrote:
>> You did not build v2. Then you send v3... which you also did not build.
>>
>> Please start at least compiling your own code. Then start testing it,
>> but without building it cannot obviously be even tested.
> 
> I forgot to rebase an amend! before sending v2, which I corrected in v3. 
> I *did* in fact build v3 (after the aforementioned correction) rebased 
> on top of Linux 6.5, which is what I have available for my board. And I 

We cannot take patches based on v6.5. That's some close to ancient
kernel nowadays.

> also *did* test with aplay and confirmed to have working audio. If you 
> believe there are differences between 6.5 and master that break v3 of 

Yes, there are thousands of changes with possible impact.

All your patches must be prepared on latest mainline tree. All your SoC
code must be tested on *latest mainline tree*.

> the patch, then please point those out as opposed to making accusations.

First, your code does not build. Your code might not even apply. I do
not have to point patches causing it, because your job is to work on
mainline. But if you ask about patches causing issues, then I also do
not have to go through 50 000 commits which could have possible impact,
because you are supposed to work on mainline kernel.

Best regards,
Krzysztof
diff mbox series

Patch

diff --git a/drivers/dma/sun4i-dma.c b/drivers/dma/sun4i-dma.c
index d472f57a39ea..f485d6f378c0 100644
--- a/drivers/dma/sun4i-dma.c
+++ b/drivers/dma/sun4i-dma.c
@@ -15,6 +15,7 @@ 
 #include <linux/of_dma.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
+#include <linux/reset.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 
@@ -159,6 +160,7 @@  struct sun4i_dma_config {
 	u8 ddma_drq_sdram;
 
 	u8 max_burst;
+	bool has_reset;
 };
 
 struct sun4i_dma_pchan {
@@ -208,6 +210,7 @@  struct sun4i_dma_dev {
 	int				irq;
 	spinlock_t			lock;
 	const struct sun4i_dma_config *cfg;
+	struct reset_control *rst;
 };
 
 static struct sun4i_dma_dev *to_sun4i_dma_dev(struct dma_device *dev)
@@ -1215,6 +1218,16 @@  static int sun4i_dma_probe(struct platform_device *pdev)
 		return PTR_ERR(priv->clk);
 	}
 
+	if (priv->cfg->has_reset) {
+		priv->rst = devm_reset_control_get_exclusive(&pdev->dev,
+							     NULL);
+		if (IS_ERR(priv->rst)) {
+			dev_err_probe(&pdev->dev, PTR_ERR(priv->rst),
+						  "Failed to get reset control\n");
+			return PTR_ERR(priv->rst);
+		}
+	}
+
 	platform_set_drvdata(pdev, priv);
 	spin_lock_init(&priv->lock);
 
@@ -1287,6 +1300,14 @@  static int sun4i_dma_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	/* Deassert the reset control */
+	ret = reset_control_deassert(priv->rst);
+	if (ret) {
+		dev_err_probe(&pdev->dev, ret,
+			"Failed to deassert the reset control\n");
+		goto err_clk_disable;
+	}
+
 	/*
 	 * Make sure the IRQs are all disabled and accounted for. The bootloader
 	 * likes to leave these dirty
@@ -1356,6 +1377,7 @@  static struct sun4i_dma_config sun4i_a10_dma_cfg = {
 	.ddma_drq_sdram		= SUN4I_DDMA_DRQ_TYPE_SDRAM,
 
 	.max_burst		= SUN4I_MAX_BURST,
+	.has_reset		= false,
 };
 
 static const struct of_device_id sun4i_dma_match[] = {