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
