similar to: [PATCH] drm/simple-kms: Standardize arguments for callbacks

On Tue, Oct 22, 2019 at 7:16 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi, > > there are two types of callbacks in struct > drm_simple_display_pipe_funcs: functions that are genuine to simple KMS, > and functions that are merely forwarded from another structure (crtc, > plane, etc). > > In the former category are enable(), disable(), check(), and

On Tue, Oct 22, 2019 at 7:16 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi, > > there are two types of callbacks in struct > drm_simple_display_pipe_funcs: functions that are genuine to simple KMS, > and functions that are merely forwarded from another structure (crtc, > plane, etc). > > In the former category are enable(), disable(), check(), and

Hi, there are two types of callbacks in struct drm_simple_display_pipe_funcs: functions that are genuine to simple KMS, and functions that are merely forwarded from another structure (crtc, plane, etc). In the former category are enable(), disable(), check(), and update(). Those should probably receive a simple display pipe as their first argument. In the latter category are mode_valid(),

Hi Am 22.10.19 um 21:03 schrieb Daniel Vetter: > On Tue, Oct 22, 2019 at 7:16 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: >> >> Hi, >> >> there are two types of callbacks in struct >> drm_simple_display_pipe_funcs: functions that are genuine to simple KMS, >> and functions that are merely forwarded from another structure (crtc, >> plane,

Passing the wrong type feels icky, everywhere else we use the pipe as the first parameter. Spotted while discussing patches with Thomas Zimmermann. v2: Make xen compile correctly Acked-By: Thomas Zimmermann <tzimmermann at suse.de> (v1) Cc: Thomas Zimmermann <tzimmermann at suse.de> Cc: Noralf Tr?nnes <noralf at tronnes.org> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc:

Passing the wrong type feels icky, everywhere else we use the pipe as the first parameter. Spotted while discussing patches with Thomas Zimmermann. v2: Make xen compile correctly Acked-By: Thomas Zimmermann <tzimmermann at suse.de> (v1) Cc: Thomas Zimmermann <tzimmermann at suse.de> Cc: Noralf Tr?nnes <noralf at tronnes.org> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc:

Update the cirrus driver to follow current best practices. While the driver's hardware is obsolete, the cirrus driver is still one of the go-to modules to learn about writing a DRM driver. So keep it in good shape. Patches 1 to 3 simplify blitting and convert it to the DRM's current helpers. Patches 4 to 8 replace simple-KMS helpers with DRM's regular atomic helpers. The former are

On Mon, Oct 28, 2019 at 05:10:25PM -0300, Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg at mellanox.com> > > DMA_SHARED_BUFFER can not be enabled by the user (it represents a library > set in the kernel). The kconfig convention is to use select for such > symbols so they are turned on implicitly when the user enables a kconfig > that needs them. > > Otherwise

Many DRM drivers implement an encoder with an empty implementation. This patchset adds drm_simple_encoder_init() and drm_simple_encoder_create(), which can be used by drivers instead. Except for the destroy callback, the simple encoder's implementation is empty. The patchset also converts 4 encoder instances to use the simple-encoder helpers. But there are at least 11 other drivers which can

Hi, On 8/13/20 11:36 AM, Thomas Zimmermann wrote: > GEM object functions deprecate several similar callback interfaces in > struct drm_driver. This patch replaces the per-driver callbacks with > per-instance callbacks in xen. The only exception is gem_prime_mmap, > which is non-trivial to convert. > > Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> > --- >

Now that we've added the hooks that we've needed for this and used them in i915, let's add one more hook (which I could use some feedback on, I'm not sure if it's worth maybe just reworking how we do mode pruning in nouveau instead...) and start using this in our mst ->mode_valid callback to filter out impossible to set modes on MST connectors. Lyude Paul (2):

Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Fixes: f530bc60a30b ("drm/nouveau/disp: move HDMI config into acquire + infoframe methods") Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/gt215.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Just a backport of the two patches for v5.9 that you'll want to apply. The first one was Cc'd to stable, but I forgot to Cc the second one as well. Lyude Paul (2): drm/nouveau/kms/nv50-: Get rid of bogus nouveau_conn_mode_valid() drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid() drivers/gpu/drm/nouveau/nouveau_connector.c | 36 ++++++---------------

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, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually

Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually

On Fri, Sep 13, 2019 at 6:05 PM Lyude Paul <lyude at redhat.com> wrote: > > When drm_connector_helper_funcs->atomic_best_encoder is defined, > ->best_encoder is ignored both by the atomic modesetting helpers. That By both the atomic modesetting helpers and ... (usually "both" implies 2 things) > being said, this hook is completely broken anyway - it always

A call to drm_simple_encoder_init() initializes an encoder without further functionality. It only provides the destroy callback to cleanup the encoder's state. Only few drivers implement more sophisticated encoders than that. Most drivers implement such a simple encoder and can use drm_simple_encoder_init() instead. The patchset converts drivers where the encoder's instance is embedded in

A call to drm_simple_encoder_init() initializes an encoder without further functionality. It only provides the destroy callback to cleanup the encoder's state. Only few drivers implement more sophisticated encoders than that. Most drivers implement such a simple encoder and can use drm_simple_encoder_init() instead. The patchset converts drivers where the encoder's instance is embedded in

On the ThinkPad P71, we have one eDP connector exposed along with 5 DP connectors, resulting in a total of 11 TMDS encoders. Since the GPU on this system is also capable of MST, we create an additional 4 fake MST encoders for each DP port. Unfortunately, we also do this for the eDP port as well, resulting in: 1 eDP port: +1 TMDS encoder +4 DPMST encoders 5 DP ports: +2 TMDS