aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py
diff options
context:
space:
mode:
authorJani Nikula <[email protected]>2019-11-29 12:29:31 +0200
committerJani Nikula <[email protected]>2019-12-03 11:10:19 +0200
commit12281c8dda5a3b47008bd6a6db6645995234b4e1 (patch)
treeeb66e99d2a1b53c2ff31b364e9b50643c867c115 /tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py
parentdc190678534ee0f9042a65db1613ab1e59582bff (diff)
video: fb_defio: preserve user fb_ops
Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap and then resetting it to NULL afterwards causes problems all over the place. First, it prevents making the fbops member of struct fb_info a const pointer, which means we can't make struct fb_ops const anywhere. Second, a few places have to go out of their way to restore the original fb_mmap pointer that gets reset to NULL. Since the only user of the fbops->fb_mmap hook is fb_mmap() in fbmem.c, call fb_deferred_io_mmap() directly when deferred IO is enabled, and avoid modifying fb_ops altogether. Simply use info->fbdefio to determine whether deferred IO should be used or not. This should be accurate enough for all use cases, although perhaps not pedantically correct. v2: Simplify considerably by calling fb_deferred_io_mmap() directly (Daniel, Ville) Cc: Jaya Kumar <[email protected]> Cc: [email protected] Cc: Daniel Vetter <[email protected]> Cc: Ville Syrjälä <[email protected]> Acked-by: Noralf Trønnes <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/022c82429da15d6450ff9ac1a897322ec3124db4.1575022735.git.jani.nikula@intel.com
Diffstat (limited to 'tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py')
0 files changed, 0 insertions, 0 deletions