- 26 Feb, 2020 20 commits
-
-
Laurent Pinchart authored
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 <laurent.pinchart@ideasonboard.com> Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Tested-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-21-laurent.pinchart@ideasonboard.com
-
Laurent Pinchart authored
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 authored
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 authored
Implement the newly added bridge connector operations, allowing the usage of drm_bridge_panel with drm_bridge_connector. Signed-off-by:
-
Laurent Pinchart authored
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 authored
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:
Maxime Ripard <mripard@kernel.org> Reviewed-by:
-
Laurent Pinchart authored
The TI OPA362 is an analog video amplifier controlled through a GPIO. Add support for it to the simple-bridge driver. Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Reviewed-by:
-
Laurent Pinchart authored
If an enable GPIO is declared in the firmware, assert it when enabling the bridge and deassert it when disabling it. Signed-off-by:
Stefan Agner <stefan@agner.ch> Reviewed-by:
-
Laurent Pinchart authored
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 authored
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 authored
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 authored
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:Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Laurent Pinchart authored
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 authored
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 authored
Clean up the drm_bridge overview documentation, and expand the operations documentation to provide more details on API usage. Signed-off-by:
-
Laurent Pinchart authored
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 authored
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 authored
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:Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Laurent Pinchart authored
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 authored
The hdmi_avi_infoframe_init() never needs to return an error, change its return type to void. Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by:
-
- 25 Feb, 2020 10 commits
-
-
Nicolas Boichat authored
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 <drinkcat@chromium.org> Reviewed-by:
Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by:
Steven Price <steven.price@arm.com> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200207052627.130118-6-drinkcat@chromium.org
-
Nicolas Boichat authored
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:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Nicolas Boichat authored
It is useful to know which component cannot be powered on. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by:
-
Boris Brezillon authored
Propagate bus format/flags so that the previous bridge element in the chain knows which input format the panel bridge expects. v11: * Fix a typo in the subject * Update the commit message so it's readable by itself v10: * Add changelog to the commit message v8 -> v9: * No changes v7: * Set atomic state hooks explicitly v4 -> v6: * Not part of the series v3: * Adjust things to match the new bus-format negotiation approach * Use drm_atomic_helper_bridge_propagate_bus_fmt * Don't implement ->atomic_check() (the core now takes care of bus flags propagation) v2: * Adjust things to match the new bus-format negotiation approach Signed-off-by:
-
Laurent Pinchart authored
The drm_bridge_funcs structure is never modified, make it const. Making it read-only can improve security as the structure contains function pointers. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
-
Laurent Pinchart authored
Factor out the manual container_of() uses to a common to_lvds_codec() macro to shorten lines (and provide better type safety, although that won't matter much in this case). Signed-off-by:
-
Gurchetan Singh authored
For old userspace, initialization will still be implicit. For backwards compatibility, enqueue virtio_gpu_cmd_context_create after the first 3D ioctl. v3: staticify virtio_gpu_create_context remove notify to batch vm-exit v6: Remove nested 3D checks (emil.velikov): - unify 3D check in resource create v7: Remove check when getting capabilities Reviewed-by:Chia-I Wu <olvaffe@gmail.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20200225000800.2966-4-gurchetansingh@chromium.orgSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Gurchetan Singh authored
Use an boolean variable to track whether a context has been initiated. v5: Fix possible race and sleep via mutex (olv) Reviewed-by:
-
Gurchetan Singh authored
We currently create an OpenGL context when opening the DRM fd if 3D is available. We may need other context types (VK,..) in the future, and the plan is to have explicit initialization for that. For explicit initialization to work, we need to factor out virtio_gpu_create_context from driver initialization. v2: Move context handle initialization too (olv) v6: Remove redundant 3D check (emil.velikov) Reviewed-by:
-
Gurchetan Singh authored
Minor cleanup, change: - file_priv--> file, - drm_file --> file. Reviewed-by:
-
- 24 Feb, 2020 1 commit
-
-
Xinliang Liu authored
Update myself email address. Add John Stultz as a reviewer. Thanks John. Update git tree to drm-misc Signed-off-by:
Xinliang Liu <xinliang.liu@linaro.org> Acked-by:
-
- 22 Feb, 2020 2 commits
-
-
Marek Szyprowski authored
Add proper MODULE_DEVICE_TABLE structure with SPI IDs to allow proper creation of SPI modalias string and fix autoloading module for this driver. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Tomi Valkeinen authored
The panel datasheet says that the panel samples at falling edge, but does not say anything about h/v sync signals. Testing shows that if the sync signals are driven on falling edge, the picture on the panel will be slightly shifted right. Setting sync drive edge to the same as data drive edge fixes this issue. Signed-off-by:
-
- 21 Feb, 2020 3 commits
-
-
Maxime Ripard authored
The A33 TCON supports LVDS, so we can toggle the support switch. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Acked-by:
Chen-Yu Tsai <wens@csie.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200214120934.107924-1-maxime@cerno.tech
-
Torsten Duwe authored
of_get_regulator() will unconditionally add "-supply" to form the property name. This is documented in commit 69511a45 ("map consumer regulator based on device tree"). Remove the suffix from the requests. Signed-off-by:
Torsten Duwe <duwe@lst.de> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200218155440.BEFB968C65@verein.lst.de
-
Torsten Duwe authored
drm_dp_link_rate_to_bw_code and ...bw_code_to_link_rate simply divide by and multiply with 27000, respectively. Avoid an overflow in the u8 dpcd[0] and the multiply+divide alltogether. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
- 20 Feb, 2020 4 commits
-
-
Andrey Lebedev authored
A20 SoC (found in Cubieboard 2 among others) requires different LVDS set up procedure than A33. Timing controller (tcon) driver only implements sun6i-style procedure, that doesn't work on A20 (sun7i). Signed-off-by:
Andrey Lebedev <andrey@lebedev.lt> Signed-off-by:
-
Andrey Lebedev authored
Timing controllers on A20 are not equivalent: tcon0 on A20 supports LVDS output and tcon1 does not. Separate the capabilities by introducing independent set of quirks for each of the tcons. Signed-off-by:
-
Andrey Lebedev authored
Document new compatibles used to differentiate between timing controllers on A20 (sun7i) Signed-off-by:
-
Andrey Lebedev authored
Different sunxi flavors require slightly different sequence for enabling LVDS output. This allows to differentiate between them. Signed-off-by:
-
