Bug 90418

That's the expected behaviour for fbdev since it does not wrap access to the framebuffer. Are you saying that you observe this after the display server is active?

Chris,

>> That's the expected behaviour for fbdev since it does not wrap access to the framebuffer. 
Not getting the invalidate calls is expected?

>> Are you saying that you observe this after the display server is active?
Yes. Even when ubuntu Desktop is up, this behavior(absence of invalidate) is observed.

(In reply to Ramalingam C from comment #2)
> Chris,
> 
> >> That's the expected behaviour for fbdev since it does not wrap access to the framebuffer. 
> Not getting the invalidate calls is expected?

For fbdev, yes.

> >> Are you saying that you observe this after the display server is active?
> Yes. Even when ubuntu Desktop is up, this behavior(absence of invalidate) is
> observed.

Since invalidate is only called at the start of a write transaction, yes. The desktop should only be flipping (not even drawing into the scanout) which only triggers flush on the change of buffers.

 
> > >> Are you saying that you observe this after the display server is active?
> > Yes. Even when ubuntu Desktop is up, this behavior(absence of invalidate) is
> > observed.
> 
> Since invalidate is only called at the start of a write transaction, yes.
> The desktop should only be flipping (not even drawing into the scanout)
> which only triggers flush on the change of buffers.

Yes. But when we are opening the apps like file browser or terminal, FB will be changed hence leading to a write operation. correct me if i am wrong about this. In such scenarios also fb_obj invalidate call is not made.

(In reply to Ramalingam C from comment #4)
>  
> > > >> Are you saying that you observe this after the display server is active?
> > > Yes. Even when ubuntu Desktop is up, this behavior(absence of invalidate) is
> > > observed.
> > 
> > Since invalidate is only called at the start of a write transaction, yes.
> > The desktop should only be flipping (not even drawing into the scanout)
> > which only triggers flush on the change of buffers.
> 
> Yes. But when we are opening the apps like file browser or terminal, FB will
> be changed hence leading to a write operation. correct me if i am wrong
> about this. In such scenarios also fb_obj invalidate call is not made.

The writes are to a backbuffer which is flipped to the scanout, hence no invalidate only flush from the flip.

Thanks for the information Chris,

I did some experiemnts and found that intel_eDP_drrs_invalidate has to be added to the intel_frontbuffer_flip_prepare.

With this on ubuntu Desktop environment eDP Idleness DRRS is working. But to test the all corner case I am developing a IGT. In IGT environment DRRS not updated in few situations. Have to divein further for more info.

For now I have submitted a patch to add the drrs_invalidate to the frontbuffer_flip_prepare.

Hi,

With following patches FB changes with flip is captured and DRRS is notified accordingly.

http://www.spinics.net/lists/intel-gfx/msg68515.html
http://www.spinics.net/lists/intel-gfx/msg68516.html

But if the FB change carried out without flip, then we dont get the fb change notification.

Might be in few places in intel_gem.c fb_obj_invalidate call is missed. Else the obj->frontbuffer_bits are not set while calling the fb_obj_invalidate.

Gem expert's eye on this will be fruitful.

Hmm, invalidate is only called if the object is already bound to a fb when it is mapped. But we typically initialise the object, then bind to a fb for scanout. I guess when we pin_to_display we should also do an invalidate to catch this case.

Upclocking was needed in intel_edp_drrs_invalidate and also in intel_edp_drrs_flush. Documentation on intel_edp_drrs_flush mislead to a expectation of the intel_fb_obj_invalidate for every content change in the planes. 

A change is submitted for documentation correction and also for the code change.

Thanks Daniel for finding the cause. 
Thanks Chris for helping me in the debugging.