On Wed, Sep 26, 2012 at 4:25 PM, Inderpal Singh
<inderpal.singh@xxxxxxxxxx> wrote:
> On 26 September 2012 15:02, Jassi Brar <jassisinghbrar@xxxxxxxxx> wrote:
>> On Wed, Sep 26, 2012 at 12:11 PM, Inderpal Singh
>> <inderpal.singh@xxxxxxxxxx> 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.
>
Do you see any issue with channels that have zero client_count ?
AFAIU there are already enough checks in the path to weed out unused
channels, so let us please not uglify the code by adding new
unnecessary checks.
thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
