similar to: [PATCH 17/26] drm/nouveau: Use drm_fb_helper_fill_info

This changes the fb name from "nouveaufb" to "nouveaudrmfb". Aside: I wonder whether the in_interrupt() check is good enough for the nouveau acceleration. Cargo-cult says drm_can_sleep() is needed, which isn't actually working if you pick a .config without PREEMPT. For the generic fbdev defio support we've gone with offloading everything to a worker. For the non-accel

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

It's 0. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Inki Dae <inki.dae at samsung.com> Cc: Joonyoung Shim <jy0922.shim at samsung.com> Cc: Seung-Woo Kim <sw0312.kim at samsung.com> Cc: Kyungmin Park <kyungmin.park at samsung.com> Cc: Kukjin Kim <kgene at kernel.org> Cc: Krzysztof Kozlowski <krzk at kernel.org> Cc: Patrik Jakobsson

The buffer object stored in nvbo is also available GEM object in obj[0] of struct drm_framebuffer. Therefore remove nvbo in favor obj[0] and replace all references accordingly. This may require an additional cast. With this change we can already replace nouveau_user_framebuffer_destroy() and nouveau_user_framebuffer_create_handle() with generic GEM helpers. Calls to nouveau_framebuffer_new()

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

KMS drivers really should all be able to restore their display state on resume without fbcon helping out. So make this the default. Since I'm not entirely foolish, make it only a default, which drivers can still override. That way when the inevitable regression report happens I can fix things up with a one-liner plus FIXME comment that someone should fix up the suspend/resume code in that

Hello. I had some trouble building nouveau drm for linux-2.6.35-rc1. I investigated a bit why it failed and noticed that the fb_info-structure had changed slightly. Since I do not have any previous knowledge of how the driver works, I'm not certain if this is a proper fix, but it seems to work. I'm curious if there's a better solution, or if my solution breaks in all other cases.

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

When the fbcon object is initialized, but nouveau_fbcon_create is not called, we run into a NULL pointer access within nouveau_fbcon_create when unloading nouveau. The call to drm_fb_helper_funcs.fb_probe is deferred until there is a display for real since 4.14, that's why fbcon->helper.fb is still not set. Signed-off-by: Karol Herbst <kherbst at redhat.com> ---

KMS drivers really should all be able to restore their display state on resume without fbcon helping out. So make this the default. Since I'm not entirely foolish, make it only a default, which drivers can still override. That way when the inevitable regression report happens I can fix things up with a one-liner plus FIXME comment that someone should fix up the suspend/resume code in that

(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

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

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

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

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

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.

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

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