Displaying 20 results from an estimated 6000 matches similar to: "[PATCH] drm/nouveau: Remove file nouveau_fbcon.c"
2023 Jan 09
1
[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
2023 Jan 09
1
[PATCH] drm/nouveau: Remove file nouveau_fbcon.c
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
2023 Jan 10
1
[PATCH v2] drm/nouveau: Remove file nouveau_fbcon.c
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>
2020 Feb 06
5
[PATCH 0/4] drm/nouveau: Remove struct nouveau_framebuffer
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
2020 Feb 06
5
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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
2020 Feb 06
2
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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."?
2020 Feb 06
2
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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
2020 Feb 10
2
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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,
2020 Feb 10
2
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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
2016 Jul 12
6
[PATCH] drm/nouveau/fbcon: fix deadlock with FBIOPUT_CON2FBMAP
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
2017 Nov 10
2
[PATCH] Accept 3d controllers and not only VGA controllers.
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,
2017 Dec 03
2
[PATCH] Accept 3d controllers and not only VGA controllers.
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
2015 Jan 05
2
drm/nouveau: dont switch vt on suspend
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
2017 Dec 14
2
[PATCH] Accept 3d controllers and not only VGA controllers.
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
2018 Aug 14
1
[PATCH v7 3/5] drm/nouveau: Fix deadlock with fb_helper with async RPM requests
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
2017 Dec 18
2
[PATCH] Accept 3d controllers and not only VGA controllers.
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
2020 Feb 06
0
[PATCH 2/4] drm/nouveau: Move struct nouveau_framebuffer.vma to struct nouveau_fbdev
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>
---
2016 Jul 13
2
[PATCH] drm/nouveau/fbcon: fix deadlock with FBIOPUT_CON2FBMAP
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
2018 Aug 13
6
[PATCH v7 0/5] Fix connector probing deadlocks from RPM bugs
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()
2018 Aug 13
6
[PATCH v6 0/5] Fix connector probing deadlocks from RPM bugs
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)