[PATCH] dma: tegra: enable/disable dma clock

[PATCH] dma: tegra: enable/disable dma clock

[Laxman Dewangan]

Enable the DMA clock when registering DMA driver and
disable clock when removing the DMA driver.

The failure was observed on Tegra20 based system by
Stephen Warren. However, it is working fine on tegra30
based system and probably becasue uboot enable the clock
on Tegra30.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reported-by: Stephen Warren <swarren@wwwdotorg.org>
---
 drivers/dma/tegra20-apb-dma.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index d52dbc6..ccfdaf4 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -1255,6 +1255,12 @@ static int __devinit tegra_dma_probe(struct platform_device *pdev)
 		}
 	}
 
+	ret = clk_prepare_enable(tdma->dma_clk);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "clk_prepare_enable failed: %d\n", ret);
+		goto err_pm_disable;
+	}
+
 	/* Reset DMA controller */
 	tegra_periph_reset_assert(tdma->dma_clk);
 	udelay(2);
@@ -1363,6 +1369,7 @@ static int __devexit tegra_dma_remove(struct platform_device *pdev)
 	if (!pm_runtime_status_suspended(&pdev->dev))
 		tegra_dma_runtime_suspend(&pdev->dev);
 
+	clk_disable_unprepare(tdma->dma_clk);
 	return 0;
 }
 
-- 
1.7.1.1

Re: [PATCH] dma: tegra: enable/disable dma clock

[Vinod Koul]

On Wed, 2012-07-18 at 14:26 +0530, Laxman Dewangan wrote:
> Enable the DMA clock when registering DMA driver and
> disable clock when removing the DMA driver.
> 
> The failure was observed on Tegra20 based system by
> Stephen Warren. However, it is working fine on tegra30
> based system and probably becasue uboot enable the clock
> on Tegra30.
Don't know much about the clock subsystem, but shouldn't the clocks be
enabled runtime..... when you actually start using the controller??
> 
> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
> Reported-by: Stephen Warren <swarren@wwwdotorg.org>
> ---
>  drivers/dma/tegra20-apb-dma.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> index d52dbc6..ccfdaf4 100644
> --- a/drivers/dma/tegra20-apb-dma.c
> +++ b/drivers/dma/tegra20-apb-dma.c
> @@ -1255,6 +1255,12 @@ static int __devinit tegra_dma_probe(struct platform_device *pdev)
>  		}
>  	}
>  
> +	ret = clk_prepare_enable(tdma->dma_clk);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "clk_prepare_enable failed: %d\n", ret);
> +		goto err_pm_disable;
> +	}
> +
>  	/* Reset DMA controller */
>  	tegra_periph_reset_assert(tdma->dma_clk);
>  	udelay(2);
> @@ -1363,6 +1369,7 @@ static int __devexit tegra_dma_remove(struct platform_device *pdev)
>  	if (!pm_runtime_status_suspended(&pdev->dev))
>  		tegra_dma_runtime_suspend(&pdev->dev);
>  
> +	clk_disable_unprepare(tdma->dma_clk);
>  	return 0;
>  }
>  


-- 
~Vinod

Re: [PATCH] dma: tegra: enable/disable dma clock

[Laxman Dewangan]

On Friday 20 July 2012 11:32 AM, Vinod Koul wrote:
> On Wed, 2012-07-18 at 14:26 +0530, Laxman Dewangan wrote:
>> Enable the DMA clock when registering DMA driver and
>> disable clock when removing the DMA driver.
>>
>> The failure was observed on Tegra20 based system by
>> Stephen Warren. However, it is working fine on tegra30
>> based system and probably becasue uboot enable the clock
>> on Tegra30.
> Don't know much about the clock subsystem, but shouldn't the clocks be
> enabled runtime..... when you actually start using the controller??

Yes, this is the plan and I am going to implement dynamic clock 
management but it will take some time to complete and have testing 
throughly. some of the issue which I am seeing and analyzing on this 
approach is that
  - clock disable can be called from isr context or not?
  - how much complexity will be added in dma driver to implement this?
  - What power benefit we will get on this.
  - Is there any user which generally use dma and always keep dma on 
requested state like UART RX always ready etc.

So keeping that in mind, it will take some time to complete this and 
meanwhile, I want to make it work for Tegra20 based system which is not 
working on current driver.
and hence this is the change.

Thanks,
Laxman

Re: [PATCH] dma: tegra: enable/disable dma clock

[Vinod Koul]

On Fri, 2012-07-20 at 11:34 +0530, Laxman Dewangan wrote:
> On Friday 20 July 2012 11:32 AM, Vinod Koul wrote:
> > On Wed, 2012-07-18 at 14:26 +0530, Laxman Dewangan wrote:
> >> Enable the DMA clock when registering DMA driver and
> >> disable clock when removing the DMA driver.
> >>
> >> The failure was observed on Tegra20 based system by
> >> Stephen Warren. However, it is working fine on tegra30
> >> based system and probably becasue uboot enable the clock
> >> on Tegra30.
> > Don't know much about the clock subsystem, but shouldn't the clocks be
> > enabled runtime..... when you actually start using the controller??
> 
> Yes, this is the plan and I am going to implement dynamic clock 
> management but it will take some time to complete and have testing 
> throughly. some of the issue which I am seeing and analyzing on this 
> approach is that
>   - clock disable can be called from isr context or not?
>   - how much complexity will be added in dma driver to implement this?
>   - What power benefit we will get on this.
>   - Is there any user which generally use dma and always keep dma on 
> requested state like UART RX always ready etc.
> 
> So keeping that in mind, it will take some time to complete this and 
> meanwhile, I want to make it work for Tegra20 based system which is not 
> working on current driver.
> and hence this is the change.
for a start you can move these to .alloc_chan_resources
and .free_chan_resources while doing a  refcount.
Further optimization can be done by moving this to tx_submit and
tasklet.

-- 
~Vinod

Re: [PATCH] dma: tegra: enable/disable dma clock

[Laxman Dewangan]

On Friday 20 July 2012 12:10 PM, Vinod Koul wrote:
> On Fri, 2012-07-20 at 11:34 +0530, Laxman Dewangan wrote:
>> On Friday 20 July 2012 11:32 AM, Vinod Koul wrote:
>>
> for a start you can move these to .alloc_chan_resources
> and .free_chan_resources while doing a  refcount.
> Further optimization can be done by moving this to tx_submit and
> tasklet.
>
Agree. I will send the new patch.