- 13 Jan, 2023 24 commits
-
-
Thomas Zimmermann authored
Acquire ownership of the firmware scanout buffer by calling Linux' aperture helpers. Remove the use of struct fb_info.apertures and do not set FBINFO_MISC_FIRMWARE; both of which previously configured buffer ownership. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-14-tzimmermann@suse.de
-
Thomas Zimmermann authored
Move the palette array into struct offb_par and allocate both via framebuffer_alloc(), as intended by fbdev. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Acquire ownership of the firmware scanout buffer by calling Linux' aperture helpers. Remove the use of struct fb_info.apertures and do not set FBINFO_MISC_FIRMWARE; both of which previously configured buffer ownership. Signed-off-by:
-
Thomas Zimmermann authored
The efifb_par structure holds the palette for efifb. It will also be useful for storing the device's aperture range. Signed-off-by:
-
Thomas Zimmermann authored
Generic fbdev drivers use the apertures field in struct fb_info to control ownership of the framebuffer memory and graphics device. Do not set the values in mdpy-fb. Signed-off-by:
-
Thomas Zimmermann authored
Generic fbdev drivers use the apertures field in struct fb_info to control ownership of the framebuffer memory and graphics device. Do not set the values in hyperv-fb. Signed-off-by:
Michael Kelley <mikelley@microsoft.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-9-tzimmermann@suse.de
-
Thomas Zimmermann authored
Generic fbdev drivers use the apertures field in struct fb_info to control ownership of the framebuffer memory and graphics device. Do not set the values in clps711x-fb. Signed-off-by:
-
Thomas Zimmermann authored
The apertures field in struct fb_info is not used by DRM drivers. Do not allocate it. Signed-off-by:
-
Thomas Zimmermann authored
Generic fbdev drivers use the apertures field in struct fb_info to control ownership of the framebuffer memory and graphics device. Do not set the values in radeon. Signed-off-by:
-
Thomas Zimmermann authored
Generic fbdev drivers use the apertures field in struct fb_info to control ownership of the framebuffer memory and graphics device. Do not set the values in i915. Signed-off-by:
-
Thomas Zimmermann authored
Generic fbdev drivers use the apertures field in struct fb_info to control ownership of the framebuffer memory and graphics device. Do not set the values in gma500. Signed-off-by:
-
Thomas Zimmermann authored
This reverts commit ae128786. Always free the console font when deinitializing the framebuffer console. Subsequent framebuffer consoles will then use the default font. Rely on userspace to load any user-configured font for these consoles. Commit ae128786 ("fbcon: don't lose the console font across generic->chip driver switch") was introduced to work around losing the font during graphics-device handover. [1][2] It kept a dangling pointer with the font data between loading the two consoles, which is fairly adventurous hack. It also never covered cases when the other consoles, such as VGA text mode, where involved. The problem has meanwhile been solved in userspace. Systemd comes with a udev rule that re-installs the configured font when a console comes up. [3] So the kernel workaround can be removed. This also removes one of the two special cases triggered by setting FBINFO_MISC_FIRMWARE in an fbdev driver. Tested during device handover from efifb and simpledrm to radeon. Udev reloads the configured console font for the new driver's terminal. Signed-off-by:
-
Thomas Zimmermann authored
Fix coding style. No functional changes. Signed-off-by:
-
Cai Huoqing authored
Commit 399516ab ("MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers") marked these drivers obsolete 7 years ago. And the mesa UMD of this drm driver already in deprecated list in the link: https://docs.mesa3d.org/systems.html 3dfx Glide-->driver/gpu/drm/tdfx Matrox-->driver/gpu/drm/mga Intel i810-->driver/gpu/drm/i810 S3 Savage-->drivers/gpu/drm/savage ATI Rage 128->drivers/gpu/drm/r128 Silicon Integrated Systems->drivers/gpu/drm/sis It's time to remove these drivers. Signed-off-by:
Cai Huoqing <cai.huoqing@linux.dev> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Dave Airlie <airlied@redhat.com> Acked-by:
-
Cai Huoqing authored
Commit 399516ab ("MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers") marked these drivers obsolete 7 years ago. And the mesa UMD of this drm driver already in deprecated list in the link: https://docs.mesa3d.org/systems.html 3dfx Glide-->driver/gpu/drm/tdfx Matrox-->driver/gpu/drm/mga Intel i810-->driver/gpu/drm/i810 S3 Savage-->drivers/gpu/drm/savage ATI Rage 128->drivers/gpu/drm/r128 Silicon Integrated Systems->drivers/gpu/drm/sis VIA Unichrome->drivers/gpu/drm/via It's time to remove these drivers. Signed-off-by:
-
Cai Huoqing authored
Add comments to avoid removing DRM_LEGACY config menu, because DRM_LEGACY menu could list other legacy drivers. Signed-off-by:
-
Cai Huoqing authored
Commit 399516ab ("MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers") marked via driver obsolete 7 years ago. And the mesa UMD of this drm driver already in deprecated list in the link: https://docs.mesa3d.org/systems.html VIA Unichrome->drivers/gpu/drm/via It's time to remove this driver. Signed-off-by:
-
Cai Huoqing authored
Commit 399516ab ("MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers") marked tdfx driver obsolete 7 years ago. And the mesa UMD of this drm driver already in deprecated list in the link: https://docs.mesa3d.org/systems.html 3dfx Glide-->driver/gpu/drm/tdfx It's time to remove this driver. Signed-off-by:
-
Cai Huoqing authored
Commit 399516ab ("MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers") marked sis driver obsolete 7 years ago. And the mesa UMD of this drm driver already in deprecated list in the link: https://docs.mesa3d.org/systems.html Silicon Integrated Systems->drivers/gpu/drm/sis It's time to remove this driver. Signed-off-by:
-
Cai Huoqing authored
Commit 399516ab ("MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers") marked savage driver obsolete 7 years ago. And the mesa UMD of this drm driver already in deprecated list in the link: https://docs.mesa3d.org/systems.html S3 Savage-->drivers/gpu/drm/savage It's time to remove this driver. Signed-off-by:
-
Cai Huoqing authored
Commit 399516ab ("MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers") marked r128 driver obsolete 7 years ago. And the mesa UMD of this drm driver already in deprecated list in the link: https://docs.mesa3d.org/systems.html ATI Rage 128->drivers/gpu/drm/r128 It's time to remove this driver. Signed-off-by:
-
Cai Huoqing authored
Commit 399516ab ("MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers") marked mga driver obsolete 7 years ago. And the mesa UMD of this drm driver already in deprecated list in the link: https://docs.mesa3d.org/systems.html Matrox-->driver/gpu/drm/mga It's time to remove this driver. Signed-off-by:
-
Cai Huoqing authored
Commit 399516ab ("MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers") marked i810 driver obsolete 7 years ago. And the mesa UMD of this drm driver already in deprecated list in the link: https://docs.mesa3d.org/systems.html Intel i810-->driver/gpu/drm/i810 It's time to remove this driver. Signed-off-by:
-
Thomas Zimmermann authored
Remove nouveau's support for legacy contexts and buffers. It was required by libdrm earlier than 2.4.33, released in March 2012. A previous attempt in 2013 to remove the functionality [1] had to be reverted [2] as there were still users left. Libdrm 2.4.33 is now almost 11 years old and it is time for userspace to move on. With the nouveau code gone, we can also remove the driver-feature bit DRIVER_KMS_LEGACY_CONTEXT. Signed-off-by:
Karol Herbst <kherbst@redhat.com> Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7c510133d93dd6f15ca040733ba7b2891ed61fd1 # 1 Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095 # 2 Link: https://patchwork.freedesktop.org/patch/msgid/20230112133858.17087-1-tzimmermann@suse.de
-
- 12 Jan, 2023 1 commit
-
-
Maíra Canal authored
With commit 359c6649 ("drm/gem: Implement shadow-plane {begin, end}_fb_access with vmap"), the behavior of the shadow-plane helpers changed and the vunmap is now performed at the end of the current pageflip, instead of the end of the following pageflip. By performing the vunmap at the end of the current pageflip, invalid memory is accessed by the vkms during the plane composition, as the data is being unmapped before being used, as reported by the following warning: [ 275.866047] BUG: unable to handle page fault for address: ffffb382814e8002 [ 275.866055] #PF: supervisor read access in kernel mode [ 275.866058] #PF: error_code(0x0000) - not-present page [ 275.866061] PGD 1000067 P4D 1000067 PUD 110a067 PMD 46e3067 PTE 0 [ 275.866066] Oops: 0000 [#1] PREEMPT SMP PTI [ 275.866070] CPU: 2 PID: 49 Comm: kworker/u8:2 Not tainted 6.1.0-rc6-00018-gb357e7ac-dirty #54 [ 275.866074] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 [ 275.866076] Workqueue: vkms_composer vkms_composer_worker [vkms] [ 275.866084] RIP: 0010:XRGB8888_to_argb_u16+0x5c/0xa0 [vkms] [ 275.866092] Code: bf 56 0a 0f af 56 70 48 8b 76 28 01 ca 49 83 f8 02 41 b9 01 00 00 00 4d 0f 43 c8 48 01 f2 48 83 c2 02 31 f6 66 c7 04 f0 ff ff <0f> b6 0c b2 89 cf c1 e7 08 09 cf 66 89 7c f0 02 0f b6 4c b2 ff 89 [ 275.866095] RSP: 0018:ffffb382801b7db0 EFLAGS: 00010246 [ 275.866098] RAX: ffff896336ace000 RBX: ffff896310e293c0 RCX: 0000000000000000 [ 275.866101] RDX: ffffb382814e8002 RSI: 0000000000000000 RDI: ffffb382801b7de8 [ 275.866103] RBP: 0000000000001400 R08: 0000000000000280 R09: 0000000000000280 [ 275.866105] R10: 0000000000000010 R11: ffffffffc011d990 R12: ffff896302a1ece0 [ 275.866107] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000080008001 [ 275.866109] FS: 0000000000000000(0000) GS:ffff89637dd00000(0000) knlGS:0000000000000000 [ 275.866112] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 275.866114] CR2: ffffb382814e8002 CR3: 0000000003bb4000 CR4: 00000000000006e0 [ 275.866120] Call Trace: [ 275.866123] <TASK> [ 275.866124] compose_active_planes+0x1c4/0x380 [vkms] [ 275.866132] vkms_composer_worker+0x9f/0x130 [vkms] [ 275.866139] process_one_work+0x1c0/0x370 [ 275.866160] worker_thread+0x221/0x410 [ 275.866164] ? worker_clr_flags+0x50/0x50 [ 275.866167] kthread+0xe1/0x100 [ 275.866172] ? kthread_blkcg+0x30/0x30 [ 275.866176] ret_from_fork+0x22/0x30 [ 275.866181] </TASK> [ 275.866182] Modules linked in: vkms [ 275.866186] CR2: ffffb382814e8002 [ 275.866191] ---[ end trace 0000000000000000 ]--- Therefore, introduce again prepare_fb and cleanup_fb functions to the vkms, which were previously removed on commit b43e2ec0 ("drm/vkms: Let shadow-plane helpers prepare the plane's FB"). Fixes: 359c6649 ("drm/gem: Implement shadow-plane {begin, end}_fb_access with vmap") Acked-by:
Maíra Canal <mcanal@igalia.com> Signed-off-by:
Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230111131304.106039-1-mcanal@igalia.com
-
- 11 Jan, 2023 15 commits
-
-
Daniel Vetter authored
The documentation for struct drm_minor already states this, but that's not always that easy to find. Also due to historical reasons we still have the minor-centric interfaces (like drm_debugfs_create_files), but since this is now getting fixed we can put a few more pointers in place as to how this should be done ideally. Note that debugfs isn't there yet for all cases (debugfs files on kms objects like crtc/connector aren't supported, neither debugfs files with full fops), so the debugfs side of this is still rather aspirational and more for new users than converting everything existing. todo.rst covers the additional work needed already. Motivated by some discussion with Rodrigo on irc about how drm/xe should lay out its sysfs interfaces. v2: Make the debugfs situation clearer in the commit message, but don't elaborate more in the actual kerneldoc to avoid distracting from the main message around sysfs (Jani) Also fix some typos. Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Melissa Wen <mwen@igalia.com> Reviewed-by:
Maxime Ripard <maxime@cerno.tech> Acked-by:
Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Wambui Karuga <wambui.karugax@gmail.com> Cc: Maíra Canal <mcanal@igalia.com> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Melissa Wen <mwen@igalia.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230109164604.3860862-1-daniel.vetter@ffwll.ch
-
Javier Martinez Canillas authored
There is a macro for this already in the <drm/drm_mipi_dsi.h> header, use that instead and delete the custom DSI write macro defined in the driver. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230107191822.3787147-14-javierm@redhat.com
-
Javier Martinez Canillas authored
There is a macro for this already in the <drm/drm_mipi_dsi.h> header, use that instead and delete the custom DSI write macro defined in the driver. Signed-off-by:
-
Javier Martinez Canillas authored
There is a macro for this already in the <drm/drm_mipi_dsi.h> header, use that instead and delete the custom DSI write macro defined in the driver. Signed-off-by:
Guido Günther <agx@sigxcpu.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230107191822.3787147-12-javierm@redhat.com
-
Javier Martinez Canillas authored
There is a macro for this already in the <drm/drm_mipi_dsi.h> header, use that instead and delete the custom DSI write macro defined in the driver. Signed-off-by:
-
Javier Martinez Canillas authored
There is a macro for this already in the <drm/drm_mipi_dsi.h> header, use that instead and delete the custom DSI write macro defined in the driver. Signed-off-by:
-
Javier Martinez Canillas authored
There is a macro for this already in the <drm/drm_mipi_dsi.h> header, use that instead and delete the custom DSI write macro defined in the driver. Signed-off-by:
-
Javier Martinez Canillas authored
There are macros for these already in the <drm/drm_mipi_dsi.h> header, use that instead and delete the custom DSI write macros defined in the driver. Signed-off-by:
-
Javier Martinez Canillas authored
There is a macro for this already in the <drm/drm_mipi_dsi.h> header, use that instead and delete the custom DSI write macro defined in the driver. Signed-off-by:
-
Javier Martinez Canillas authored
There is a macro for this already in the <drm/drm_mipi_dsi.h> header, use that instead and delete the custom DSI write macro defined in the driver. Signed-off-by:
-
Javier Martinez Canillas authored
There is a macro for this already in the <drm/drm_mipi_dsi.h> header, use that instead and delete the custom DSI write macro defined in the driver. Signed-off-by:
-
Javier Martinez Canillas authored
There is a macro for this already in the <drm/drm_mipi_dsi.h> header, use that instead and delete the custom DSI write macro defined in the driver. Signed-off-by:
-
Javier Martinez Canillas authored
There are macros for these already in the <drm/drm_mipi_dsi.h> header, use that instead and delete the custom DSI write macros defined in the driver. Signed-off-by:
-
Javier Martinez Canillas authored
There are macros for these already in the <drm/drm_mipi_dsi.h> header, use that instead and delete the custom DSI write macros defined in the driver. Signed-off-by:
-
Abel Vesa authored
Add an eDP panel entry for IVO M133NW4J. Due to lack of documentation, use the delay_200_500_p2e100 timings like some other IVO entries for now. Signed-off-by:
Abel Vesa <abel.vesa@linaro.org> Reviewed-by:
Johan Hovold <johan+linaro@kernel.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
