- 03 Sep, 2018 40 commits
-
-
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 <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
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:
-
Laurent Pinchart authored
The omap_crtcs global array is used to store pointers to omap_crtc indexed by DISPC channel number, in order to look them up in the dss_mgr operations. Store the information in the omap_drm_private structure in the form of an array of omap_drm_pipeline pointers. Signed-off-by:
-
Laurent Pinchart authored
Replace the dss display device pointer by a pipe pointer that will allow the omap_crtc_init() function to access both the display and the DSS output. As a result we can remove the omapdss_device_get_dispc_channel() function that is now unneeded. Signed-off-by:
-
Laurent Pinchart authored
To simplify the pipeline disconnection handling merge the omapdss_device_disconnect() and omapdss_output_unset_device() functions. The device state check is now called for every device in the pipeline, extending this sanity check coverage. There is no need to return an error from omapdss_device_disconnect() when the check fails, as omapdss_output_unset_device() used to do, given that we can't prevent disconnection due to device unbinding (the return value of omapdss_output_unset_device() is never checked in the current code for that reason). Signed-off-by:
-
Laurent Pinchart authored
The display type is validated when the display is connected to the DSS output. We already have all the information we need for validation when initializing the outputs. Move validation to output initialization to simplify pipeline connection handling. Signed-off-by:
-
Laurent Pinchart authored
When a DSS output is (dis)connected the omapdss_output_(un)set_device() function performs a sanity check to ensure that the output isn't already (dis)connected. The check is unnecessary as those situations should never happen, but can nonetheless be useful to catch driver bugs. To prepare for removal of the omapdss_output_(un)set_device() functions move the connection check to the omapdss_device_connect() function. The omapdss_device_disconnect() already contains a corresponding check. Signed-off-by:
-
Laurent Pinchart authored
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. To reconcile the omapdrm and omapdss drivers with the DRM bridge and panel model, we need to reverse the direction of the DSS device operations. Start with the connect and disconnect operations. Signed-off-by:
-
Laurent Pinchart authored
Create an omap_drm_pipeline structure to model display pipelines, made of a CRTC, an encoder, a connector and a DSS display device. This allows grouping related parameters together instead of storing them in independent arrays and thus improves code readability. Signed-off-by:
-
Laurent Pinchart authored
Creating all the planes in a single location instead of creating them per-CRTC with remaining planes then created in a second step simplifies the logic. Signed-off-by:
-
Laurent Pinchart authored
The crtc_idx and plane_idw variables in the main loop are always equal to the loop counter i, use it instead. Don't unnecessarily initialize dssdev to NULL. Signed-off-by:
-
Laurent Pinchart authored
Regulators for the DPI, DSI, HDMI, SDI and VENC outputs are all looked up when connecting the output omap_dss_device. There's no need to delay regulator handling to that time, get the regulators at probe time. Signed-off-by:
-
Laurent Pinchart authored
The dss_mgr_connect() and dss_mgr_disconnect() functions take two omap_dss_device pointers as parameters, which are always set to the same value by all callers. Remove the duplicated pointer. Signed-off-by:
-
Laurent Pinchart authored
Add a new omapdss_display_get() function to retrieve the omap_dss_device for a given DSS output. This will be used when reversing the direction of the DSS pipeline handling logic. Signed-off-by:
-
Laurent Pinchart authored
Similarly to for_each_dss_display(), the for_each_dss_output() macro iterates over all the DSS connected outputs. Signed-off-by:
-
Laurent Pinchart authored
Look up the next dssdev at probe time based on device tree links for all DSS outputs and encoders. This will be used to reverse the order of the dssdev connect and disconnect call chains. Signed-off-by:
-
Laurent Pinchart authored
There's no reason to delay initialization of most of the driver (such as mapping memory I/O or enabling runtime PM) to the component bind handler. Perform as much of the initialization as possible at probe time, initializing at bind time only the parts that depends on the DSS. The cleanup code is moved from unbind to remove in a similar way. Signed-off-by:
-
Laurent Pinchart authored
There's no reason to delay initialization of most of the driver (such as mapping memory I/O or enabling runtime PM) to the component bind handler. Perform as much of the initialization as possible at probe time, initializing at bind time only the parts that depends on the DSS. The cleanup code is moved from unbind to remove in a similar way. Signed-off-by:
-
Laurent Pinchart authored
There's no reason to delay initialization of most of the driver (such as mapping memory I/O or enabling runtime PM) to the component bind handler. Perform as much of the initialization as possible at probe time, initializing at bind time only the parts that depends on the DSS. The cleanup code is moved from unbind to remove in a similar way. Signed-off-by:
-
Laurent Pinchart authored
There's no reason to delay initialization of most of the driver (such as mapping memory I/O or enabling runtime PM) to the component bind handler. Perform as much of the initialization as possible at probe time, initializing at bind time only the parts that depends on the DSS. The cleanup code is moved from unbind to remove in a similar way. Signed-off-by:
-
Laurent Pinchart authored
Rename the jump labels according to the cleanup they perform, not the location they're accessed from, and move functions from error checks to cleanup paths, and move reference handling to simplify cleanup. Signed-off-by:
-
Laurent Pinchart authored
The connect handle of the analog TV and HDMI connectors casts the dssdev to panel data only to then access fields of the panel data that are also present in the dssdev. Remove the cast and use dssdev directly. Signed-off-by:
-
Laurent Pinchart authored
The omapdss_of_find_source_for_first_ep() function locates the source corresponding to the first endpoint of the first port of a device node. We can easily extend it to locate sinks as well by passing the port number as a parameter. This will be useful to find sinks in encoders drivers. Extend the function and rename it to omapdss_of_find_connected_device() to reflect its new extended purpose. Additionally, it is useful to differentiate between failures to return the connected device because no link exists in the device tree for the requested port, or because the connected device as described in the device tree is invalid or not probed yet. Return NULL in the first case and an error code in the second case, and update the callers accordingly. Signed-off-by:
-
Laurent Pinchart authored
The omap_dss_device port_num field stores the DT port number associated with the device. The field is used in different ways depending on the device type: - For DPI outputs, the port number is used as an identifier of the DPI instance - For sources, the port number is used to look up the omap_dss_device by DT port node As omap_dss_device instances are only looked up as sources by sinks, setting the field to the number of the source port works for both use cases. However, to enable looking up sinks, we need to record all the ports associated with an omap_dss_device. Do so by turning the port_num field into an of_ports bitmask. For DPI outputs the port number is additionally stored in the dpi_data structure as the output ID. Signed-off-by:
-
