aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-02-26drm/omap: hdmi4: Register a drm_bridge for EDID readLaurent Pinchart2-6/+75
In order to integrate with a chain of drm_bridge, the internal HDMI4 encoder has to expose the EDID read operation through the drm_bridge API. Register a bridge at initialisation time to do so. For the time being make the next bridge in the chain optional as the HDMI output is still based on omap_dss_device. The create_connector argument to the bridge attach function is also ignored for the same reason. This will be changed later when removing the related omapdrm-specific display drivers. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/omap: hdmi5: Rework EDID read to isolate data readLaurent Pinchart3-77/+65
In preparation of adding DRM bridge support to the hdmi5 encoder code, rework the EDID read to isolate data read. The hdmi_read_edid() function is the main entry point. It performs all initialisation steps required prior to reading the EDID (such as ensuring the device is powered on), as well as corresponding cleanup steps afterwards. EDID read itself is handled by hdmi_read_edid_data() that calls the hdmi5_core_ddc_read() function to read individual blocks. This new code architecture will allow reusing hdmi_read_edid() and hdmi5_core_ddc_read() for the drm_bridge EDID read implementation, while swapping out hdmi_read_edid_data() for the DRM drm_do_get_edid() function. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/omap: hdmi4: Rework EDID read to isolate data readLaurent Pinchart3-84/+73
In preparation of adding DRM bridge support to the hdmi4 encoder code, rework the EDID read to isolate data read. The hdmi_read_edid() function is the main entry point. It performs all initialisation steps required prior to reading the EDID (such as ensuring the device is powered on), as well as corresponding cleanup steps afterwards. EDID read itself is handled by hdmi_read_edid_data() that calls the hdmi4_core_ddc_read() function to read individual blocks. This new code architecture will allow reusing hdmi_read_edid() and hdmi4_core_ddc_read() for the drm_bridge EDID read implementation, while swapping out hdmi_read_edid_data() for the DRM drm_do_get_edid() function. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/omap: hdmi: Allocate EDID in the .read_edid() operationLaurent Pinchart4-27/+47
Bring the omapdss-specific .read_edid() operation in sync with the drm_bridge .get_edid() operation to ease code reuse. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/omap: dss: Make omap_dss_device_ops optionalLaurent Pinchart4-16/+22
As part of the move to drm_bridge ops, the dssdev ops will become empty for some of the internal encoders. Make them optional in the driver to allow them to be removed completely, easing the transition. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/omap: Add infrastructure to support drm_bridge local to DSS outputsLaurent Pinchart9-12/+26
In order to support drm_bridge-based pipeline, the internal HDMI encoders will need to expose the EDID read operation through the drm_bridge API, and thus to expose a drm_bridge instance corresponding to the encoder. The HDMI encoders are however handled as omap_dss_device instances, which conflicts with this requirement. In order to move forward with the drm_bridge transition, add support for creating drm_bridge instances local to DSS outputs. If a local bridge is passed to the omapdss_device_init_output() function, it is used as the first bridge in the chain, and the omap_dss_device.next_bridge field is set to the next bridge for the use of the internal encoders' bridges. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/omap: dss: Fix output next device lookup in DTLaurent Pinchart13-15/+14
The DSS core looks up the next device connected to an output by traversing the OF graph. It currently hardcodes the local port number to 0, which breaks any output with a different port number (SDI on OMAP3 and any DPI output but the first one). Fix this by repurposing the currently unused of_ports bitmask in omap_dss_device with an of_port output port number, and use it to traverse the OF graph. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/omap: Use the drm_panel_bridge APILaurent Pinchart5-47/+32
Replace the manual panel handling code by a drm_panel_bridge. This simplifies the driver and allows all components in the display pipeline to be treated as bridges, paving the way to generic connector handling. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/omap: Factor out display type to connector type conversionLaurent Pinchart3-18/+25
Move the code that computes the DRM connector type for the omapdss_device display type to a new omapdss_device_connector_type() function for later reuse. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/omap: Simplify HDMI mode and infoframe configurationLaurent Pinchart3-15/+1
Remove the omap_connector_get_hdmi_mode() function as the HDMI mode can be accessed directly from the connector's display info. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/omap: dss: Cleanup DSS ports on initialisation failureLaurent Pinchart1-17/+26
When the DSS initialises its output DPI and SDI ports, failures don't clean up previous successfully initialised ports. This can lead to resource leak or memory corruption. Fix it. Reported-by: Hans Verkuil <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm: Add helper to create a connector for a chain of bridgesLaurent Pinchart5-1/+417
Most bridge drivers create a DRM connector to model the connector at the output of the bridge. This model is historical and has worked pretty well so far, but causes several issues: - It prevents supporting more complex display pipelines where DRM connector operations are split over multiple components. For instance a pipeline with a bridge connected to the DDC signals to read EDID data, and another one connected to the HPD signal to detect connection and disconnection, will not be possible to support through this model. - It requires every bridge driver to implement similar connector handling code, resulting in code duplication. - It assumes that a bridge will either be wired to a connector or to another bridge, but doesn't support bridges that can be used in both positions very well (although there is some ad-hoc support for this in the analogix_dp bridge driver). In order to solve these issues, ownership of the connector needs to be moved to the display controller driver. To avoid code duplication in display controller drivers, add a new helper to create and manage a DRM connector backed by a chain of bridges. All connector operations are delegating to the appropriate bridge in the chain. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: tfp410: Allow operation without drm_connectorLaurent Pinchart1-4/+2
The tfp410 driver can operate as part of a pipeline where the drm_connector is created by the display controller. Enable this mode of operation by skipping creation of a drm_connector internally. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: tfp410: Replace manual connector handling with bridgeLaurent Pinchart1-141/+75
Now that a driver is available for display connectors, replace the manual connector handling code with usage of the DRM bridge API. The tfp410 driver doesn't deal with the display connector directly anymore, but still delegates drm_connector operations to the next bridge. This brings us one step closer to having the tfp410 driver handling the TFP410 only. Signed-off-by: Laurent Pinchart <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: panel: Implement bridge connector operationsLaurent Pinchart1-4/+13
Implement the newly added bridge connector operations, allowing the usage of drm_bridge_panel with drm_bridge_connector. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: Add driver for the TI TPD12S015 HDMI level shifterLaurent Pinchart3-0/+220
The TI TPD12S015 is an HDMI level shifter and ESD protector controlled through GPIOs. Add a DRM bridge driver for the device. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: Add bridge driver for display connectorsLaurent Pinchart3-0/+307
Display connectors are modelled in DT as a device node, but have so far been handled manually in several bridge drivers. This resulted in duplicate code in several bridge drivers, with slightly different (and thus confusing) logics. In order to fix this, implement a bridge driver for display connectors. The driver centralises logic for the DVI, HDMI, VGAn composite and S-video connectors and exposes corresponding bridge operations. This driver in itself doesn't solve the issue completely, changes in bridge and display controller drivers are needed to make use of the new connector driver. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: simple-bridge: Add support for the TI OPA362Laurent Pinchart1-0/+5
The TI OPA362 is an analog video amplifier controlled through a GPIO. Add support for it to the simple-bridge driver. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: simple-bridge: Add support for enable GPIOLaurent Pinchart1-4/+18
If an enable GPIO is declared in the firmware, assert it when enabling the bridge and deassert it when disabling it. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Stefan Agner <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: simple-bridge: Add support for non-VGA bridgesLaurent Pinchart1-12/+29
Create a new simple_bridge_info structure that stores information about the bridge model, and store the bridge timings in there, along with the connector type. Use that new structure for of_device_id data. This enables support for non-VGA bridges. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Stefan Agner <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: dumb-vga-dac: Rename driver to simple-bridgeLaurent Pinchart9-16/+16
The dumb-vga-dac driver can support simple DRM bridges without being limited to VGA DACs. Rename it to simple-bridge. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Acked-by: Maxime Ripard <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: dumb-vga-dac: Rename internal symbols to simple-bridgeLaurent Pinchart1-77/+77
The dumb-vga-dac driver is a simple DRM bridge driver for simple VGA DACs that don't require configuration. Other non-VGA bridges fall in a similar category, and would benefit from a common driver. Prepare for this by renaming the internal symbols from dumb-vga-dac to simple-bridge. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: Extend bridge API to disable connector creationLaurent Pinchart60-79/+231
Most bridge drivers create a DRM connector to model the connector at the output of the bridge. This model is historical and has worked pretty well so far, but causes several issues: - It prevents supporting more complex display pipelines where DRM connector operations are split over multiple components. For instance a pipeline with a bridge connected to the DDC signals to read EDID data, and another one connected to the HPD signal to detect connection and disconnection, will not be possible to support through this model. - It requires every bridge driver to implement similar connector handling code, resulting in code duplication. - It assumes that a bridge will either be wired to a connector or to another bridge, but doesn't support bridges that can be used in both positions very well (although there is some ad-hoc support for this in the analogix_dp bridge driver). In order to solve these issues, ownership of the connector should be moved to the display controller driver (where it can be implemented using helpers provided by the core). Extend the bridge API to allow disabling connector creation in bridge drivers as a first step towards the new model. The new flags argument to the bridge .attach() operation allows instructing the bridge driver to skip creating a connector. Unconditionally set the new flags argument to 0 for now to keep the existing behaviour, and modify all existing bridge drivers to return an error when connector creation is not requested as they don't support this feature yet. The change is based on the following semantic patch, with manual review and edits. @ rule1 @ identifier funcs; identifier fn; @@ struct drm_bridge_funcs funcs = { ..., .attach = fn }; @ depends on rule1 @ identifier rule1.fn; identifier bridge; statement S, S1; @@ int fn( struct drm_bridge *bridge + , enum drm_bridge_attach_flags flags ) { ... when != S + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) { + DRM_ERROR("Fix bridge driver to make connector optional!"); + return -EINVAL; + } + S1 ... } @ depends on rule1 @ identifier rule1.fn; identifier bridge, flags; expression E1, E2, E3; @@ int fn( struct drm_bridge *bridge, enum drm_bridge_attach_flags flags ) { <... drm_bridge_attach(E1, E2, E3 + , flags ) ...> } @@ expression E1, E2, E3; @@ drm_bridge_attach(E1, E2, E3 + , 0 ) Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: Add interlace_allowed flag to drm_bridgeLaurent Pinchart1-0/+5
In preparation for a connector creation helper based on a chain of bridges, add a flag to the drm_bridge structure to report support for interlaced modes. This will be used to set the connector's interlace_allowed flag. Signed-off-by: Laurent Pinchart <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: Add connector-related bridge operations and dataLaurent Pinchart2-2/+391
To support implementation of DRM connectors on top of DRM bridges instead of by bridges, the drm_bridge needs to expose new operations and data: - Output detection, hot-plug notification, mode retrieval and EDID retrieval operations - Bitmask of supported operations - Bridge output type - I2C adapter for DDC access Add and document these. Three new bridge helper functions are also added to handle hot plug notification in a way that is as transparent as possible for the bridges. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: Improve overview documentationLaurent Pinchart2-28/+79
Clean up the drm_bridge overview documentation, and expand the operations documentation to provide more details on API usage. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: Fix atomic state ops documentationLaurent Pinchart1-6/+14
The drm_bridge_funcs atomic_state_duplicate and atomic_state_destroy operations are erroneously documented as having a default implementation if not implemented in bridge drivers. This isn't correct, fix the documentation. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/bridge: Document the drm_encoder.bridge_chain field as privateLaurent Pinchart1-1/+2
The drm_encoder.bridge_chain is not meant to be touched manually by drivers. Make this clear in the documentation. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/edid: Add flag to drm_display_info to identify HDMI sinksLaurent Pinchart3-0/+28
The drm_display_info structure contains many fields related to HDMI sinks, but none that identifies if a sink compliant with CEA-861 (EDID) shall be treated as an HDMI sink or a DVI sink. Add such a flag, and populate it according to section 8.3.3 ("DVI/HDMI Device Discrimination") of the HDMI v1.3 specification. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/connector: Add helper to get a connector type nameLaurent Pinchart2-0/+16
drm_connector.c contains a map of connector types (DRM_MODE_CONNECTOR_*) to name strings, but doesn't expose it. This leads to drivers having to store a similar map. Add a new drm_get_connector_type_name() helper function that return a name string for a connector type. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26video: hdmi: Change return type of hdmi_avi_infoframe_init() to voidLaurent Pinchart3-14/+4
The hdmi_avi_infoframe_init() never needs to return an error, change its return type to void. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Acked-by: Bartlomiej Zolnierkiewicz <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-25drm/panfrost: Add support for multiple power domainsNicolas Boichat3-8/+102
When there is a single power domain per device, the core will ensure the power domain is switched on (so it is technically equivalent to having not power domain specified at all). However, when there are multiple domains, as in MT8183 Bifrost GPU, we need to handle them in driver code. Signed-off-by: Nicolas Boichat <[email protected]> Reviewed-by: Ulf Hansson <[email protected]> Reviewed-by: Steven Price <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-25drm/panfrost: Add support for multiple regulatorsNicolas Boichat3-18/+51
Some GPUs, namely, the bifrost/g72 part on MT8183, have a second regulator for their SRAM, let's add support for that. We extend the framework in a generic manner so that we could support more than 2 regulators, if required. Signed-off-by: Nicolas Boichat <[email protected]> Reviewed-by: Steven Price <[email protected]> Reviwed-by: Mark Brown <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-25drm/panfrost: Improve error reporting in panfrost_gpu_power_onNicolas Boichat1-4/+7
It is useful to know which component cannot be powered on. Signed-off-by: Nicolas Boichat <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]> Reviewed-by: Steven Price <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-25drm/i915: Update DRIVER_DATE to 20200225Rodrigo Vivi1-2/+2
Signed-off-by: Rodrigo Vivi <[email protected]>
2020-02-25Merge drm/drm-next into drm-intel-next-queuedRodrigo Vivi9450-186586/+464703
Some DSI and VBT pending patches from Hans will apply cleanly and with less ugly conflicts if they are rebuilt on top of other patches that recently landed on drm-next. Reference: https://patchwork.freedesktop.org/series/70952/ Cc: Hans de Goede <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]
2020-02-25drm/amd/display: limit display clock to 100MHz to avoid FIFO errorYu-ting Shen2-0/+4
[Why] when changing display clock, SMU need to use power up DFS and use DENTIST to ramp DFS DID to switch target frequency before switching back to bypass. [How] fixed the minimum display clock to 100MHz, it's W/A the same with PCO. Signed-off-by: Yu-ting Shen <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-25drm/amd/display: Access patches from stream for ignore MSA monitor patchJaehyun Chung1-2/+2
[Why] System will crash when trying to access local sink in core_link_enable_stream in MST case. [How] Access patches directly from stream. Signed-off-by: Jaehyun Chung <[email protected]> Reviewed-by: Aric Cyr <[email protected]> Reviewed-by: Ashley Thomas <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-25drm/amd/display: Temporarily disable stutter on MPO transitionGeorge Shen5-1/+37
[Why] Underflow sometimes occurs during transition into MPO with stutter enabled. [How] When transitioning into MPO, disable stutter. Re-enable stutter within one frame. Signed-off-by: George Shen <[email protected]> Signed-off-by: Tony Cheng <[email protected]> Reviewed-by: Eric Yang <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-25drm/amd/display: Make clock table struct more accessibleSung Lee1-1/+1
[WHY] Currently clock table struct is very far down in the bounding box struct making it hard to find while debugging, especially when using the dal3dbgext. [HOW] Move it up so it is the first struct defined, and therefore much easier to find and access. Signed-off-by: Sung Lee <[email protected]> Reviewed-by: Eric Yang <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-25drm/amd/display: optimize prgoram wm and clksYongqiang Sun10-102/+237
[Why] In some display configuration like 1080P monitor playing a 1080P video, if user use ALT+F4 to exit Movie and TV, there is a chance clocks are same only water mark changed. Current clock optimization machanism will result in water mark keeps high after exit Movie and TV app. [How] Return if watermark need to be optimized when doing program watermark, perform the optimization after. Signed-off-by: Yongqiang Sun <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-25drm/amd/display: correct dml surface size assignmentDmytro Laktyushkin1-4/+4
Need to assign surface size rather than viewport size for surface size dml variable. Signed-off-by: Dmytro Laktyushkin <[email protected]> Reviewed-by: Eric Bernstein <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-25drm/amd/display: Update TTU properlyAlvin Lee1-0/+8
[Why] We need to update TTU properly if DRAMClockChangeWatermark changes. If TTU < DRAMClockChangeWatermark, we pstate won't be allowed and we will hang in some PSR cases. [How] Update TTU if DramClockChangeWatermark value increases (only if TTU was dependent on the watermark value on the DRAMClockChangeWatermark value in the first place). Signed-off-by: Alvin Lee <[email protected]> Reviewed-by: Jun Lei <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-25drm/amd/display: Fix RV2 Variant DetectionMichael Strauss3-18/+21
[WHY] RV2 and variants are indistinguishable by hw internal rev alone, need to be distinguishable in order to correctly set max vlevel. Previous detection change incorrectly checked for hw internal rev. [HOW] Use pci revision to check if RV2 or low power variant Correct a few overlapping ASICREV range checks Signed-off-by: Michael Strauss <[email protected]> Reviewed-by: Michael Strauss <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-25drm/amd/display: Add driver support for enabling PSR on DMCUBWyatt Wood8-10/+24
[Why] We want to be able to enable PSR on DMCUB, and fallback to DMCU when necessary. [How] Add infrastructure to enable and disable PSR on DMCUB. Signed-off-by: Wyatt Wood <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-25drm/amd/display: 3.2.74Aric Cyr1-1/+1
Signed-off-by: Aric Cyr <[email protected]> Reviewed-by: Aric Cyr <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-25drm/amd/display: remove unused dml variableDmytro Laktyushkin3-3/+0
Signed-off-by: Dmytro Laktyushkin <[email protected]> Reviewed-by: Eric Bernstein <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-25drm/amd/display: update dml input population functionDmytro Laktyushkin4-14/+18
Update dcn20_populate_dml_pipes_from_context to correctly handle odm when no surface is provided. Signed-off-by: Dmytro Laktyushkin <[email protected]> Reviewed-by: Jun Lei <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-25drm/amd/display: Add visual confirm support for FreeSync 2 ARGB2101010Peikang Zhang1-0/+4
[Why] DalMPVisualConfirm does not support FreeSync 2 ARGB2101010 which causes black visual confirm bar when playing HDR video on FreeSync 2 display in full screen mode [How] Added pink color for DalMPVisualConfirm on FreeSync 2 ARGB2101010 surface Signed-off-by: Peikang Zhang <[email protected]> Reviewed-by: Anthony Koo <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-25drm/amd/display: Link training TPS1 workaroundMartin Leung3-10/+10
[Why] Previously implemented early_cr_pattern was link level but the whole asic should be affected. [How] - change old link flag to dc level - new bit in dc->work_arounds set by DM Signed-off-by: Martin Leung <[email protected]> Reviewed-by: Joshua Aberback <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.