Displaying 20 results from an estimated 4000 matches similar to: "[PATCH v2] drm/nouveau: Remove file nouveau_fbcon.c"
2023 Jan 09
1
[PATCH] drm/nouveau: Remove file nouveau_fbcon.c
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:
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
2018 Aug 13
0
[PATCH v6 3/5] drm/nouveau: Fix deadlock with fb_helper with async RPM requests
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
2018 Aug 13
0
[PATCH v7 3/5] drm/nouveau: Fix deadlock with fb_helper with async RPM requests
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
2020 Feb 06
0
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
After its cleanup, struct nouveau_framebuffer is only a wrapper around
struct drm_framebuffer. Use the latter directly.
Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 26 +++++++++++------------
drivers/gpu/drm/nouveau/nouveau_display.c | 14 ++++++------
drivers/gpu/drm/nouveau/nouveau_display.h | 12 +----------
2020 Feb 06
0
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
(Re-sending to list rather than just to James)
Is this format modifier information not stored, or otherwise worth
storing, directly in the nouveau_bo object associated with the
framebuffer? I'm not particularly knowledgeable on the topic, but there
already seem to exist some fields with very similar names in nouveau_bo.
Best,
Roy
On 06/02/2020 15:17, James Jones wrote:
> Note I'm
2020 Feb 06
0
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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."? 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
2020 Feb 07
0
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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, but if these
cleanup patches are taken, only v4 will work.
Thanks,
-James
On 2/6/20 8:45 AM, James Jones
2020 Feb 06
0
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
So ... for Vulkan, the API requires allocating VA before declaring
what goes into that VA (e.g. an image or data). I believe our plan for
that was to move all this into userspace, which would allocate VA and
then just tell the kernel "make VA range X have memtype Y". At that
point, nouveau_bo would be left mainly for compat as well as for
things like framebuffer backing.
James, in what
2020 Feb 10
0
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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 conflicts with your series, but should make them structurally
>> compatible.
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
2020 Feb 10
0
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
On Tue, 11 Feb 2020 at 09:17, James Jones <jajones at nvidia.com> wrote:
>
> 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
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
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
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>
---
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,
2016 Jul 12
0
[PATCH] drm/nouveau/fbcon: fix deadlock with FBIOPUT_CON2FBMAP
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
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