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
>> amba_device *adev)
>> /* Remove the channel */
>> list_del(&pch->chan.device_node);
>>
>> - /* Flush the channel */
>> - pl330_control(&pch->chan, DMA_TERMINATE_ALL, 0);
>> - pl330_free_chan_resources(&pch->chan);
>> + if (pch->chan.client_count != 0) {
>> + /* Flush the channel */
>> + pl330_control(&pch->chan, DMA_TERMINATE_ALL, 0);
>> + pl330_free_chan_resources(&pch->chan);
>> + }
>> }
>>
> It is perfectly safe to flush the channels that have client_count == 0
> as well. Which is already the case.
As per my understanding, if client_count ==0, It may mean following:
1. This channel was never allocated to any client. Hence
alloc_chan_resources was not done for it.
So, no need to flush and free resources if it was never allocated at
the first place. If we free_chan_resources, it will not be balanced
against alloc_chan_resources. Scenario: insmod and then rmmod.
Or,
2. The channel was allocated to some client, alloc_chan_resource was
done, the work for the client is completed and free_chan_resources was
performed. Now since resources have already been freed, no need to
flush and free_chan_resources again in remove.
The whole idea of this patch is to balance alloc_chan_resources and
free_chan_resources.
Thanks,
Inder
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
