similar to: [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_helper_connector_set_property. The only special case is nouveau which used one function for both pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2 vtables. But amounts to exactly the same. What is rather strange here is how few drivers set this up, I suspect the earlier patch

Op 25-07-17 om 10:01 schreef Daniel Vetter: > It's dead code, the core handles all this directly now. This also > allows us to unexport drm_atomic_helper_connector_set_property. > > The only special case is nouveau which used one function for both > pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2 > vtables. But amounts to exactly the same. > > What

These days drm core checks function pointers everywhere before calling them. So we can drop a bunch of dummy functions now. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_display.c | 50 --------------------------------------- 1 file changed, 50 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index

Doesn't do anything with atomic. Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch> Cc: Dave Airlie <airlied at redhat.com> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: virtualization at lists.linux-foundation.org Cc: spice-devel at lists.freedesktop.org --- drivers/gpu/drm/qxl/qxl_display.c | 1 - 1 file changed, 1 deletion(-) diff --git

These days drm core checks function pointers everywhere before calling them. So we can drop a bunch of dummy functions now. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_display.c | 50 --------------------------------------- 1 file changed, 50 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index

Hello, This patch series aims at replacing all dummy ->best_encoder() implementations where we have a 1:1 relationship between encoders and connectors. The core already provides the drm_atomic_helper_best_encoder() function which is taking the first encoder attached to the connector (after making sure only one encoder was attached to the connector), but it's not automatically used, and

Hello, This patch series aims at replacing all dummy ->best_encoder() implementations where we have a 1:1 relationship between encoders and connectors. The core already provides the drm_atomic_helper_best_encoder() function which is taking the first encoder attached to the connector (after making sure only one encoder was attached to the connector), but it's not automatically used, and

For all outputs except DSI we have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com> --- drivers/gpu/drm/msm/edp/edp_connector.c | 10 ----------

For nouveau, while the GPU is guaranteed to be on when a hotplug has been received, the same assertion does not hold true if a connector probe has been started by userspace without having had received a sysfs event. So ensure that any connector probing keeps the GPU alive for the duration of the probe by introducing drm_helper_probe_single_connector_modes_with_rpm(). It's the same as

Hello, This patch series aims at replacing all dummy ->best_encoder() implementations where we have a 1:1 relationship between encoders and connectors. The core already provides the drm_atomic_helper_best_encoder() function which is taking the first encoder attached to the connector (after making sure only one encoder was attached to the connector), but it's not automatically used, and

Hello, This patch series aims at replacing all dummy ->best_encoder() implementations where we have a 1:1 relationship between encoders and connectors. The core already provides the drm_atomic_helper_best_encoder() function which is taking the first encoder attached to the connector (after making sure only one encoder was attached to the connector), but it's not automatically used, and

While the GPU is guaranteed to be on when a hotplug has been received, the same assertion does not hold true if a connector probe has been started by userspace without having had received a sysfs event. So ensure that any connector probing keeps the GPU alive for the duration of the probe. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Karol Herbst <karolherbst at gmail.com> Cc:

Conversion to atomic modesetting, step three. Wire up atomic helpers. Switch planes to atomic. We are late to the party, the transitional helpers are gone, so this can't be splitted into smaller steps any more. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/bochs/bochs_fbdev.c | 3 ++ drivers/gpu/drm/bochs/bochs_kms.c | 70

This is a complicated one. Essentially, there's currently a problem in the MST core that hasn't really caused any issues that we're aware of (emphasis on "that we're aware of"): locking. When we go through and probe the link addresses and path resources in a topology, we hold no locks when updating ports with said information. The members I'm referring to in

This is a trimmed down version of https://patchwork.freedesktop.org/series/46637/ with all of the review comments addressed. The last version of this series had fixes for the i2c and DP aux busses to ensure that the GPU would be turned on whenever anything tried to access the i2c/aux busses. Unfortunately: one of the fixes apparently contained some very incorrect usage of Linux's runtime PM

We have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementation and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com> --- drivers/gpu/drm/omapdrm/omap_connector.c | 8 -------- 1 file changed, 8 deletions(-)

This fixes quite a number of runtime PM bugs I found that have been causing some pretty nasty issues such as: - Deadlocking on boot - Connector probing potentially not working while the GPU is in runtime suspend - i2c char dev not working while the GPU is in runtime suspend - aux char dev not working while the GPU is in runtime suspend There's definitely more parts of nouveau that need

When reading EDID from firmware file, the nouveau driver can not setup it's native_mode like when reading EDID from hardware. Add this callback to allow driver to update their native_mode. Signed-off-by: Alexander Stein <alexanders83 at web.de> --- This might be a fast forward hack. I'm wondering if there is a better way to achieve the same. The actual problem is that

Currently the way that we prevent userspace from performing new modesets on MST connectors that have just been destroyed is rather broken. There's nothing in the actual DRM DP MST topology helpers that checks whether or not a connector still exists, instead each DRM driver does this on it's own, usually by returning NULL from the best_encoder callback which in turn, causes the atomic

Currently the way that we prevent userspace from performing new modesets on MST connectors that have just been destroyed is rather broken. There's nothing in the actual DRM DP MST topology helpers that checks whether or not a connector still exists, instead each DRM driver does this on it's own, usually by returning NULL from the best_encoder callback which in turn, causes the atomic