summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/omapdrm/omap_crtc.c
diff options
context:
space:
mode:
authorLaurent Pinchart <laurent.pinchart@ideasonboard.com>2018-06-07 00:17:32 +0300
committerTomi Valkeinen <tomi.valkeinen@ti.com>2018-09-03 16:13:30 +0300
commit31cd7afa3086f1206ef4c7434e033669702adf08 (patch)
tree3fca306d5e5489986f30ad65752b8a6aec9b5ba1 /drivers/gpu/drm/omapdrm/omap_crtc.c
parentca6e968b9326a17d072b14b658fff538466c6bd2 (diff)
drm/omap: panels: Don't modify fixed timings
Panels drivers store their timings in a device data structure field that is initialized at probe time, either from hardcoded values or from firmware-supplied values. Those timings are then reported through the .get_timings() operation to construct the panel display mode. The panel timings are further modified by the .set_timings() operation, which is called with the timings retrieved by .get_timings(), and mangled by .check_timings(). The latter potentially adjusts the pixel clock only. Conceptually, modifying the panel timings is wrong, as the timings are an intrinsic property of the panel and should thus be fixed. Furthermore, modifying them this way at runtime can result in display modes reported to userspace varying between calls, which is also wrong. There's no actual need to store the mangled pixel clock value in the timings. Don't modify the panel timings in the .set_timings() operation, just forward it to the previous device in the display pipeline. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Diffstat (limited to 'drivers/gpu/drm/omapdrm/omap_crtc.c')
0 files changed, 0 insertions, 0 deletions