On Wed, May 21, 2014 at 4:40 PM, Viresh Kumar wrote:
> OPP tables are already initialized for all CPUs by cpufreq core and so we
> don't
> need to reinitialize them from arm_big_little_dt driver.
>
I guess you wanted to say "cpu core code" instead of "cpufreq core".
Correction may be needed
On Wed, May 21, 2014 at 1:25 PM, Viresh Kumar wrote:
> On 21 May 2014 11:21, Inderpal Singh wrote:
>> At the driver unloading time the associated opps and its table may need
>> to be deleted. Otherwise it amounts to memory leak. The existing
>> OPP library does not ha
On Wed, May 21, 2014 at 1:25 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 21 May 2014 11:21, Inderpal Singh inderpa...@samsung.com wrote:
At the driver unloading time the associated opps and its table may need
to be deleted. Otherwise it amounts to memory leak. The existing
OPP library
On Wed, May 21, 2014 at 4:40 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
OPP tables are already initialized for all CPUs by cpufreq core and so we
don't
need to reinitialize them from arm_big_little_dt driver.
I guess you wanted to say cpu core code instead of cpufreq core.
Correction
At the driver unloading time the associated opps and its table may need
to be deleted. Otherwise it amounts to memory leak. The existing
OPP library does not have provision to do so.
Hence this patch implements the required functions to free the same.
Signed-off-by: Inderpal Singh
---
Changes
At the driver unloading time the associated opps and its table may need
to be deleted. Otherwise it amounts to memory leak. The existing
OPP library does not have provision to do so.
Hence this patch implements the required functions to free the same.
Signed-off-by: Inderpal Singh inderpa
On Tue, May 20, 2014 at 12:04 AM, Nishanth Menon wrote:
> On Mon, May 19, 2014 at 1:08 PM, Inderpal Singh
> wrote:
>> Hi Nishanth,
>>
>> Thanks for the review comments.
>>
>> On Mon, May 19, 2014 at 6:43 PM, Nishanth Menon wrote:
>>>
Hi Nishanth,
Thanks for the review comments.
On Mon, May 19, 2014 at 6:43 PM, Nishanth Menon wrote:
> On 05/16/2014 04:09 AM, Inderpal Singh wrote:
>> At the driver unloading time the associated opp table may need
>> to be deleted. Otherwise it amounts to memory leak. The
On Tue, May 20, 2014 at 12:04 AM, Nishanth Menon n...@ti.com wrote:
On Mon, May 19, 2014 at 1:08 PM, Inderpal Singh inderpa...@samsung.com
wrote:
Hi Nishanth,
Thanks for the review comments.
On Mon, May 19, 2014 at 6:43 PM, Nishanth Menon n...@ti.com wrote:
On 05/16/2014 04:09 AM
Hi Nishanth,
Thanks for the review comments.
On Mon, May 19, 2014 at 6:43 PM, Nishanth Menon n...@ti.com wrote:
On 05/16/2014 04:09 AM, Inderpal Singh wrote:
At the driver unloading time the associated opp table may need
to be deleted. Otherwise it amounts to memory leak. The existing
OPP
On Fri, May 16, 2014 at 10:41 PM, Viresh Kumar wrote:
> On 16 May 2014 22:38, Inderpal Singh wrote:
>>>> + while (!list_empty(_opp->opp_list)) {
>>>> + opp = list_entry_rcu(dev_opp->opp_list.next,
>>>> +
Hi Viresh,
Thanks for the review.
On Fri, May 16, 2014 at 3:36 PM, Viresh Kumar wrote:
> On 16 May 2014 14:39, Inderpal Singh wrote:
>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>> +void dev_pm_opp_free_opp_table(struct device *dev)
>> +{
>>
At the driver unloading time the associated opp table may need
to be deleted. Otherwise it amounts to memory leak. The existing
OPP library does not have provison to do so.
Hence this patch implements the function to free the opp table.
Signed-off-by: Inderpal Singh
---
drivers/base/power
At the driver unloading time the associated opp table may need
to be deleted. Otherwise it amounts to memory leak. The existing
OPP library does not have provison to do so.
Hence this patch implements the function to free the opp table.
Signed-off-by: Inderpal Singh inderpa...@samsung.com
Hi Viresh,
Thanks for the review.
On Fri, May 16, 2014 at 3:36 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 16 May 2014 14:39, Inderpal Singh inderpa...@samsung.com wrote:
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
+void dev_pm_opp_free_opp_table(struct device *dev
On Fri, May 16, 2014 at 10:41 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 16 May 2014 22:38, Inderpal Singh inderpa...@samsung.com wrote:
+ while (!list_empty(dev_opp-opp_list)) {
+ opp = list_entry_rcu(dev_opp-opp_list.next
On Thu, May 15, 2014 at 11:31 AM, Viresh Kumar wrote:
> On 15 May 2014 11:16, Inderpal Singh wrote:
>> I think I did not make myself clear.
>
> Probably I was the one who got confused :)
>
>> Devfreq will have its own opp table associated with its own device. It
>&g
On Thu, May 15, 2014 at 11:31 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 15 May 2014 11:16, Inderpal Singh inderpa...@samsung.com wrote:
I think I did not make myself clear.
Probably I was the one who got confused :)
Devfreq will have its own opp table associated with its own device
On Thu, May 15, 2014 at 11:07 AM, Viresh Kumar wrote:
> On 15 May 2014 11:00, Inderpal Singh wrote:
>> On Thu, May 15, 2014 at 10:34 AM, Viresh Kumar
>> wrote:
>>> On 15 May 2014 10:22, Inderpal Singh wrote:
>>>
>>>> What i am saying t
On Thu, May 15, 2014 at 10:34 AM, Viresh Kumar wrote:
> On 15 May 2014 10:22, Inderpal Singh wrote:
>
>> What i am saying that "what if we are not going to re-use again ? "
>
> That's what I said:
>
> Yes, it will keep occupying some space but there is only o
On Thu, May 15, 2014 at 10:06 AM, Viresh Kumar wrote:
> On 15 May 2014 10:02, Inderpal Singh wrote:
>> I feel freeing of opps are needed at least at the driver unregistration
>> time, like we free cpufreq_table.
>> Otherwise it amounts to memory leak unless we assume
On Thu, May 15, 2014 at 10:06 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 15 May 2014 10:02, Inderpal Singh inderpa...@samsung.com wrote:
I feel freeing of opps are needed at least at the driver unregistration
time, like we free cpufreq_table.
Otherwise it amounts to memory leak unless
On Thu, May 15, 2014 at 10:34 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 15 May 2014 10:22, Inderpal Singh inderpa...@samsung.com wrote:
What i am saying that what if we are not going to re-use again ?
That's what I said:
Yes, it will keep occupying some space but there is only one
On Thu, May 15, 2014 at 11:07 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 15 May 2014 11:00, Inderpal Singh inderpa...@samsung.com wrote:
On Thu, May 15, 2014 at 10:34 AM, Viresh Kumar viresh.ku...@linaro.org
wrote:
On 15 May 2014 10:22, Inderpal Singh inderpa...@samsung.com wrote
output regulators. The consumer of the
real regulators need not change anything. Only the name of the real
regulators need to be changed.
This patch has been tested on exynos5420 based smdk5420.
Signed-off-by: Doug Anderson
Signed-off-by: Inderpal Singh
---
.../bindings/regulator/locker
output regulators. The consumer of the
real regulators need not change anything. Only the name of the real
regulators need to be changed.
This patch has been tested on exynos5420 based smdk5420.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Inderpal Singh inderpa...@samsung.com
+CC:
dg77@samsung.com, myungjoo@samsung.com, kyungmin.p...@samsung.com
On 8 January 2013 16:20, Inderpal Singh wrote:
> Add freq_attr attribute to show list of available frequencies.
>
> Signed-off-by: Donggeun Kim
> Signed-off-by: MyungJoo Ham
> Signed-off-by: KyungMin
Add freq_attr attribute to show list of available frequencies.
Signed-off-by: Donggeun Kim
Signed-off-by: MyungJoo Ham
Signed-off-by: KyungMin Park
Signed-off-by: Inderpal Singh
---
drivers/cpufreq/exynos-cpufreq.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers
Add freq_attr attribute to show list of available frequencies.
Signed-off-by: Donggeun Kim dg77@samsung.com
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: KyungMin Park kyungmin.p...@samsung.com
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/cpufreq
+CC:
dg77@samsung.com, myungjoo@samsung.com, kyungmin.p...@samsung.com
On 8 January 2013 16:20, Inderpal Singh inderpal.si...@linaro.org wrote:
Add freq_attr attribute to show list of available frequencies.
Signed-off-by: Donggeun Kim dg77@samsung.com
Signed-off-by: MyungJoo Ham
lly_probe+0x68/0x1f4) from []
(driver_probe_device+0x30/0x48)
Signed-off-by: Inderpal Singh
---
drivers/regulator/s5m8767.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index 8ef5b33..9e6850f 100644
--- a/drivers/regulat
) from [c0297dd0]
(really_probe+0x68/0x1f4)
[c0297dd0] (really_probe+0x68/0x1f4) from [c0298070]
(driver_probe_device+0x30/0x48)
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/regulator/s5m8767.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi Vinod,
On 29 October 2012 10:15, Vinod Koul wrote:
> On Sat, 2012-10-27 at 15:50 +0530, Inderpal Singh wrote:
>> Hi Vinod,
>>
>> On 26 October 2012 10:15, Vinod Koul wrote:
>> > On Thu, 2012-10-25 at 16:53 +0530, Inderpal Singh wrote:
>> >>
>
Hi Vinod,
On 29 October 2012 10:15, Vinod Koul vk...@infradead.org wrote:
On Sat, 2012-10-27 at 15:50 +0530, Inderpal Singh wrote:
Hi Vinod,
On 26 October 2012 10:15, Vinod Koul vk...@infradead.org wrote:
On Thu, 2012-10-25 at 16:53 +0530, Inderpal Singh wrote:
This code will get
Hi Vinod,
On 26 October 2012 10:15, Vinod Koul wrote:
> On Thu, 2012-10-25 at 16:53 +0530, Inderpal Singh wrote:
>>
>> This code will get executed only in case of force removal of the
>> module which was discussed in the first version of the patch at [1].
>> Now, if we
Hi Vinod,
On 26 October 2012 10:15, Vinod Koul vk...@infradead.org wrote:
On Thu, 2012-10-25 at 16:53 +0530, Inderpal Singh wrote:
This code will get executed only in case of force removal of the
module which was discussed in the first version of the patch at [1].
Now, if we do not have
Hi Vinod,
On 24 October 2012 09:44, Vinod Koul wrote:
> On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
>> Since peripheral channel resources are not being allocated at probe,
>> no need to flush the channels and free the resources in remove function.
>> In case,
On 24 October 2012 09:49, Vinod Koul wrote:
> On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
>> unregister dma_device in module's remove function.
>>
>> Signed-off-by: Inderpal Singh
>> ---
>> drivers/dma/pl330.c |2 ++
>> 1 file changed, 2 i
On 24 October 2012 09:40, Vinod Koul wrote:
> On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
>> In probe, memory for multiple DMA descriptors were being allocated at once
>> and then it was being split and added into DMA pool one by one. The address
>> of t
Hi Vinod,
Thanks for reviewing.
On 24 October 2012 09:35, Vinod Koul wrote:
> On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
>> The allocated memory for peripheral channels is not being freed upon
>> failure in probe and in module's remove funtion. It will lead to me
Hi Vinod,
Thanks for reviewing.
On 24 October 2012 09:35, Vinod Koul vk...@infradead.org wrote:
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
The allocated memory for peripheral channels is not being freed upon
failure in probe and in module's remove funtion. It will lead to memory
On 24 October 2012 09:40, Vinod Koul vk...@infradead.org wrote:
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
In probe, memory for multiple DMA descriptors were being allocated at once
and then it was being split and added into DMA pool one by one. The address
of this memory
On 24 October 2012 09:49, Vinod Koul vk...@infradead.org wrote:
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
unregister dma_device in module's remove function.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/dma/pl330.c |2 ++
1 file changed, 2
Hi Vinod,
On 24 October 2012 09:44, Vinod Koul vk...@infradead.org wrote:
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
Since peripheral channel resources are not being allocated at probe,
no need to flush the channels and free the resources in remove function.
In case, the channel
reg_offset is offset of the status/mask registers. Now, since status_base
and mask_base are pointing to corresponding first registers, reg_offset
should start from 0 otheriwse regmap_add_irq_chip will fail during probe.
Signed-off-by: Inderpal Singh
---
It is based on Samuel's for-next-merge
reg_offset is offset of the status/mask registers. Now, since status_base
and mask_base are pointing to corresponding first registers, reg_offset
should start from 0 otheriwse regmap_add_irq_chip will fail during probe.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
It is based
and
free_chan_resources.
Signed-off-by: Inderpal Singh
---
This patch is based on slave-dma's next branch and on top
of the clean up patches at [1].
[1] https://lkml.org/lkml/2012/10/5/169
drivers/dma/pl330.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330
On 13 October 2012 16:33, Jassi Brar wrote:
> On Fri, Oct 5, 2012 at 3:47 PM, Inderpal Singh
> wrote:
>> The first 2 patches of this series fix memory leaks because the memory
>> allocated for peripheral channels and DMA descriptors were not getting
>> freed.
>>
On 13 October 2012 16:33, Jassi Brar jassisinghb...@gmail.com wrote:
On Fri, Oct 5, 2012 at 3:47 PM, Inderpal Singh
inderpal.si...@linaro.org wrote:
The first 2 patches of this series fix memory leaks because the memory
allocated for peripheral channels and DMA descriptors were not getting
and
free_chan_resources.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
This patch is based on slave-dma's next branch and on top
of the clean up patches at [1].
[1] https://lkml.org/lkml/2012/10/5/169
drivers/dma/pl330.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/dma
Hello,
On 5 October 2012 06:17, Inderpal Singh wrote:
> The first 2 patches of this series fix memory leaks because the memory
> allocated for peripheral channels and DMA descriptors were not getting
> freed.
>
> The last 2 patches balance the module's remove function.
>
>
Hello,
On 5 October 2012 06:17, Inderpal Singh inderpal.si...@linaro.org wrote:
The first 2 patches of this series fix memory leaks because the memory
allocated for peripheral channels and DMA descriptors were not getting
freed.
The last 2 patches balance the module's remove function
descs can also be freed.
2. Free DMA descs in case of error in probe and in module's remove function
Signed-off-by: Inderpal Singh
---
drivers/dma/pl330.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma
unregister dma_device in module's remove function.
Signed-off-by: Inderpal Singh
---
drivers/dma/pl330.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 4b7a34d..e7dc040 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
Since peripheral channel resources are not being allocated at probe,
no need to flush the channels and free the resources in remove function.
In case, the channel is in use by some client, return EBUSY.
Signed-off-by: Inderpal Singh
---
drivers/dma/pl330.c | 13 -
1 file changed
The allocated memory for peripheral channels is not being freed upon
failure in probe and in module's remove funtion. It will lead to memory
leakage. Hence free the allocated memory.
Signed-off-by: Inderpal Singh
---
drivers/dma/pl330.c |5 -
1 file changed, 4 insertions(+), 1 deletion
list_add_tail with spin_locks
- Return EBUSY from remove if channel is in use
- unregister dma_device in remove
Inderpal Singh (4):
DMA: PL330: Free memory allocated for peripheral channels
DMA: PL330: Change allocation method to properly free DMA
descriptors
DMA: PL330: Balance module
from remove if channel is in use
- unregister dma_device in remove
Inderpal Singh (4):
DMA: PL330: Free memory allocated for peripheral channels
DMA: PL330: Change allocation method to properly free DMA
descriptors
DMA: PL330: Balance module remove function with probe
DMA: PL330
The allocated memory for peripheral channels is not being freed upon
failure in probe and in module's remove funtion. It will lead to memory
leakage. Hence free the allocated memory.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/dma/pl330.c |5 -
1 file changed, 4
Since peripheral channel resources are not being allocated at probe,
no need to flush the channels and free the resources in remove function.
In case, the channel is in use by some client, return EBUSY.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/dma/pl330.c | 13
unregister dma_device in module's remove function.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/dma/pl330.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 4b7a34d..e7dc040 100644
--- a/drivers/dma/pl330.c
+++ b
descs can also be freed.
2. Free DMA descs in case of error in probe and in module's remove function
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/dma/pl330.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers
On 28 September 2012 16:28, Jassi Brar wrote:
> On Fri, Sep 28, 2012 at 10:03 AM, Inderpal Singh
> wrote:
>>
>> Now, if we have to check if any client is using the channel and then
>> decide. We will have to traverse the channel list twice once to check
>> the u
On 28 September 2012 16:28, Jassi Brar jassisinghb...@gmail.com wrote:
On Fri, Sep 28, 2012 at 10:03 AM, Inderpal Singh
inderpal.si...@linaro.org wrote:
Now, if we have to check if any client is using the channel and then
decide. We will have to traverse the channel list twice once to check
On 27 September 2012 21:36, Jassi Brar wrote:
> On Thu, Sep 27, 2012 at 9:11 PM, Inderpal Singh
> wrote:
>> On 27 September 2012 15:18, Vinod Koul wrote:
>>> On Wed, 2012-09-26 at 12:11 +0530, Inderpal Singh wrote:
>>>> If we fail pl330_remove while some c
On 27 September 2012 15:18, Vinod Koul wrote:
> On Wed, 2012-09-26 at 12:11 +0530, Inderpal Singh wrote:
>> If we fail pl330_remove while some client is queued, the force unload
>> will fail and the
>> force unload will lose its purpose.
>> How about conditionally
On 27 September 2012 15:18, Vinod Koul vinod.k...@linux.intel.com wrote:
On Wed, 2012-09-26 at 12:11 +0530, Inderpal Singh wrote:
If we fail pl330_remove while some client is queued, the force unload
will fail and the
force unload will lose its purpose.
How about conditionally
On 27 September 2012 21:36, Jassi Brar jassisinghb...@gmail.com wrote:
On Thu, Sep 27, 2012 at 9:11 PM, Inderpal Singh
inderpal.si...@linaro.org wrote:
On 27 September 2012 15:18, Vinod Koul vinod.k...@linux.intel.com wrote:
On Wed, 2012-09-26 at 12:11 +0530, Inderpal Singh wrote:
If we fail
On 27 September 2012 10:35, Jassi Brar wrote:
> On Thu, Sep 27, 2012 at 9:43 AM, Inderpal Singh
> wrote:
>>
>> Don't you think free_chan_resource should be done __only if__
>> alloc_chan_resource was successful ?
>>
> No, I don't think so. Thanks.
Thanks for
On 26 September 2012 22:19, Jassi Brar wrote:
> On Wed, Sep 26, 2012 at 4:25 PM, Inderpal Singh
> wrote:
>> On 26 September 2012 15:02, Jassi Brar wrote:
>>> On Wed, Sep 26, 2012 at 12:11 PM, Inderpal Singh
>>> wrote:
>>>
>>>> How about cond
On 26 September 2012 15:02, Jassi Brar wrote:
> On Wed, Sep 26, 2012 at 12:11 PM, Inderpal Singh
> wrote:
>
>> How about conditionally DMA_TERMINATE_ALL and free resources like below ?
>>
>> @@ -3017,9 +3017,11 @@ static int __devexit pl330_remove(
On 25 September 2012 18:47, Jassi Brar wrote:
> On Tue, Sep 25, 2012 at 2:27 PM, Inderpal Singh
> wrote:
>> Since peripheral channel resources are not being allocated at probe,
>> no need to flush the channels and free the resources in remove function.
>>
>>
On 25 September 2012 18:47, Jassi Brar jassisinghb...@gmail.com wrote:
On Tue, Sep 25, 2012 at 2:27 PM, Inderpal Singh
inderpal.si...@linaro.org wrote:
Since peripheral channel resources are not being allocated at probe,
no need to flush the channels and free the resources in remove function
On 26 September 2012 15:02, Jassi Brar jassisinghb...@gmail.com wrote:
On Wed, Sep 26, 2012 at 12:11 PM, Inderpal Singh
inderpal.si...@linaro.org wrote:
How about conditionally DMA_TERMINATE_ALL and free resources like below ?
@@ -3017,9 +3017,11 @@ static int __devexit pl330_remove(struct
On 26 September 2012 22:19, Jassi Brar jassisinghb...@gmail.com wrote:
On Wed, Sep 26, 2012 at 4:25 PM, Inderpal Singh
inderpal.si...@linaro.org wrote:
On 26 September 2012 15:02, Jassi Brar jassisinghb...@gmail.com wrote:
On Wed, Sep 26, 2012 at 12:11 PM, Inderpal Singh
inderpal.si
On 27 September 2012 10:35, Jassi Brar jassisinghb...@gmail.com wrote:
On Thu, Sep 27, 2012 at 9:43 AM, Inderpal Singh
inderpal.si...@linaro.org wrote:
Don't you think free_chan_resource should be done __only if__
alloc_chan_resource was successful ?
No, I don't think so. Thanks.
Thanks
On 25 September 2012 18:39, Jassi Brar wrote:
> On Tue, Sep 25, 2012 at 2:27 PM, Inderpal Singh
> wrote:
>> In probe, memory for multiple DMA descriptors were being allocated at once
>> and then it was being split and added into DMA pool one by one. The address
>> o
On 25 September 2012 18:17, Jassi Brar wrote:
> On Tue, Sep 25, 2012 at 2:27 PM, Inderpal Singh
> wrote:
>> The allocated memory for peripheral channels is not being freed upon
>> failure in probe and in module's remove funtion. It will lead to memory
>> leakage. Hence f
Since peripheral channel resources are not being allocated at probe,
no need to flush the channels and free the resources in remove function.
Signed-off-by: Inderpal Singh
---
drivers/dma/pl330.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/dma/pl330.c b
t;fixes" branch and applied patch at [1] to fix the build error.
[1] http://permalink.gmane.org/gmane.linux.kernel.next/24274
Inderpal Singh (3):
DMA: PL330: Free memory allocated for peripheral channels
DMA: PL330: Change allocation method to properly free DMA descriptors
DMA: PL330: Balance mo
descs can also be freed.
2. Free DMA descs in case of error in probe and in module's remove function
Signed-off-by: Inderpal Singh
---
drivers/dma/pl330.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
The allocated memory for peripheral channels is not being freed upon
failure in probe and in module's remove funtion. It will lead to memory
leakage. Hence free the allocated memory.
Signed-off-by: Inderpal Singh
---
drivers/dma/pl330.c |5 -
1 file changed, 4 insertions(+), 1 deletion
The allocated memory for peripheral channels is not being freed upon
failure in probe and in module's remove funtion. It will lead to memory
leakage. Hence free the allocated memory.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/dma/pl330.c |5 -
1 file changed, 4
descs can also be freed.
2. Free DMA descs in case of error in probe and in module's remove function
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/dma/pl330.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/pl330
patch at [1] to fix the build error.
[1] http://permalink.gmane.org/gmane.linux.kernel.next/24274
Inderpal Singh (3):
DMA: PL330: Free memory allocated for peripheral channels
DMA: PL330: Change allocation method to properly free DMA descriptors
DMA: PL330: Balance module remove function
Since peripheral channel resources are not being allocated at probe,
no need to flush the channels and free the resources in remove function.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/dma/pl330.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff
On 25 September 2012 18:17, Jassi Brar jassisinghb...@gmail.com wrote:
On Tue, Sep 25, 2012 at 2:27 PM, Inderpal Singh
inderpal.si...@linaro.org wrote:
The allocated memory for peripheral channels is not being freed upon
failure in probe and in module's remove funtion. It will lead to memory
On 25 September 2012 18:39, Jassi Brar jassisinghb...@gmail.com wrote:
On Tue, Sep 25, 2012 at 2:27 PM, Inderpal Singh
inderpal.si...@linaro.org wrote:
In probe, memory for multiple DMA descriptors were being allocated at once
and then it was being split and added into DMA pool one by one
Since 0 is not considered as error at dmaengine level, return ENOMEM
from pl330_alloc_chan_resources in case of failure.
Signed-off-by: Inderpal Singh
---
drivers/dma/pl330.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index
Since 0 is not considered as error at dmaengine level, return ENOMEM
from pl330_alloc_chan_resources in case of failure.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/dma/pl330.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/pl330.c b
The driver's runtime_suspend/resume functions just disable/enable
the clock which is already being managed at AMBA bus level
runtime_suspend/resume functions.
Hence, remove the driver's runtime_suspend/resume functions.
Signed-off-by: Inderpal Singh
---
drivers/dma/pl330.c | 61
The controller clock is being enabled/disabled in AMBA bus
infrastructre in probe/remove functions. Hence, its not required
at driver level probe/remove.
Signed-off-by: Inderpal Singh
---
drivers/dma/pl330.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/dma/pl330.c
the redundant clock enable/disable from the driver.
Inderpal Singh (2):
DMA: PL330: Remove controller clock enable/disable
DMA: PL330: Remove redundant runtime_suspend/resume functions
drivers/dma/pl330.c | 73 ---
1 file changed, 5 insertions
the redundant clock enable/disable from the driver.
Inderpal Singh (2):
DMA: PL330: Remove controller clock enable/disable
DMA: PL330: Remove redundant runtime_suspend/resume functions
drivers/dma/pl330.c | 73 ---
1 file changed, 5 insertions
The controller clock is being enabled/disabled in AMBA bus
infrastructre in probe/remove functions. Hence, its not required
at driver level probe/remove.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/dma/pl330.c | 12
1 file changed, 12 deletions(-)
diff
The driver's runtime_suspend/resume functions just disable/enable
the clock which is already being managed at AMBA bus level
runtime_suspend/resume functions.
Hence, remove the driver's runtime_suspend/resume functions.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/dma
96 matches
Mail list logo
