Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Implement fb_dirty for intel custom fb helper

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Dec 21, 2022 at 04:08:13PM +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 21.12.22 um 15:51 schrieb Ville Syrjälä:
> > On Wed, Dec 21, 2022 at 11:49:59AM +0100, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 29.11.22 um 13:43 schrieb Jouni Högander:
> >>> After splitting generic drm_fb_helper into it's own file it's left to
> >>> helper implementation to have fb_dirty function. Currently intel
> >>> fb doesn't have it. This is causing problems when PSR is enabled.
> >>>
> >>> Implement simple fb_dirty callback to deliver notifications to psr
> >>> about updates in fb console.
> >>
> >> I'm a bit confused about i915's use of fb_dirty here. How is this
> >> supposed to interact with mmap?  i915 doesn't use deferred I/O so fbdev
> >> mmap will never call fb_dirty if userspace writes to mmap'ed pages. Is
> >> this only required for the kernel's graphics console?
> > 
> > It's required for everything. mmap is presumably borked for
> > the cases where we can't use any hw based damage tracking.
> 
> In this case, it would make sense to implement the update with fb_dirty 
> (instead of the fb_ops I mentioned).
> 
> For mmap you can use fbdev's deferred I/O. There's 
> drm_fb_helper_deferrer_io() that tracks mmaped pages and regularly calls 
> fb_dirty to let the driver do an update.

Not sure we want the extra defio overhead for a feature
no one is likely to ever need.

If we actually cared about any of this we could perhaps
just hook into .fb_mmap() and turn off any stuff that
needs software dirty tracking while the buffer is mapped.

-- 
Ville Syrjälä
Intel