- 10 Feb, 2023 2 commits
-
-
Maíra Canal authored
vgem_fence_open() instantiates a mutex for a particular fence instance, but never destroys it by calling mutex_destroy() in vgem_fence_close(). So, add the missing mutex_destroy() to guarantee proper resource destruction. Fixes: 40777984 ("drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)") Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230202125517.427976-1-mcanal@igalia.com
-
Christian König authored
Not used by any driver any more. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Tested-by:
-
- 09 Feb, 2023 1 commit
-
-
Somalapuram Amaranath authored
Use amdgpu_bo_in_cpu_visible_vram() instead. v2 (chk): fix test inversion Signed-off-by:
Somalapuram Amaranath <Amaranath.Somalapuram@amd.com> Reviewed-by:
-
- 07 Feb, 2023 1 commit
-
-
John Keeping authored
Commit 15b9ca16 ("drm: Config orientation property if panel provides it") added a helper to set the panel orientation early but only connected this for drm_bridge_connector, which constructs a panel bridge with DRM_BRIDGE_ATTACH_NO_CONNECTOR and creates the connector itself. When the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is not specified and the panel_bridge creates its own connector the orientation is not set unless the panel does it in .get_modes which is too late and leads to a warning splat from __drm_mode_object_add() because the device is already registered. Call the necessary function to set add the orientation property when the connector is created so that it is available before the device is registered. Signed-off-by:
John Keeping <john@metanate.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
- 06 Feb, 2023 10 commits
-
-
Christian König authored
We have checks for this in the individual drivers move callback, but it's probably better to generally forbid that on a higher level. Also stops exporting ttm_resource_compat() since that's not necessary any more after removing the extra checks in vmwgfx. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Christian König authored
That should not be necessary any more when drivers should at least be able to handle a move without a resource. Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130120636.63765-5-matthew.auld@intel.com
-
Christian König authored
That should not be necessary any more when drivers should at least be able to handle the move without a resource. Signed-off-by:
-
Matthew Auld authored
In the next few patches, when initially creating a ttm BO, the bo->resource is NULL, and the driver is then expected to handle the initial dummy move. However, if this is created as a system resource the first ttm_tt we create will always have the clear value set to false. Previously the initial ttm_tt would be created in ttm_bo_validate() with the clear parameter always set to true. Signed-off-by:
Christian König <ckoenig.leichtzumerken@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130101230.25347-3-matthew.auld@intel.comAcked-by:
-
Matthew Auld authored
In the near future TTM will have NULL bo->resource when the object is initially created, plus after calling into pipeline-gutting. Try to handle the remaining cases. In practice NULL bo->resource should be taken to mean swapped-out or purged object. v2 (Andrzej): - Rather make i915_ttm_cpu_maps_iomem() return false with NULL resource. References: 516198d3 ("drm/i915: audit bo->resource usage v3") Signed-off-by:Andrzej Hajda <andrzej.hajda@intel.com> Acked-by:
-
Matthew Auld authored
Sparse complains with: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1066:21: sparse: expected restricted vm_fault_t [assigned] [usertype] ret drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1066:21: sparse: got int Fixes: 516198d3 ("drm/i915: audit bo->resource usage v3") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Stanislaw Gruszka authored
Update according to new dma-buf locking scheme. Remove redundant WARN_ON()'s, dma_buf functions internally have the same warnings already. Signed-off-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by:
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230202092114.2637452-5-stanislaw.gruszka@linux.intel.com
-
Stanislaw Gruszka authored
Avoid below spurious warning: [ 264.844029] DMA-API: intel_vpu 0000:00:0b.0: mapping sg segment longer than device claims to support [len=143360] [max=65536] [ 264.844038] WARNING: CPU: 0 PID: 1254 at kernel/dma/debug.c:1160 debug_dma_map_sg+0x6ca/0xb70 Signed-off-by:
-
Andrzej Kacprowski authored
The VPU_JSM_MSG_CONTEXT_DELETE will remove any resources associated with the SSID, that included any blobs create by the user space application. The command can also remove doorbell registrations, but since this does not work in HW scheduling case, we do not depend on this capability and unregister the doorbells explicitly. Signed-off-by:
Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com> Signed-off-by:
-
Andrzej Kacprowski authored
FW API structures have been updated to fix misaligned structure members. Also changed JSM message header format to account for future improvements. Added explicit check for minimum supported JSM API version. Signed-off-by:
-
- 05 Feb, 2023 15 commits
-
-
Rob Clark authored
In the error path, rockchip_drm_gem_object_mmap() is dropping an obj reference that it doesn't own. Fixes: 41315b79 ("drm/rockchip: use drm_gem_mmap helpers") Signed-off-by:
Rob Clark <robdclark@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230119231734.2884543-1-robdclark@gmail.com
-
John Keeping authored
If a buffer is allocated with alloc_kmap, then it is vmap'd on creation and there is no reason to map it again in rockchip_gem_prime_vmap() when the existing mapping can be used. Signed-off-by:
-
Brian Norris authored
The downstream code from which this was derived didn't ever run through this 'switch' block with non-AFBC formats, but the upstream code does -- we use this function to probe whether a given format is supported. Demote the warning to eliminate this sort of warning seen on every boot: [drm] unsupported AFBC format[3231564e] And make it warn more than once, because if we *actually* care to see what formats we're probing/rejecting and for what reasons, we probably care about more than just the first message. Drop the comment, because one of the two *is* commonly reachable. And lastly, drop the unreachable return; we'd do better to let the compiler complain if we start hitting this unexpectedly. Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Michael Riesch authored
The Rockchip VOP2 features an internal RGB output block, which can be attached any video port of the VOP2. Add support for this output block. Signed-off-by:
Michael Riesch <michael.riesch@wolfvision.net> Reviewed-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Michael Riesch authored
Let the function name vop2_create_crtcs reflect that the function creates multiple CRTCS. Also, use a symmetric function pair to create and destroy the CRTCs and the corresponding planes. Signed-off-by:
-
Michael Riesch authored
The VOP2 driver has more than one video port, hence the hard-coded port id will not work anymore. Add an extra parameter for the video port id to the rockchip_rgb_init function. Signed-off-by:
-
Michael Riesch authored
Commit 540b8f27 ("drm/rockchip: Embed drm_encoder into rockchip_decoder") provides the means to pass the endpoint ID to the VOP2 driver, which sets the interface MUX accordingly. However, this step has not yet been carried out for the RGB output block. Embed the drm_encoder structure into the rockchip_encoder structure and set the endpoint ID correctly. Signed-off-by:
-
Michael Riesch authored
The variable possible_crtcs is only initialized for primary and overlay planes. Since the VOP2 driver only supports these plane types at the moment, the current code is safe. However, in order to provide a future-proof solution, fix the initialization of the variable. Reported-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Johan Jonker authored
Convert analogix_dp-rockchip.txt to yaml. Changed: Add power-domains property File name Signed-off-by:
Johan Jonker <jbx6244@gmail.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Johan Jonker authored
Convert analogix_dp.txt to yaml for use as common document. Changed: Relexed requirements Signed-off-by:
-
Johan Jonker authored
Convert dw_mipi_dsi_rockchip.txt to yaml. Changed: file name requirements Signed-off-by:
-
Johan Jonker authored
Fix clock properties from the common snps,dw-mipi-dsi.yaml file, as they don't match with what is used on the SoCs. Signed-off-by:
-
Johan Jonker authored
The clock-master property is used for the controller and not in the panel, so move it there. Signed-off-by:
-
Johan Jonker authored
Add new converted rockchip,lvds.yaml to grf.yaml file. Prepare for more SoCs with lvds output. Signed-off-by:
-
Johan Jonker authored
Convert rockchip-lvds.txt to YAML. Changed: Add power-domains property. Requirements between PX30 and RK3288 Signed-off-by:
-
- 03 Feb, 2023 1 commit
-
-
Deepak R Varma authored
According to Documentation/filesystems/sysfs.rst, the show() callback function of kobject attributes should strictly use sysfs_emit() instead of sprintf() family functions. Issue identified using the device_attr_show.cocci Coccinelle script. Signed-off-by:
Deepak R Varma <drv@mailo.com> Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/Y9Q5Tt8c9WBDxeyV@ubun2204.myguest.virtualbox.org
-
- 02 Feb, 2023 1 commit
-
-
Maíra Canal authored
Commit b8a926be ("kunit: Introduce KUNIT_EXPECT_MEMEQ and KUNIT_EXPECT_MEMNEQ macros") introduced a new macro to compare blocks of memory and, if the test fails, print the result in a human-friendly format. Therefore, use KUNIT_EXPECT_MEMEQ to compare memory blocks in replacement of the KUNIT_EXPECT_EQ macro. Reviewed-by:
David Gow <davidgow@google.com> Signed-off-by:
-
- 31 Jan, 2023 8 commits
-
-
Stephen Boyd authored
The unprepare sequence has started to fail after moving to panel bridge code in the msm drm driver (commit 007ac026 ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE")). You'll see messages like this in the kernel logs: panel-boe-tv101wum-nl6 ae94000.dsi.0: failed to set panel off: -22 This is because boe_panel_enter_sleep_mode() needs an operating DSI link to set the panel into sleep mode. Performing those writes in the unprepare phase of bridge ops is too late, because the link has already been torn down by the DSI controller in post_disable, i.e. the PHY has been disabled, etc. See dsi_mgr_bridge_post_disable() for more details on the DSI . Split the unprepare function into a disable part and an unprepare part. For now, just the DSI writes to enter sleep mode are put in the disable function. This fixes the panel off routine and keeps the panel happy. My Wormdingler has an integrated touchscreen that stops responding to touch if the panel is only half disabled too. This patch fixes it. And finally, this saves power when the screen is off because without this fix the regulators for the panel are left enabled when nothing is being displayed on the screen. Fixes: 007ac026 ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE") Fixes: a869b9db ("drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel") Cc: yangcong <yangcong5@huaqin.corp-partner.google.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Jitao Shi <jitao.shi@mediatek.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Rob Clark <robdclark@chromium.org> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
-
Arnd Bergmann authored
With extra warnings enabled, gcc warns about two assignments of the same .mmap callback: In file included from drivers/accel/ivpu/ivpu_drv.c:10: include/drm/drm_accel.h:31:27: error: initialized field overwritten [-Werror=override-init] 31 | .mmap = drm_gem_mmap | ^~~~~~~~~~~~ drivers/accel/ivpu/ivpu_drv.c:360:9: note: in expansion of macro 'DRM_ACCEL_FOPS' 360 | DRM_ACCEL_FOPS, | ^~~~~~~~~~~~~~ Remove the unused local assignment. Fixes: e868cc59 ("accel: Add .mmap to DRM_ACCEL_FOPS") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Thomas Zimmermann authored
Backmerging to get v6.2-rc6. Signed-off-by: -
Geert Uytterhoeven authored
The introduction of drivers/accel/ broke alignment, and removed the newline at the end of the file. Fix all of that. Fixes: 35b13763 ("accel/ivpu: Introduce a new DRM driver for Intel VPU") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Oded Gabbay <ogabbay@kernel.org> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Daniel Vetter authored
Due to holidays we started -next with more -fixes in-flight than usual, and people have been asking where they are. Backmerge to get things better in sync. Conflicts: - Tiny conflict in drm_fbdev_generic.c between variable rename and missing error handling that got added. - Conflict in drm_fb_helper.c between the added call to vgaswitcheroo in drm_fb_helper_single_fb_probe and a refactor patch that extracted lots of helpers and incidentally removed the dev local variable. Readd it to make things compile. Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rayyan Ansari authored
Document the new panel node and what it is used for. Signed-off-by:
Rayyan Ansari <rayyan@ansari.sh> Reviewed-by:
-
Rayyan Ansari authored
Parse the width-mm and height-mm devicetree properties of the panel node, and use this to set the DRM Display Mode instead of calculating it based on a hardcoded DPI. Signed-off-by:
-
Arnd Bergmann authored
At the moment, accel drivers can be built-in even with CONFIG_DRM=m, but this causes a link failure: x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_dev_init': ivpu_drv.c:(.text+0x1535): undefined reference to `drmm_kmalloc' x86_64-linux-ld: ivpu_drv.c:(.text+0x1562): undefined reference to `drmm_kmalloc' x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_remove': ivpu_drv.c:(.text+0x1faa): undefined reference to `drm_dev_unregister' x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_probe': ivpu_drv.c:(.text+0x1fef): undefined reference to `__devm_drm_dev_alloc' The problem is that DRM_ACCEL is a 'bool' symbol, so driver that only depend on DRM_ACCEL but not also on DRM do not see the restriction to =m configs. To ensure that each accel driver has an implied dependency on CONFIG_DRM, enclose the entire Kconfig file in an if/endif check. Fixes: 8bf48897 ("drivers/accel: define kconfig and register a new major") Signed-off-by:
-
- 30 Jan, 2023 1 commit
-
-
Rob Clark authored
Once we create the handle, the handle owns the reference. Currently nothing was doing anything with the shmem ptr after the handle was created, but let's change drm_gem_shmem_create_with_handle() to not return the pointer, so-as to not encourage problematic use of this function in the future. As a bonus, it makes the code a bit cleaner. Signed-off-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
