linux/drivers/gpu/drm/omapdrm/omap_encoder.c, branch v4.3

drm: omapdrm: Move encoder setup to encoder operations

2015-06-12T19:52:50Z

Now that the driver is fully converted to atomic operations, and that the atomic helpers call the operations in the right order, we can move encoder setup to where it belongs, in the encoder operations. Signed-off-by: Laurent Pinchart Signed-off-by: Tomi Valkeinen

drm: omapdrm: Replace encoder mode_fixup with atomic_check

2015-06-12T19:52:48Z

The encoder .mode_fixup() operation is legacy, atomic updates uses the new .atomic_check() operation. Convert the encoder driver. Signed-off-by: Laurent Pinchart Signed-off-by: Tomi Valkeinen

drm: omapdrm: Switch connector DPMS to atomic helpers

2015-06-12T19:52:48Z

The atomic connector DPMS helper implements the connector DPMS operation using atomic commit, removing the need for DPMS helper operations on CRTCs and encoders. Signed-off-by: Laurent Pinchart Signed-off-by: Tomi Valkeinen

drm: omapdrm: Switch mode config to atomic helpers

2015-06-12T19:52:47Z

This removes the legacy mode config code. The CRTC and encoder prepare and commit operations are not used anymore, remove them. Signed-off-by: Laurent Pinchart Signed-off-by: Tomi Valkeinen

drm: omapdrm: Implement encoder .disable() and .enable() operations

2015-06-12T19:52:46Z

The operations are required by the atomic helpers, implement them. Signed-off-by: Laurent Pinchart Signed-off-by: Tomi Valkeinen

drm: omapdrm: Clean up #include's

2015-06-12T19:52:46Z

Use the <...> include style instead of "..." for DRM headers and sort the headers alphabetically to ease detection of duplicates. Signed-off-by: Laurent Pinchart Signed-off-by: Tomi Valkeinen

drm/omap: Add infoframe & dvi/hdmi mode support

2014-07-04T08:17:59Z

Make the omapdrm driver use the new HDMI ops when possible. omapdrm will call set_hdmi_mode (when available) to tell the encoder driver whether the monitor is a DVI or HDMI monitor, and if it's an HDMI monitor, omapdrm will call set_hdmi_infoframe to to set the AVI infoframe. Signed-off-by: Tomi Valkeinen Cc: Rob Clark

drm/omap: fix: disable encoder before destroying it

2014-01-09T13:17:25Z

Currently, an encoder is disabled only when an apply work is queued for the corresponding crtc. This works fine for the paths where userspace explicitly disables crtc, this results in disabling the omapdss device in the crtc's pre_apply function. However, when the omapdrm module is removed, there is no work queued to ensure that the encoder is disabled. This can result in an enabled omapdss device when removing omapdrm. omapdss is left in an inconsistent state, and that prevents us from using that omapdss device being used again. Disable enabled encoders in omap_encoder_destroy, we could consider a better place for doing this later. Signed-off-by: Archit Taneja Signed-off-by: Tomi Valkeinen

OMAPDSS: rename omap_dss_device's 'output' to 'src'

2013-08-30T05:51:10Z

In the old panel device model we had "outputs", which were the encoders inside OMAP DSS block, and panel devices (omap_dss_device). The panel devices had a reference to the source of the video data, i.e. reference to an "output", in a field named "output". That was somewhat confusing even in the old panel device model, but even more so with the panel device model where we can have longer chains of display entities. This patch renames the "output" field to "src", which much better tells what the field points to. Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja

drm/omap: Fix and improve crtc and overlay manager correlation

2013-04-11T10:26:01Z

The omapdrm driver currently takes a config/module arg to figure out the number of crtcs it needs to create. We could create as many crtcs as there are overlay managers in the DSS hardware, but we don't do that because each crtc eats up one DSS overlay, and that reduces the number of planes we can attach to a single crtc. Since the number of crtcs may be lesser than the number of hardware overlay managers, we need to figure out which overlay managers to use for our crtcs. The current approach is to use pipe2chan(), which returns a higher numbered manager for the crtc. The problem with this approach is that it assumes that the overlay managers we choose will connect to the encoders the platform's panels are going to use, this isn't true, an overlay manager connects only to a few outputs/encoders, and choosing any overlay manager for our crtc might lead to a situation where the encoder cannot connect to any of the crtcs we have chosen. For example, an omap5-panda board has just one hdmi output. If num_crtc is set to 1, with the current approach, pipe2chan will pick up the LCD2 overlay manager, which cannot connect to the hdmi encoder at all. The only manager that could have connected to hdmi was the TV overlay manager. Therefore, there is a need to choose our overlay managers keeping in mind the panels we have on that platform. The new approach iterates through all the available panels, creates encoders and connectors for them, and then tries to get a suitable overlay manager to create a crtc which can connect to the encoders. We use the dispc_channel field in omap_dss_output to retrieve the desired overlay manager's channel number, we then check whether the manager had already been assigned to a crtc or not. If it was already assigned to a crtc, we assume that out of all the encoders which intend use this crtc, only one will run at a time. If the overlay manager wan't assigned to a crtc till then, we create a new crtc and link it with the overlay manager. This approach just looks for the best dispc_channel for each encoder. On DSS HW, some encoders can connect to multiple overlay managers. Since we don't try looking for alternate overlay managers, there is a greater possibility that 2 or more encoders end up asking for the same crtc, causing only one encoder to run at a time. Also, this approach isn't the most optimal one, it can do either good or bad depending on the sequence in which the panels/outputs are parsed. The optimal way would be some sort of back tracking approach, where we improve the set of managers we use as we iterate through the list of panels/encoders. That's something left for later. Signed-off-by: Archit Taneja Signed-off-by: Tomi Valkeinen