similar to: [PATCH] drm/nouveau: Remove file nouveau_fbcon.c

On Mon, Jan 9, 2023 at 9:06 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") > converted nouveau to generic fbdev emulation. Also remove the internal > implementation from the driver. No functional changes. Looking at 4a16dd9d18a0, it appears to have removed this file already. I guess it

Hi Am 09.01.23 um 15:15 schrieb Alex Deucher: > On Mon, Jan 9, 2023 at 9:06 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: >> >> Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") >> converted nouveau to generic fbdev emulation. Also remove the internal >> implementation from the driver. No functional changes. > > Looking

Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") converted nouveau to generic fbdev emulation. The driver's internal implementation later got accidentally restored during a merge commit. Remove the file from the driver. No functional changes. v2: * point Fixes tag to merge commit (Alex) Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>

All fields in struct nouveau_framebuffer appear to be obsolete. The data structure can be replaced by struct drm_framebuffer entirely. Patch 1 removes several unused fields from struct nouveau_framebuffer. Patch 2 moves the field vma to struct nouveau_fbdev. The information in vma is only relevant for fbdev emulation, and as such he field is only used there. Patch 3 removes nvbo from struct

Note I'm adding some fields to nouveau_framebuffer in the series "drm/nouveau: Support NVIDIA format modifiers." I sent out v3 of that yesterday. It would probably still be possible to avoid them by re-extracting the relevant data from the format modifier on the fly when needed, but it is simpler and likely less error-prone with the wrapper struct. Thanks, -James On 2/6/20

Yes, that's certainly viable. If that's the general preference in direction, I'll rework that patches to do so. Thanks, -James On 2/6/20 7:49 AM, Thomas Zimmermann wrote: > Hi James > > Am 06.02.20 um 16:17 schrieb James Jones: >> Note I'm adding some fields to nouveau_framebuffer in the series >> "drm/nouveau: Support NVIDIA format modifiers."?

The format modifiers, when present, override the equivalent field in the BO. Right now, that's probably not particularly useful. However, as nouveau interfaces evolve towards the HW capabilities and add support for newer graphics APIs, saying an entire BO has a singular layout becomes less meaningful, so I suspect those fields will be effectively deprecated in favor of the

On Sat, 8 Feb 2020 at 07:10, James Jones <jajones at nvidia.com> wrote: > > I've sent out a v4 version of the format modifier patches which avoid > caching values in the nouveau_framebuffer struct. It will have a few > trivial conflicts with your series, but should make them structurally > compatible. > > I'm fine with either v3 or v4 of my series personally,

On 2/10/20 12:25 AM, Thomas Zimmermann wrote: > Hi > > Am 10.02.20 um 09:20 schrieb Ben Skeggs: >> On Sat, 8 Feb 2020 at 07:10, James Jones <jajones at nvidia.com> wrote: >>> >>> I've sent out a v4 version of the format modifier patches which avoid >>> caching values in the nouveau_framebuffer struct. It will have a few >>> trivial

The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called while nouveau was runtime suspended, a deadlock would occur due to nouveau_fbcon_set_suspend also trying to obtain console_lock(). Fix this by delaying the drm_fb_helper_set_suspend call. Based on the i915 code (which was done for performance reasons though). Cc: Chris Wilson <chris at chris-wilson.co.uk> Cc: Daniel

Accept 3d controllers and not only VGA controllers. According to Ilia Mirkin, the VGA controller check should be removed. This makes it possible to use external connectors on a docking station (40A5) for a Thinkpad P51. (See Bug 101778). lspci example: 01:00.0 3D controller: NVIDIA Corporation GM107GLM [Quadro M1200 Mobile] (rev a2) Also include safe-guards to avoid NULL dereferencing of fbcon,

Sure, I can easily split it into two commits, but I would like to have an OK on the actual code changes before splitting the patch. Best regards, Josef Larsson On 2017-11-11 01:05, Tobias Klausmann wrote: > > On 11/10/17 7:49 PM, Josef Larsson wrote: >> Accept 3d controllers and not only VGA controllers. According to Ilia >> Mirkin, >> the VGA controller check should be

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at ubuntu.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 3ed12a8cfc91..a4a586807903 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -370,6 +370,7 @@ nouveau_fbcon_create(struct drm_fb_helper *helper, ret = -ENOMEM; goto

On 14 December 2017 at 23:45, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > On 12/3/17 8:56 PM, Josef Larsson wrote: >> >> Sure, I can easily split it into two commits, but I would like to have >> an OK on the actual code changes before splitting the patch. I'm not actually sure this is a good idea still. As I recall, part of the purpose

On Mon, Aug 13, 2018 at 03:16:43PM -0400, Lyude Paul wrote: > I'm sure I don't need to tell you that fb_helper's locking is a mess. Uh, loaded statement :-) Especially since we've just reworked all the fbdev locking to untangle it from drm_modeset locking. What's still a mess about it? It's documented, and very clearly wrapped around all the drm_modeset locks. If

Without a NULL pointer safe-guard patch, I get a kernel oops when I plug in external displays in my docking station, (exactly the same issue as https://bugs.freedesktop.org/show_bug.cgi?id=101778) and without removing or modifying the check (accepting PCI_CLASS_DISPLAY_3D in the if-condition), I cannot use external displays through my docking station. This is on an optimus system where I use

The vma field of struct nouveau_framebuffer is a special field for the the accelerated fbdev console. Hence there's at most one single instance for the active console. Moving it into struct nouveau_fbdev makes struct nouveau_framebuffer slightly smaller and brings it closer to struct drm_framebuffer. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> ---

On Wed, Jul 13, 2016 at 11:54:49AM +0200, Daniel Vetter wrote: > On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > > while nouveau was runtime suspended, a deadlock would occur due to > > nouveau_fbcon_set_suspend also trying to obtain console_lock(). > > > > Fix this by delaying

Latest version of https://patchwork.freedesktop.org/series/46815/ , with one small change re: ilia Lyude Paul (5): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend() drm/nouveau: Fix deadlock with fb_helper with async RPM requests drm/nouveau: Use pm_runtime_get_noresume() in connector_detect()

Latest version of https://patchwork.freedesktop.org/series/46815/ with some significant improvements: - I finally figured out a clean way to do this entirely with runtime PM helpers, no avoiding grabbing refs required! - Since this new method removes the need for a lot of the other changes I made (although we probably still want those changes, but not for fixing these deadlocks)