similar to: [PATCH] drm/nouveau: by default use low bpp framebuffer on low memory cards

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>

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. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") Cc: Ben Skeggs <bskeggs at redhat.com> Cc:

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

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> ---

This check is useful for drivers that do not have DRIVER_ATOMIC set but have atomic modesetting internally implemented. Wrap the check into a function since this is used in many places and as a bonus, the function name helps to document what the check is for. v2: Change return type to bool (Ville) Move the function drm_atomic.h (Daniel) Fixed comment marker for documentation v3: Included drmP.h

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 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

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,

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. > > 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

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

On 14 December 2017 11:55:35 p.m. GMT+01:00, Ben Skeggs <skeggsb at gmail.com> wrote: >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

This check is useful for drivers that do not have DRIVER_ATOMIC set but have atomic modesetting internally implemented. Wrap the check into a function since this is used in many places and as a bonus, the function name helps to document what the check is for. v2: Change return type to bool (Ville) Move the function drm_atomic.h (Daniel) Suggested-by: Daniel Vetter <daniel.vetter at

This check is useful for drivers that do not have DRIVER_ATOMIC set but have atomic modesetting internally implemented. Wrap the check into a function since this is used in many places and as a bonus, the function name helps to document what the check is for. v2: Change return type to bool (Ville) Move the function drm_atomic.h (Daniel) Fixed comment marker for documentation Suggested-by: Daniel

I've discussed it with Ben and we actually found a better solution. There are just some calls inside those functions which should get NULL checks, nv50_mstm_register_connector and nv50_mstm_destroy_connector. Or at least something similiar so that the code doesn't depent on the fbcon object being there. On Mon, Dec 18, 2017 at 6:30 PM, Josef Larsson <josef.lar at gmail.com> wrote:

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

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

I'm sure I don't need to tell you that fb_helper's locking is a mess. That being said; fb_helper's locking mess can seriously complicate the runtime suspend/resume operations of drivers because it can invoke atomic commits and connector probing from anywhere that calls drm_fb_helper_hotplug_event(). Since most drivers use drm_fb_helper_output_poll_changed() as their

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 the drm_fb_helper_set_suspend call. Based on the > i915 code (which was done for

I'm sure I don't need to tell you that fb_helper's locking is a mess. That being said; fb_helper's locking mess can seriously complicate the runtime suspend/resume operations of drivers because it can invoke atomic commits and connector probing from anywhere that calls drm_fb_helper_hotplug_event(). Since most drivers use drm_fb_helper_output_poll_changed() as their

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 the drm_fb_helper_set_suspend call. Based on the > i915 code (which was done for