- 26 Feb, 2020 9 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 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 <laurent.pinchart@ideasonboard.com> Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-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:Andrzej Hajda <a.hajda@samsung.com> Reviewed-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:
-
- 19 Feb, 2020 1 commit
-
-
Samuel Holland authored
We need to make sure that the DRM driver is fully registered before allowing the panel to be attached. Otherwise, we may trigger a hotplug event before sun4i_framebuffer_init() sets up drm->mode_config.funcs, causing a NULL pointer dereference. Fixes: 1a2703bd ("drm/sun4i: dsi: Allow binding the host without a panel") Signed-off-by:
Samuel Holland <samuel@sholland.org> Signed-off-by:
-
- 18 Feb, 2020 1 commit
-
-
Boris Brezillon authored
Commit 75146591 ("drm/bridge: Add a drm_bridge_state object") introduced new helpers and hooks but the kernel was slightly broken. Fix that now. v2: * Fix the drm_atomic_add_encoder_bridges() doc Fixes: 75146591 ("drm/bridge: Add a drm_bridge_state object") Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
- 17 Feb, 2020 9 commits
-
-
Gerd Hoffmann authored
Move all remaining virtio_gpu_notify() calls from virtio_gpu_cmd_* to the callers, for consistency reasons. Signed-off-by:
-
Gerd Hoffmann authored
Move virtio_gpu_notify() to higher-level functions for virtio_gpu_cmd_get_display_info() and virtio_gpu_cmd_get_edids(). virtio_gpu_config_changed_work_func() and virtio_gpu_init() will batch commands and notify only once per update Signed-off-by:
-
Gerd Hoffmann authored
Move virtio_gpu_notify() to higher-level functions for virtio_gpu_cmd_create_resource(), virtio_gpu_cmd_resource_create_3d() and virtio_gpu_cmd_resource_attach_backing(). virtio_gpu_object_create() will batch commands and notify only once when creating a resource. Signed-off-by:
-
Gerd Hoffmann authored
Move virtio_gpu_notify() to higher-level functions for virtio_gpu_cmd_resource_flush(), virtio_gpu_cmd_set_scanout() and virtio_gpu_cmd_transfer_to_host_{2d,3d}(). virtio_gpu_primary_plane_update() will notify only once for a series of commands (restores plane update command batching). Signed-off-by: -
Gerd Hoffmann authored
Before we are going to wait for virtqueue entries becoming available call virtio_gpu_notify() to make sure the host has seen everything we've submitted. Signed-off-by:
-
Gerd Hoffmann authored
Drop the virtio_gpu_{disable,enable}_notify(). Add a new virtio_gpu_notify() call instead, which must be called whenever the driver wants make sure the host is notified needed. Drop automatic notification from command submission. Add virtio_gpu_notify() calls after each command query instead. This allows more fine-grained control over host notification and can move around the notify calls in subsequent patches to batch command submissions. With this in place it is also possible to make notification optional for userspace ioctls. Page flip batching goes away (temporarely). v3: - move batching to separate patches. v2: - rebase to latest drm-misc-next. - use "if (!atomic_read())". - add review & test tags. Signed-off-by: -
Maxime Ripard authored
Lyude needs some patches in 5.6-rc2 and we didn't bring drm-misc-next forward yet, so it looks like a good occasion. Signed-off-by: -
Christophe JAILLET authored
A 'h' ismissing in' syncronization' Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Emmanuel Vadot authored
Contributors for this file are : Gerd Hoffmann <kraxel@redhat.com> Maxime Ripard <mripard@kernel.org> Noralf Trønnes <noralf@tronnes.org> Acked-by:
Noralf Trønnes <noralf@tronnes.org> Acked-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
Emmanuel Vadot <manu@FreeBSD.org> Signed-off-by:
-
