On Thu, 2012-09-06 at 19:05 +0530, Archit Taneja wrote:
On Thursday 06 September 2012 06:34 PM, Tomi Valkeinen wrote:
quoted
On Wed, 2012-09-05 at 19:01 +0530, Archit Taneja wrote:
quoted
On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote:
quoted
Now that fifo merge has been removed, nobody uses the extra_info related
completion code, which can be removed.
I think this might come into use when we fix the usage of channel out
field. That is, since channel out is an immediate write field, when we
set a new manager for an overlay, we may need to wait till the overlay
disable kicks in, only then we should change channel out.
For this, we would need some wait for extra_info, right?
Hmm, yes, I think you are right. Previously the ovl_disable waited until
the overlay is not used anymore, but now it doesn't.
So I think I need to add wait_pending_extra_info_updates() call to the
beginning of dss_ovl_set_manager(). Or, should it be in unset_manager...
I think unset is better, then a "free" overlay always disabled also in
the HW level.
Yes, I also think it should be in unset_manager. One option could be to
leave the wait_pending_extra_info_updates() in ovl_disable itself, as it
was before. But that would force us to use mutexes there, and we'd
rather have overlay enabling and disabling as a non blocking thing.
Actually, we do have mutexes there. You are thinking about the prototype
API I have. (I also thought we didn't have mutex there =).
So, in fact, we can have the wait at ovl_disable like it was before. The
prototype API, which cannot block, will not have the wait, but there the
caller (i.e. omapdrm) will have to manage the proper wait.
Tomi