kernel/linux.git/drivers/gpu/drm/bochs, branch v5.8.10

drm/drm_fb_helper: fix fbdev with sparc64

2020-07-27T14:47:46+00:00

Recent kernels have been reported to panic using the bochs_drm framebuffer under qemu-system-sparc64 which was bisected to commit 7a0483ac4ffc ("drm/bochs: switch to generic drm fbdev emulation"). The backtrace indicates that the shadow framebuffer copy in drm_fb_helper_dirty_blit_real() is trying to access the real framebuffer using a virtual address rather than use an IO access typically implemented using a physical (ASI_PHYS) access on SPARC. The fix is to replace the memcpy with memcpy_toio() from io.h. memcpy_toio() uses writeb() where the original fbdev code used sbus_memcpy_toio(). The latter uses sbus_writeb(). The difference between writeb() and sbus_memcpy_toio() is that writeb() writes bytes in little-endian, where sbus_writeb() writes bytes in big-endian. As endian does not matter for byte writes they are the same. So we can safely use memcpy_toio() here. Note that this only fixes bochs, in general fbdev helpers still have issues with mixing up system memory and __iomem space. Fixing that will require a lot more work. v3: - Improved changelog (Daniel) - Added FIXME to fbdev_use_iomem (Daniel) v2: - Added missing __iomem cast (kernel test robot) - Made changelog readable and fix typos (Mark) - Add flag to select iomem - and set it in the bochs driver Signed-off-by: Sam Ravnborg Reported-by: Mark Cave-Ayland Reported-by: kernel test robot Tested-by: Mark Cave-Ayland Reviewed-by: Daniel Vetter Cc: Mark Cave-Ayland Cc: Thomas Zimmermann Cc: Gerd Hoffmann Cc: "David S. Miller" Cc: sparclinux@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200709193016.291267-1-sam@ravnborg.org Link: https://patchwork.freedesktop.org/patch/msgid/20200725191012.GA434957@ravnborg.org

drm/bochs: Remove explicit drm_connector_register

2020-04-28T14:14:17+00:00

This is leftovers from the old drm_driver->load callback upside-down issues. It doesn't do anything for not-hotplugged connectors since drm_dev_register takes care of that. Acked-by: Gerd Hoffmann Acked-by: Sam Ravnborg Signed-off-by: Daniel Vetter Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org Link: https://patchwork.freedesktop.org/patch/msgid/20200415074034.175360-60-daniel.vetter@ffwll.ch

Merge drm/drm-next into drm-misc-next

2020-04-17T06:12:22+00:00

Backmerging required to pull topic/phy-compliance. Signed-off-by: Thomas Zimmermann

Merge v5.6 into drm-next

2020-03-31T05:15:47+00:00

msm needed rc6, so I just went and merged release (msm has been in drm-next outside of this tree) Signed-off-by: Dave Airlie

drm/bochs: Drop explicit drm_mode_config_cleanup

2020-03-26T14:46:09+00:00

Instead rely on the automatic clean, for which we just need to check that drm_mode_config_init succeeded. To avoid an inversion in the cleanup we also have to move the dev_private allocation over to drmm_kzalloc. This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Acked-by: Gerd Hoffmann Acked-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Thomas Zimmermann Cc: Laurent Pinchart Signed-off-by: Daniel Vetter Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-29-daniel.vetter@ffwll.ch

drm/bochs: Remove leftover drm_atomic_helper_shutdown

2020-03-26T14:45:59+00:00

Small mistake that crept into commit 81da8c3b8d3df6f05b11300b7d17ccd1f3017fab Author: Gerd Hoffmann Date: Tue Feb 11 14:52:18 2020 +0100 drm/bochs: add drm_driver.release callback where drm_atomic_helper_shutdown was left in both places. The ->release callback really shouldn't touch hardware. Acked-by: Gerd Hoffmann Cc: Gerd Hoffmann Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-28-daniel.vetter@ffwll.ch

drm/bochs: downgrade pci_request_region failure from error to warning

2020-03-13T14:34:19+00:00

Shutdown of firmware framebuffer has a bunch of problems. Because of this the framebuffer region might still be reserved even after drm_fb_helper_remove_conflicting_pci_framebuffers() returned. Don't consider pci_request_region() failure for the framebuffer region as fatal error to workaround this issue. Reported-by: Marek Marczykowski-Górecki Signed-off-by: Gerd Hoffmann Acked-by: Sam Ravnborg Link: http://patchwork.freedesktop.org/patch/msgid/20200313084152.2734-1-kraxel@redhat.com

drm/bochs: add drm_driver.release callback.

2020-02-12T09:24:08+00:00

Call bochs_unload via drm_driver.release to make sure we release stuff when it is safe to do so. Use drm_dev_{enter,exit,unplug} to avoid touching hardware after device removal. Tidy up here and there. v4: add changelog. v3: use drm_dev_*(). v2: move hardware deinit to pci_remove(). Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20200211135218.22871-1-kraxel@redhat.com

drm/bochs: deinit bugfix

2020-02-10T11:54:32+00:00

Check whenever mode_config was actually properly initialized before trying to clean it up. Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20200207124348.21641-1-kraxel@redhat.com

drm/bochs: Clear struct drm_connector_funcs.dpms

2020-02-10T08:23:50+00:00

Atomic modesetting doesn't use struct drm_connector_funcs.dpms and the set function, drm_helper_connector_dpms(), wouldn't support it anyway. So keep the pointer to NULL. Signed-off-by: Thomas Zimmermann Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200207141602.4760-1-tzimmermann@suse.de