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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
