[PATCH/RFC 00/60] omapdrm: Reverse direction of DSS device (dis)connect operations

[Tomi Valkeinen]

Hi,

On 07/03/18 02:24, Laurent Pinchart wrote:
> Hello,
> 
> This patch series is a first step towards moving the omapdrm driver away from
> the custom bridge and panel drivers to drm_bridge and drm_panel.
> 
> The main blocker to transition to drm_bridge and drm_panel is the direction of
> the bridge operations. While the omapdrm driver manages its components from
> sink to source (panel to DSS output), the drm_bridge API is manages bridges in
> the source to sink direction. This makes the two models incompatible, and
> requires reversing the direction of operations inside omapdrm.
> 
> Don't rejoice too fast, we're still far from a complete transition, but this
> first step paves the way by reworking the driver's internals to make source to
> sink order possible. It then transitions the connect and disconnect operations
> (the omapdrm equivalent of the drm_bridge attach and detach operations) to the
> new direction.
> 
> I've sent the patches as an RFC as I might not be aware of all the
> consequences of the numerous changes to the driver's internals, even if I took
> care to analyze the code flows to the best of my abilities.
> 
> The series contains patches previously posted by Jyri and Peter that I have
> found helpful. Please see the individual patches for changes compared to the
> original versions (trivial conflict resolutions caused by a rebase are not
> mentioned).
> 
> The patches are based on top of a merge between Tomi's omapdrm-next branch and
> the drm-misc/drm-misc-next branch for the "drm: fix drm_get_max_iomem type
> mismatch" compilation fix. They can be found at
> 
> 	git://linuxtv.org/pinchartl/media.git omapdrm/bridge
> 
> The series has been tested on a Pandaboard with the HDMI and DVI outputs. All
> patches have been at least compile-tested individually. I'll now go through
> the process of making sure each of them gets tested on hardware as well.

Thanks, nice work!

I did a read-the-descs-review, and looks good to me. My only comments
are what I already mentioned in the chat: AM5 EVM doesn't work LCD
(panel-dpi broken, perhaps?) (AM5 EVM was the only board I tested), and
patch 7 it not correct, as the infoframe is set from omap_encoder.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki