lwn.git/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c, branch master

drm/omap: Remove TFP410 and DVI connector drivers

2019-03-18T09:42:14+00:00

Those components are supported by the drm_bridge infrastructure, remove the omapdrm-specific driver. Signed-off-by: Laurent Pinchart Reviewed-by: Sebastian Reichel Tested-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen

drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags

2019-03-18T09:42:13+00:00

The DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE flags are deprecated in favour of the new DRM_BUS_FLAG_PIXDATA_(DRIVE|SAMPLE)_(POS|NEG)EDGE and new DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags. Replace them through the code. This effectively changes the value of the .sampling_edge bridge timings field in the dumb-vga-dac driver. This is safe to do as no driver consumes these values yet. Signed-off-by: Laurent Pinchart Acked-by: Linus Walleij Reviewed-by: Stefan Agner Tested-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen

drm/omap: Merge omap_dss_device type and output_type fields

2019-03-18T09:42:13+00:00

The omap_dss_device type and output_type fields differ mostly for historical reasons. The output_type field is required for all devices but the display at the end of the pipeline, and must be set to OMAP_DISPLAY_TYPE_NONE for the latter. The type field is required for all devices but the internal encoder, for which it is ignored. The only reason why the output_type field must be set to OMAP_DISPLAY_TYPE_NONE for the display at the end of the pipeline is to identify omap_dss_device instances corresponding to displays. This is not documented and confusing. Clean the code by adding a new display field to the omap_dss_device structure to identify displays, and merge the type and output_type fields. Signed-off-by: Laurent Pinchart Reviewed-by: Sebastian Reichel Tested-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen

drm/omap: Reverse direction of the DSS device enable/disable operations

2019-03-18T09:42:12+00:00

The omapdrm and omapdss drivers are architectured based on display pipelines made of multiple components handled from sink (display) to source (DSS output). This is incompatible with the DRM bridge and panel APIs that handle components from source to sink. Reconcile the omapdrm and omapdss drivers with the DRM bridge and panel model by reversing the direction of the DSS device .enable() and .disable() operations. This completes the move to the DRM bridge model, with the notable exception of the DSI pipelines that will require more work. We also adapt the omapdss shutdown handler dss_shutdown() to shut down all active pipelines starting from the pipeline output device instead of the display device. As a consequence the for_each_dss_display() macro isn't used and can be removed, and the omapdss_device_get_next() function underlying the macro can be simplified to search for output devices only. Signed-off-by: Laurent Pinchart Reviewed-by: Sebastian Reichel Tested-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen

drm/omap: Remove enable checks from display .enable() and .remove()

2019-03-18T09:42:11+00:00

The displays (connectors, panels and encoders) bail out from their .enable() and .disable() handlers if the dss device is already enabled or disabled. Those safety checks are not needed when the functions are called through the omapdss_device_ops, as the .enable() and .disable() handlers are called from the DRM atomic helpers that already guarantee that no double enabling or disabling can occur. However, the handlers are also called directly from the .remove() handler. While this shouldn't be needed either as the modules can't be removed as long as the device is in use, it's still a good practice to disable the device explicitly. There is currently a safety check in .remove() in some drivers but not all of them. Remove the safety checks from the .enable() and .disable() handlers, and add missing ones in the .remove() handler. Signed-off-by: Laurent Pinchart Reviewed-by: Sebastian Reichel Tested-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen

drm/omap: Remove connection checks from display .enable() and .remove()

2019-03-18T09:42:11+00:00

The displays (connectors, panels and encoders) return an error from their .enable() handler when the dss device is not connected. They also disconnect the dss device explicitly from their .remove() handler if it is still connected. Those safety checks are not needed: - The .enable() handler is called from code paths that access the dss devices chain from the display device, which is set to NULL when the device isn't connected. - The .remove() handler can only be called when unloading the module as the driver has the suppress_bind_attrs attribute set, and a reference to the module is taken when constructing the dss devices chain, so the module can only be unloaded when the dss device is disconnected. Remove the safety checks. Signed-off-by: Laurent Pinchart Reviewed-by: Sebastian Reichel Tested-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen

drm/omap: Don't call .set_timings() operation recursively

2018-09-03T13:13:30+00:00

Instead of calling the .set_timings() operation recursively from the display device backwards, iterate over the devices manually in the DRM encoder code. This moves the complexity to a single central location and simplifies the logic in omap_dss_device drivers. Signed-off-by: Laurent Pinchart Reviewed-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen

drm/omap: Don't call .check_timings() operation recursively

2018-09-03T13:13:30+00:00

The .check_timings() operation is called recursively from the display device back to the output device. Most components just forward the operation to the previous component in the chain, resulting in lots of duplicated pass-through functions. To avoid that, iterate over the components manually. Signed-off-by: Laurent Pinchart Reviewed-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen

drm/omap: Store bus flags in the omap_dss_device structure

2018-09-03T13:13:30+00:00

Source components in the display pipeline need to configure their output signals polarities and clock driving edge based on the requirements of the sink component. Those requirements are currently shared across the whole pipeline in the flags of a videomode structure, instead of being local to each bus. This both prevents multiple buses from having different configurations (when the hardware supports it), and makes it difficult to move from videomode to drm_display_mode as the latter doesn't contain bus polarities and clock edge flags. Add a bus_flags field to the omap_dss_device structure and move the DISPLAY_FLAGS_DE_(LOW|HIGH), DISPLAY_FLAGS_PIXDATA_(POS|NEG)EDGE and DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE videomode flags to bus_flags in all external encoders, connectors and panels. The videomode flags are still used internally for internal encoders, this will be addressed in a second step. The related videomode flags in the default mode of the DVI connector can simply be dropped, as they are always overridden by the TFP410 driver. Note that this results in both the DISPLAY_FLAGS_SYNC_POSEDGE and DISPLAY_FLAGS_SYNC_NEGEDGE flags being set, which is invalid, but only the former is tested for when programming the DISPC, so the DVI connector flags are effectively overridden by the TFP410 flags. Signed-off-by: Laurent Pinchart Reviewed-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen

drm/omap: Don't store video mode internally for external encoders

2018-09-03T13:13:30+00:00

The omap_dss_device .set_timings() operation for external encoders stores the video mode in the device data structure. That mode is then never used again. Drop it. Signed-off-by: Laurent Pinchart Reviewed-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen