- 03 Sep, 2018 40 commits
-
-
Laurent Pinchart authored
The encoder enable operation currently performs mode fixup and mode setting for all omap_dss_device instances in the display pipeline. There are dedicated encoder operations for those operations (respectively .atomic_check() and .mode_set()), but they are not used for this purpose. Move the mode fixup code to .atomic_check() and the mode set code .mode_set() to better fit the KMS model. The bus flags fixup has to happen at .mode_set() time as there is no place to store the bus flags in the atomic state structures. This could be solved by extending one of the state structures, but as the goal is to replace the fixup by direct usage of bus flags through the driver, that would be pointless. 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>
-
Laurent Pinchart authored
The bus flags stored in omap_dss_device instances are used to fixup the video mode before setting it, to honour constraints that can't be expressed through drm_display_mode. The fixup occurs in the CRTC mode set operation and the resulting video mode is stored internally in the CRTC. It is then used next by omap_encoder_enable() to apply mode fixups for the omap_dss_device instances in omap_encoder_update(). Move the hack to the omap_encoder_update() function right before applying the omap_dss_device fixups, in order to group all fixups together. Signed-off-by:
-
Laurent Pinchart authored
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 authored
The analog TV, DVI and HDMI connectors all report timing information through the .get_timings() information. For analog TV outputs the information is queried from the encoder, so the operation is unused. Remove it. For HDMI outputs the display pipeline provides EDID capability, so the operation is unused as well. Remove it. For DVI outputs the operation is also unused if the pipeline provides EDID capability. Otherwise (when the DDC bus is not connected) we shouldn't hardcode a single mode, but instead report no mode and let the KMS core add default modes. This is achieved by removing the operation. Signed-off-by:
-
Laurent Pinchart authored
Timings for the TV output are currently reported by the analog TV connector. This has the disadvantage of having to handle timing-related operations in a connector omap_dss_device that has, at the hardware level, no knowledge of any timing information. Implement the .get_timings() operation in the venc driver, and get timings from the first component in the pipeline that implements the operatation. This switches the duty of reporting analog TV timings from the connector to the encoder. Signed-off-by:
-
Laurent Pinchart authored
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 authored
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 authored
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 authored
The .check_timings() operation is present in all panels and connectors. The fallback that uses .get_timings() in the absence of .check_timings() is thus unneeded. While it could be argued that the fallback implements a useful check that should be extended to cover all fixed-resolution panels, the code is currently unused and gets in the way of the ongoing refactoring. Remove it, a similar feature can always be added later. Signed-off-by:
-
Laurent Pinchart authored
The omap_dss_device .set_timings() operations are called directly from omap_encoder_update(), and indirectly from the omap_dss_device .enable() operation. The latter is called from omap_encoder_enable(), right after calling omap_encoder_update(). The .set_timings() operation it thus called twice in a row. Fix it by removing the indirect call. Signed-off-by:
-
Laurent Pinchart authored
The .set_timings() operations of the omap_dss_device instances don't need to modify the passed timings. Make the pointer const. Signed-off-by:
-
Laurent Pinchart authored
Both the .check_timings() and .set_timings() handlers call tfp410_fix_timings() to fix the timing's flags. As .check_timings() is always called before .set_timings(), there's no need to fix the flags twice. Remove the tfp410_fix_timings() call from .set_timings(). Signed-off-by:
-
Laurent Pinchart authored
The two functions implement the .set_timings() and .check_timings() operations. Rename them to hdmi_disply_set_timings() and hdmi_display_check_timings() respectively to match the operations names and make searching the source code easier. Signed-off-by:
-
Laurent Pinchart authored
Instead of determining the connector type from the type of the display's omap_dss_device and passing it to the omap_connector_init() function, move the type determination code to omap_connector.c and remove the type argument to the connector init function. This moves code to a more natural location, making the driver easier to read. Signed-off-by:
-
Laurent Pinchart authored
The drm_connector implementation requires access to the omap_dss_device corresponding to the display, which is passed to its initialization function and stored internally. Refactoring of the timings operations will require access to the output omap_dss_device. To prepare for that, pass it to the connector initialization function and store it internally as well. Signed-off-by:
-
Laurent Pinchart authored
The HDMI mode (.set_hdmi_mode()) and infoframe (.set_infoframe()) operations are called recursively from the display device back to the HDMI encoder. This isn't required, as all components other than the HDMI encoder just forward the operation to the previous component in the chain. Call the operations directly on the HDMI encoder. Signed-off-by:
-
Laurent Pinchart authored
The drm_encoder implementation requires access to the omap_dss_device corresponding to the display, which is passed to its initialization function and stored internally. Clean up of the HDMI mode and infoframe handling will require access to the output omap_dss_device. To prepare for that, pass it to the encoder initialization function and store it internally as well. Signed-off-by:
-
Laurent Pinchart authored
The CRTC mode set implementation needs to access the omap_dss_device for the pipeline display. To do so, it iterates over all pipelines to find the one that contains an encoder corresponding to the CRTC, and request the display device from the encoder. That's a very complicated dance when the CRTC has a direct pipeline pointer already, and the pipeline contains a pointer to the display device. Replace the convoluted code with direct access. Signed-off-by:
-
Laurent Pinchart authored
Instead of calling the EDID read operation (.read_edid()) recursively from the display device back to the first device that provides EDID read support, iterate over the devices manually in the DRM connector code. This moves the complexity to a single central location and simplifies the logic in omap_dss_device drivers. Signed-off-by:
-
Laurent Pinchart authored
On HDMI outputs, CEC support requires notification of HPD signal deassertion. The HPD signal can be handled by various omap_dss_device instances in the pipeline, and all of them forward HPD events to the OMAP4 internal HDMI encoder. Knowledge of the DSS internals need to be removed from the omap_dss_device instances in order to migrate to drm_bridge. To do so, move HPD handling for CEC to the omap_connector. Signed-off-by:
-
Laurent Pinchart authored
The omap_dss_device .enable_hpd() and .disable_hpd() are used to enable and disable hot-plug detection at omapdrm probe and remove time. This is required to avoid reporting hot-plug detection events before the DRM infrastructure is ready to accept them, as that could result in crashes or other malfunction. Hot-plug event reporting is conditioned by both HPD being enabled through the .enable_hpd() operation and by the HPD callback being registered though the .register_hpd_cb() operation. We thus don't need a separate enable operation if we can guarantee that callbacks won't be registered too early. HPD callbacks are registered at connector initialization time, which is too early to start reporting HPD events. There's however nothing blocking a move of callback registration to a later time when the omapdrm driver calls the HPD enable operations. Do so, and remove the HPD enable operation completely from omap_dss_device drivers. Signed-off-by:
-
Laurent Pinchart authored
The HPD-related omap_dss_device operations are now only called when the device supports HPD. There's no need to duplicate that check in the omap_dss_device drivers. The .register_hpd_cb() operation can as a result be turned into a void operation. Signed-off-by:
-
Laurent Pinchart authored
Instead of calling the hot-plug detection callback registration operations (.register_hpd_cb() and .unregister_hpd_cb()) recursively from the display device back to the first device that provides hot plug detection support, iterate over the devices manually in the DRM connector code. This moves the complexity to a single central location and simplifies the logic in omap_dss_device drivers. Signed-off-by:
-
Laurent Pinchart authored
Instead of calling the .detect() operation recursively from the display device back to the first device that provides hot plug detection support, iterate over the devices manually in the DRM connector .detect() implementation. This moves the complexity to a single central location and simplifies the logic in omap_dss_device drivers. Signed-off-by:
-
Laurent Pinchart authored
When an omap_dss_device operation can be implemented in multiple places in a chain of devices, it is important to find out which device to address to perfom the operation. This is currently done by calling the operation on the display device at the end of the chain, and recursively delagating the operation to the previous device if it can't be performed locally. The drawback of this approach is an increased complexity in omap_dss_device drivers. In order to simplify the drivers, we will switch from a recursive model to an interative model, centralizing the complexity in a single location. This requires knowing which operations an omap_dss_device supports at runtime. We can already test which operations are implemented by checking the operation pointer, but implemented operations can require resources whose availability varies between systems. For instance a hot-plug signal from a connector can be wired to a GPIO or to a bridge chip. Add operation flags that can be set in the omap_dss_device structure by drivers to signal support for operations. Signed-off-by:
-
Laurent Pinchart authored
omap_dss_device instances have two ops structures, omap_dss_driver and omap_dss_device_ops. The former is used for devices at the end of the pipeline (a.k.a. display devices), and the latter for intermediate devices. Having two sets of operations isn't convenient as code that iterates over omap_dss_device instances need to take them both into account. There's currently a reasonably small amount of such code, but more will be introduced to move the driver away from recursive operations. To simplify current and future code, move all operations that are not specific to the display device to the omap_dss_device_ops. Signed-off-by:
-
Laurent Pinchart authored
The GPIO descriptor API is favoured over the plain GPIO API for consumer drivers. Using it simplifies the driver code. As the descriptor API handles the active-low flag internally we need to invert the polarity of all GPIO operations in the driver. Rename the nreset_gpio field to reset_gpio to reflect that. The reset GPIO is mandatory, so drop conditional tests through the driver. Signed-off-by:
-
Laurent Pinchart authored
The driver doesn't use GPIOs and thus doesn't need to include the linux/gpio.h header. Signed-off-by:
-
Laurent Pinchart authored
The GPIO descriptor API is favoured over the plain GPIO API for consumer drivers. Using it simplifies the driver code. Signed-off-by:
-
Laurent Pinchart authored
The GPIO descriptor API is favoured over the plain GPIO API for consumer drivers. Using it simplifies the driver code. The reset GPIO is mandatory, so drop conditional tests through the driver. The qvga GPIO is unused, so drop it completely. Signed-off-by:
-
Laurent Pinchart authored
The GPIO descriptor API is favoured over the plain GPIO API for consumer drivers. Using it simplifies the driver code. As the descriptor API handles the active-low flag internally we need to invert the polarity of all GPIO operations in the driver. Signed-off-by:
-
Laurent Pinchart authored
The GPIO descriptor API is favoured over the plain GPIO API for consumer drivers. Using it simplifies the driver code. Signed-off-by:
-
Laurent Pinchart authored
Various functions that need to differentiate between omap_dss_device instances corresponding to displays and to internal encoders use the omap_dss_device.driver field, which is only set for display instances. This gets in the way of the omap_dss_device operations refactoring. Replace that with a check based on the output_type field which is set for all omap_dss_device instances but displays. Signed-off-by:
-
Laurent Pinchart authored
The omapdrm driver checks at suspend and resume time whether the displays it operates on have their driver operations set. This check is unneeded, as all display drivers set the driver operations field at probe time and never touch it afterwards. This is furthermore proven by the dereferencing of the driver field without checking it first in several locations. The omapdss driver performs a similar check at shutdown time. This is unneeded as well, as the for_each_dss_display() macro it uses to iterate over displays locates the displays by checking the driver field internally. As those checks are unnecessary, remove them. Signed-off-by:
-
Laurent Pinchart authored
The .get_mirror() and .set_mirror() omap_dss_driver operations are implemented by the panel-tpo-td043mtea1 driver but are never used. Remove them. Signed-off-by:
-
Laurent Pinchart authored
The .probe(), .remove(), .run_test(), .get_rotate() and .set_rotate() omap_dss_driver operations are not used. Remove them. Signed-off-by:
-
Laurent Pinchart authored
The dss_mgr .connect() and .disconnect() are implemented as no-op in omapdrm. The operations are unneeded, remove them. Signed-off-by:
-
Laurent Pinchart authored
The omap_dss_device.dispc_channel_connect field is used by DSS outputs to fail the .enable() operation if they're not connected. Set the field directly from the (dis)connect handlers of the DSS outputs instead of going through the CRTC dss_mgr operations. Signed-off-by:
-
Laurent Pinchart authored
The CRTC connect handler checks whether the DSS output supports the DISPC channel assigned to it. As the channel is assigned to the output by the output driver a failure there could only result from a driver bug. All the output drivers have been verified and they are always assigned a DISPC channel that is supported on the SoC they run on. The check can thus be removed. Signed-off-by:
-
Laurent Pinchart authored
The omap_crtc_output global array is used to look up the DSS output device by channel. We can replace that by accessing the output device from the pipeline if we store the pipeline pointer in the omap_crtc structure. The global array is also used to protect against double connection of an output. This can't happen with the connection handling mechanism going from DSS outputs to displays. We can thus drop that check, allowing removal of the global array. Signed-off-by:
-
