Hi,
On Fri, Jun 08, 2018 at 07:29:03PM +0300, Laurent Pinchart wrote:
Hello,
This patch series reworks all the timing-related operations (.get_timings(), .set_timings() and .check_timings()) as a step toward moving from omap_dss_device to drm_bridge.
All timing-related operations are called by the omapdrm driver on the omap_dss_device at the end of display pipeline, and the operations are then handled directly or forwarded to the previous omap_dss_device in the pipeline. This causes an issue in our quest to move to drm_bridge: the drm_bridge equivalent to the timing operations, .mode_valid(), .mode_fixup() and .mode_set(), are called in the source to sink direction.
Furthermore, timing handling in the omapdrm driver is very complicated, with timings getting mangled, stored in random places, retrieved back by unrelated code, mangled again, stored in different places, and modified across objects. Simplifying that is crucial to move to drm_bridge.
This patch series simplifies the timings operation and reverse the direction in which they're called. The driver still uses the videomode structure instead of the drm_display_mode structure to store timing information, this will be fixed in a second step.
The series is really a succession of cleanups interleaved with the real changes, with a total of 406 lines of code removed overall. It starts with small changes, cleanups and code removal in patches 01/23 to 07/23, and then introduces new DRM bus flags to specify sync signal clock edges using the DRM bus_flags mechanism in patch 08/23. This is the only extension to the DRM core.
Patches 09/23 and 10/23 start reworking the .check_timings() operation by making use of the bus flags. Patches 11/23 to 13/23 rework the .get_timings() operation, and patches 14/23 to 21/23 complete the .check_timings() rework. Patches 22/23 and 23/23 finally rework the .set_timings() operation.
The patchset is
Reviewed-by: Sebastian Reichel sebastian.reichel@collabora.co.uk
-- Sebastian