summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/stackcollapse-report
diff options
context:
space:
mode:
authorMaxime Ripard <mripard@kernel.org>2026-03-05 10:04:53 +0100
committerMaxime Ripard <mripard@kernel.org>2026-03-24 13:54:28 +0100
commitf3934e12f20c552f764e6488aaa1ab76cdc20343 (patch)
tree0a75d8b809e3089d3758ad2201dc4a0fc419d5e9 /tools/perf/scripts/python/bin/stackcollapse-report
parentd994acc526c70d40ec9029cfe03d08ee411083c5 (diff)
drm/connector: Introduce drm_output_color_format enum
The EDID parsing code initially introduced the DRM_COLOR_FORMAT_* defines to represent the sink capabilities. Since a given sink could support multiple formats, it was first defined as a bitmask. However, the core and drivers have since leveraged those defines to represent both the supported formats but also the current format being used. Considering the latter case, the more natural, and consistent, thing to do would be to create an enum of all the possible formats, and then list the supported formats using a bitmask of the individual enum values. Let's create a new enum following that pattern, drm_output_color_format, while maintaining the DRM_COLOR_FORMAT_* compatibility to make the transition easier. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-1-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-report')
0 files changed, 0 insertions, 0 deletions