Re: [PATCH v2 09/11] OMAP: DMA: Implement generic errata handling

["Cousson, Benoit" <b-cousson@ti.com>]

On 9/17/2010 10:09 AM, G, Manjunath Kondaiah wrote:
> Hi Benoit,
>

<...>

>>>
>>> I assume you are ok with option #1. Let me know if you have any
>>> issues/concenrs with above approach. I am in the process of
>> consolidating
>>> all the review comments and addressing all applicable
>> review comments.
>>
>> Not really, the option #1 will still require you to use the
>> oh pointer,
>> which is supposed to be private to the omap_device.
>>
>> What is still not clear is why and when you need to change
>> the sysconfig
>> setting.
>
> It is required before stopping DMA chain transfer.

OK, but why? What happen if you do not do that? Could you please give 
the full errata description to help us understanding?

>> Do you have a details explanation? Ideally you should try to
>> couple the
>> sysconfig change along with pm_runtime / hwmod state change, then we
>> will be able to handle that smoothly in the framework.
>
> Since channel is already requested(and there is possibility of other channels
> also used at the same time), using pm_runtime API's will only increase
> usage count and will not invoke omap_device_enable.

This is the part that is not clear, and where the full errata should 
help, because if you do have other channel in use, you will not be able 
to do any clock gating anyway, that why changing the sysconfig at that 
time might be useless.

>> If you cannot do that, you will need to add an omap_device
>> API as well.
>
> There is already one such API exists in hwmod layer for handling this type
> of errata(omap_hwmod_set_slave_idlemode in omap_hwmod.c).
> Above proposal is based on similar implementation.

Maybe, but this is not enough. In both case you should not use directly 
this API from the driver, so if you want to use that kind of approach, 
you will need the omap_device layer as well.


Regards,
Benoit