- 16 Apr, 2023 9 commits
-
-
Thomas Zimmermann authored
The hardware for gma500 is different from the rest, as it uses stolen framebuffer memory that is not available via PCI BAR. The regular PCI removal helper cannot detect the framebuffer, while the non-PCI helper misses possible conflicting VGA devices (i.e., a framebuffer or text console). Gma500 therefore calls both helpers to catch all cases. It's confusing as it implies that there's something about the PCI device that requires ownership management. The relationship between the PCI device and the VGA devices is non-obvious. At worst, readers might assume that calling two functions for clearing aperture ownership is a bug in the driver. Hence, move the PCI removal helper's code for VGA functionality into a separate function and call this function from gma500. Documents the purpose of each call to aperture helpers. The change contains comments and example code form the discussion at [1]. v5: * fix grammar in gma500 comment (Javier) Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.kernel.org/project/dri-devel/patch/20230404201842.567344-1-daniel.vetter@ffwll.ch/ # 1 Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230406132109.32050-10-tzimmermann@suse.de
-
Daniel Vetter authored
vga_default_device really is supposed to cover all corners, at least for x86. Additionally checking for rom shadowing should be redundant, because the bios/fw only does that for the boot vga device. If this turns out to be wrong, then most likely that's a special case which should be added to the vgaarb code, not replicated all over. Patch motived by changes to the aperture helpers, which also have this open code in a bunch of places, and which are all removed in a clean-up series. This function here is just for selecting the default fbdev device for fbcon, but I figured for consistency it might be good to throw this patch in on top. Note that the shadow rom check predates vgaarb, which was only wired up in commit 88674088 ("x86: Use vga_default_device() when determining whether an fb is primary"). That patch doesn't explain why we still fall back to the shadow rom check. v4: - fix commit message style (i.e., commit 1234 ("...")) - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Daniel Vetter authored
Instead of calling aperture_remove_conflicting_devices() to remove the conflicting devices, just call to aperture_detach_devices() to detach the device that matches the same PCI BAR / aperture range. Since the former is just a wrapper of the latter plus a sysfb_disable() call, and now that's done in this function but only for the primary devices. This fixes a regression introduced by commit ee7a69aa ("fbdev: Disable sysfb device registration when removing conflicting FBs"), where we remove the sysfb when loading a driver for an unrelated pci device, resulting in the user losing their efifb console or similar. Note that in practice this only is a problem with the nvidia blob, because that's the only gpu driver people might install which does not come with an fbdev driver of it's own. For everyone else the real gpu driver will restore a working console. Also note that in the referenced bug there's confusion that this same bug also happens on amdgpu. But that was just another amdgpu specific regression, which just happened to happen at roughly the same time and with the same user-observable symptoms. That bug is fixed now, see https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15 Note that we should not have any such issues on non-pci multi-gpu issues, because I could only find two such cases: - SoC with some external panel over spi or similar. These panel drivers do not use drm_aperture_remove_conflicting_framebuffers(), so no problem. - vga+mga, which is a direct console driver and entirely bypasses all this. For the above reasons the cc: stable is just notionally, this patch will need a backport and that's up to nvidia if they care enough. v2: - Explain a bit better why other multi-gpu that aren't pci shouldn't have any issues with making all this fully pci specific. v3 - polish commit message (Javier) v4: - Fix commit message style (i.e., commit 1234 ("...")) - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Fixes: ee7a69aa ("fbdev: Disable sysfb device registration when removing conflicting FBs") Tested-by:
Aaron Plattner <aplattner@nvidia.com> Reviewed-by:
-
Daniel Vetter authored
With the preceding patches it's become defunct. Also I'm about to add a different boolean argument, so it's better to keep the confusion down to the absolute minimum. v2: Since the hypervfb patch got droppped (it's only a pci device for gen1 vm, not for gen2) there is one leftover user in an actual driver left to touch. v4: - fixes to commit message - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Signed-off-by:
-
Daniel Vetter authored
A few reasons for this: - It's really the only one where this matters. I tried looking around, and I didn't find any non-pci vga-compatible controllers for x86 (since that's the only platform where we had this until a few patches ago), where a driver participating in the aperture claim dance would interfere. - I also don't expect that any future bus anytime soon will not just look like pci towards the OS, that's been the case for like 25+ years by now for practically everything (even non non-x86). - Also it's a bit funny if we have one part of the vga removal in the pci function, and the other in the generic one. v2: Rebase. v4: - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Signed-off-by:
-
Daniel Vetter authored
Otherwise it's a bit silly, and we might throw out the driver for the screen the user is actually looking at. I haven't found a bug report for this case yet, but we did get bug reports for the analog case where we're throwing out the efifb driver. v2: Flip the check around to make it clear it's a special case for kicking out the vgacon driver only (Thomas) v4: - fixes to commit message - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Link: https://bugzilla.kernel.org/show_bug.cgi?id=216303Signed-off-by:
-
Daniel Vetter authored
Only really pci devices have a business setting this - it's for figuring out whether the legacy vga stuff should be nuked too. And with the preceding two patches those are all using the pci version of this. Which means for all other callers primary == false and we can remove it now. v2: - Reorder to avoid compile fail (Thomas) - Include gma500, which retained it's called to the non-pci version. v4: - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
-
Daniel Vetter authored
Since vgaarb has been promoted to be a core piece of the pci subsystem we don't have to open code random guesses anymore, we actually know this in a platform agnostic way, and there's no need for an x86 specific hack. See also commit 1d38fe6e ("PCI/VGA: Move vgaarb to drivers/pci") This should not result in any functional change, and the non-x86 multi-gpu pci systems are probably rare enough to not matter (I don't know of any tbh). But it's a nice cleanup, so let's do it. There's been a few questions on previous iterations on dri-devel and irc: - fb_is_primary_device() seems to be yet another implementation of this theme, and at least on x86 it checks for both vga_default_device OR rom shadowing. There shouldn't ever be a case where rom shadowing gives any additional hints about the boot vga device, but if there is then the default vga selection in vgaarb should probably be fixed. And not special-case checks replicated all over. - Thomas also brought up that on most !x86 systems fb_is_primary_device() returns 0, except on sparc/parisc. But these 2 special cases are about platform specific devices and not pci, so shouldn't have any interactions. - Furthermore fb_is_primary_device() is a bit a red herring since it's only used to select the right fbdev driver for fbcon, and not for the fw handover dance which the aperture helpers handle. At least for x86 we might want to look into unifying them, but that's a separate thing. v2: Extend commit message trying to summarize various discussions. v4: - make the test for the primary device easier to read (Javier) - fix commit message style (i.e., commit 1234 ("...")) - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Signed-off-by:
-
Daniel Vetter authored
This one nukes all framebuffers, which is a bit much. In reality gma500 is igpu and never shipped with anything discrete, so there should not be any difference. v2: Unfortunately the framebuffer sits outside of the pci bars for gma500, and so only using the pci helpers won't be enough. Otoh if we only use non-pci helper, then we don't get the vga handling, and subsequent refactoring to untangle these special cases won't work. It's not pretty, but the simplest fix (since gma500 really is the only quirky pci driver like this we have) is to just have both calls. v4: - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Signed-off-by:
-
- 15 Apr, 2023 1 commit
-
-
Dan Carpenter authored
The devm_drm_dev_alloc() function returns error pointers. It never returns NULL. Fix the check. Fixes: c87e859c ("drm/imx/lcdc: Implement DRM driver for imx25") Signed-off-by:
Dan Carpenter <error27@gmail.com> Reviewed-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
- 14 Apr, 2023 2 commits
-
-
Fabio Estevam authored
i.MX6SX has a single LVDS port and share a similar LDB_CTRL register layout with i.MX8MP and i.MX93. There is no LVDS CTRL register on the i.MX6SX, so only write to this register on the appropriate SoCs. Add support for the i.MX6SX LDB. Tested on a imx6sx-sdb board with a Hannstar HSD100PXN1 LVDS panel and also on a custom i.MX6SX-based board. Signed-off-by:
Fabio Estevam <festevam@denx.de> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Fabio Estevam authored
i.MX6SX has a single LVDS port and share a similar LDB_CTRL register layout with i.MX8MP and i.MX93. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
- 12 Apr, 2023 3 commits
-
-
Maíra Canal authored
Use drmm_mode_config_init() instead of drm_mode_config_init(), as it allows us to assure that the resource will be properly cleaned. Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230116205800.1266227-2-mcanal@igalia.com
-
Maíra Canal authored
Use drmm_crtc_init_with_planes() instead of drm_crtc_init_with_planes() to get rid of the explicit destroy hook in struct drm_crtc_funcs. Signed-off-by:
-
Daniel Vetter authored
Otherwise core changes don't get noticed by the right people. I noticed this because a patch set from Jagan Teki seems to have fallen through the cracks. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Acked-by:
Jagan Teki <jagan@amarulasolutions.com> [narmstrong: fixed ordering & Daniel's SoB] Signed-off-by:
-
- 11 Apr, 2023 7 commits
-
-
Tom Rix authored
clang with W=1 reports drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:56:35: error: unused function 'vmw_overlay' [-Werror,-Wunused-function] static inline struct vmw_overlay *vmw_overlay(struct drm_device *dev) ^ This function is not used, so remove it. Signed-off-by:Tom Rix <trix@redhat.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230321182414.1826372-1-trix@redhat.com
-
Martin Krastev authored
Legacy Display Unit (LDU) fb dirty support used a custom fb dirty callback. Latter handled only the DIRTYFB IOCTL presentation path but not the ADDFB2/PAGE_FLIP/RMFB IOCTL path, common for Wayland compositors. Get rid of the custom callback in favor of drm_atomic_helper_dirtyfb and unify the handling of the presentation paths inside of vmw_ldu_primary_plane_atomic_update. This also homogenizes the fb dirty callbacks across all DUs: LDU, SOU and STDU. Signed-off-by:
Martin Krastev <krastevm@vmware.com> Reviewed-by:
Maaz Mombasawala <mombasawalam@vmware.com> Fixes: 2f5544ff ("drm/vmwgfx: Use atomic helper function for dirty fb IOCTL") Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by:
-
Zack Rusin authored
virtualbox implemented an incomplete version of the svga device which they decided to drop soon after the initial release. The device was always broken in various ways and never supported by vmwgfx. vmwgfx should refuse to load on those configurations but currently drm has no way of reloading fbdev when the specific pci driver refuses to load, which would leave users without a usable fb. Instead of refusing to load print an error and disable a bunch of functionality that virtualbox never implemented to at least get fb to work on their setup. Signed-off-by:
-
Martin Krastev authored
This internal helper handles a type of mksstat event counter which is currently unused. Remove the routine to avoid compile warnings. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
ruanjinjie authored
The symbol is not used outside of the file, so mark it static. Fixes the following warning: ./drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c:591:1: warning: symbol 'gv100_disp_core_mthd_base' was not declared. Should it be static? Signed-off-by:
ruanjinjie <ruanjinjie@huawei.com> Reviewed-by:
Karol Herbst <kherbst@redhat.com> Signed-off-by:
-
Ben Dooks authored
Make ga100_mc_device static as it isn't exported, to fix the following sparse warning: drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c:51:1: warning: symbol 'ga100_mc_device' was not declared. Should it be static? Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Signed-off-by:
-
Tom Rix authored
smatch reports drivers/gpu/drm/vc4/vc4_irq.c:60:1: warning: symbol 'render_wait' was not declared. Should it be static? This variable is not used so remove it. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230406151203.1953812-1-trix@redhat.com
-
- 07 Apr, 2023 2 commits
-
-
Javier Martinez Canillas authored
The driver doesn't use simple-KMS helpers to set a simple display pipeline but only the drm_simple_encoder_init() function to initialize an encoder. That helper is just a wrapper of drm_encoder_init(), but passing a struct drm_encoder_funcs that sets the .destroy handler to drm_encoder_cleanup(). Since the <drm/drm_simple_kms_helper.h> header is only included for this helper and because the connector is initialized with drm_connector_init() as well, do the same for the encoder and drop the header include. Signed-off-by:
-
Javier Martinez Canillas authored
This helper is just a wrapper that calls drm_connector_cleanup(), there's no need to have another level of indirection. Signed-off-by:
-
- 06 Apr, 2023 16 commits
-
-
Asahi Lina authored
After a job is pushed into the queue, it is owned by the scheduler core and may be freed at any time, so we can't write nor read the submit timestamp after that point. Fixes oopses observed with the drm/asahi driver, found with kASAN. Signed-off-by:
Asahi Lina <lina@asahilina.net> Link: https://lore.kernel.org/r/20230406-scheduler-uaf-2-v1-1-972531cf0a81@asahilina.netReviewed-by:
Luben Tuikov <luben.tuikov@amd.com> Signed-off-by:
-
Jagan Teki authored
Samsung MIPI DSIM bridge can be found on Exynos and NXP's i.MX8M Mini/Nano/Plus SoCs. Convert exynos_dsim.txt to yaml. Used the example node from exynos5433.dtsi instead of the one used in the legacy exynos_dsim.txt. Signed-off-by:
Rob Herring <robh@kernel.org>
-
Thomas Zimmermann authored
Move code from ad-hoc fbdev callbacks into DRM client functions and remove the old callbacks. The functions instruct the client to poll for changed output or restore the display. The DRM core calls both, the old callbacks and the new client helpers, from the same places. The new functions perform the same operation as before, so there's no change in functionality. Replace all code that initializes or releases fbdev emulation throughout the driver. Instead initialize the fbdev client by a single call to omapdrm_fbdev_setup() after omapdrm has registered its DRM device. As in most drivers, omapdrm's fbdev emulation now acts like a regular DRM client. The fbdev client setup consists of the initial preparation and the hot-plugging of the display. The latter creates the fbdev device and sets up the fbdev framebuffer. The setup performs display hot-plugging once. If no display can be detected, DRM probe helpers re-run the detection on each hotplug event. A call to drm_dev_unregister() releases the client automatically. No further action is required within omapdrm. If the fbdev framebuffer has been fully set up, struct fb_ops.fb_destroy implements the release. For partially initialized emulation, the fbdev client reverts the initial setup. v2: * init drm_client in this patch (Tomi) * don't handle non-atomic modesetting (Tomi) Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Thomas Zimmermann authored
The DRM device stores a pointer to the fbdev helper. Remove struct omap_drm_private.fbdev, which contains the same value. No functional changes. v2: * don't clear dev->fb_helper unnecessarily (Tomi) * include omap_fbdev.h in omap_fbdev.c (kernel test robot) Signed-off-by:
-
Thomas Zimmermann authored
Fbdev's framebuffer stores a pointer to the GEM object. Remove struct omap_fbdev.bo, which contains the same value. No functional changes. v2: * fix commit message (Tomi) Signed-off-by:
-
Thomas Zimmermann authored
Fbdev's struct fb_helper stores a pointer to the framebuffer. Remove struct omap_fbdev.fb, which contains the same value. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Include <linux/of.h> to get the contained declarations. No functional changes. Signed-off-by:
-
Maíra Canal authored
Before commit bc0d7fde ("drm: vkms: Supports to the case where primary plane doesn't match the CRTC"), the composition was executed on top of the primary plane. Therefore, the primary plane needed to cover the entire CRTC. After commit bc0d7fde, this is no longer necessary, as the composition is now executed on top of the CRTC. Then, allow the primary plane to be positioned in such a way that it doesn't cover the entire CRTC. This patch was tested with the vkms IGT testlist and all tests passed successfully. Moreover, the test igt@kms_universal_plane@universal-plane-pageflip-windowed-pipe-A used to fail and now is passing. Signed-off-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
-
Maíra Canal authored
Before commit bc0d7fde ("drm: vkms: Supports to the case where primary plane doesn't match the CRTC"), the composition was executed on top of the primary plane. Therefore, the primary plane needed to be visible and full screen. After commit bc0d7fde, this is no longer necessary, as the composition is now executed on top of the CRTC. Then, remove the conditional expression that forced the primary plane to be visible and full screen. This allows vkms to accept non-null framebuffers when the CRTC is disabled. This patch was tested with the vkms IGT testlist and all tests passed successfully. Moreover, the tests igt@kms_universal_plane@universal-plane-pipe-a-functional and igt@kms_universal_plane@disable-primary-vs-flip-pipe-a used to fail and now are passing. Signed-off-by:
-
Thomas Hellström authored
When swapping in, or under memory pressure ttm_tt_populate() may sleep for a substantiable amount of time. Allow interrupts during the sleep. This will also allow us to inject -EINTR errors during swapin in upcoming patches. Also avoid returning VM_FAULT_OOM, since that will confuse the core mm, making it print out a confused message and retrying the fault. Return VM_FAULT_SIGBUS also under OOM conditions. Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230404200650.11043-4-thomas.hellstrom@linux.intel.com
-
Thomas Hellström authored
When swapping out, we will split multi-order pages both in order to move them to the swap-cache and to be able to return memory to the swap cache as soon as possible on a page-by-page basis. Reduce the page max order to the system PMD size, as we can then be nicer to the system and avoid splitting gigantic pages. Looking forward to when we might be able to swap out PMD size folios without splitting, this will also be a benefit. v2: - Include all orders up to the PMD size (Christian König) v3: - Avoid compilation errors for architectures with special PFN_SHIFTs Signed-off-by:
-
Thomas Hellström authored
When hitting an error, the error path forgot to unmap dma mappings and could call set_pages_wb() on already uncached pages. Fix this by introducing a common ttm_pool_free_range() function that does the right thing. v2: - Simplify that common function (Christian König) v3: - Rename that common function to ttm_pool_free_range() (Christian König) Fixes: d099fc8f ("drm/ttm: new TT backend allocation pool v3") Cc: Christian König <christian.koenig@amd.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Jeffrey Hugo authored
Add MAINTAINERS entry for the Qualcomm Cloud AI 100 driver. Signed-off-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by:
Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by:
Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by:
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Reviewed-by:
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Acked-by:
Oded Gabbay <ogabbay@kernel.org> Signed-off-by:
-
Jeffrey Hugo authored
Now that we have all the components of a minimum QAIC which can boot and run an AIC100 device, add the infrastructure that allows the QAIC driver to be built. Signed-off-by:
-
Pranjal Ramajor Asha Kanojiya authored
Some of the MHI channels for an AIC100 device need to be routed to userspace so that userspace can communicate directly with QSM. The MHI bus does not support this, and while the WWAN subsystem does (for the same reasons), AIC100 is not a WWAN device. Also, MHI is not something that other accelerators are expected to share, thus an accel subsystem function that meets this usecase is unlikely. Create a QAIC specific MHI userspace shim that exposes these channels. Start with QAIC_SAHARA which is required to boot AIC100 and is consumed by the kickstart application as documented in aic100.rst Each AIC100 instance (currently, up to 16) in a system will create a chardev for QAIC_SAHARA. This chardev will be found as /dev/<mhi instance>_QAIC_SAHARA For example - /dev/mhi0_QAIC_SAHARA Signed-off-by:
-
Jeffrey Hugo authored
Add the datapath component that manages BOs and submits them to running workloads on the qaic device via the dma_bridge hardware. This allows QAIC clients to interact with their workloads (run inferences) via the following ioctls along with mmap(): DRM_IOCTL_QAIC_CREATE_BO DRM_IOCTL_QAIC_MMAP_BO DRM_IOCTL_QAIC_ATTACH_SLICE_BO DRM_IOCTL_QAIC_EXECUTE_BO DRM_IOCTL_QAIC_PARTIAL_EXECUTE_BO DRM_IOCTL_QAIC_WAIT_BO DRM_IOCTL_QAIC_PERF_STATS_BO Signed-off-by:
-
