diff options
author | Laurent Pinchart <laurent.pinchart@ideasonboard.com> | 2018-06-07 00:17:32 +0300 |
---|---|---|
committer | Tomi Valkeinen <tomi.valkeinen@ti.com> | 2018-09-03 16:13:30 +0300 |
commit | 31cd7afa3086f1206ef4c7434e033669702adf08 (patch) | |
tree | 3fca306d5e5489986f30ad65752b8a6aec9b5ba1 /Documentation | |
parent | ca6e968b9326a17d072b14b658fff538466c6bd2 (diff) | |
download | linux-31cd7afa3086f1206ef4c7434e033669702adf08.tar.xz |
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 'Documentation')
0 files changed, 0 insertions, 0 deletions