aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2023-02-07drm/probe_helper: sort out poll_running vs poll_enabledDmitry Baryshkov1-21/+21
There are two flags attemting to guard connector polling: poll_enabled and poll_running. While poll_enabled semantics is clearly defined and fully adhered (mark that drm_kms_helper_poll_init() was called and not finalized by the _fini() call), the poll_running flag doesn't have such clearliness. This flag is used only in drm_helper_probe_single_connector_modes() to guard calling of drm_kms_helper_poll_enable, it doesn't guard the drm_kms_helper_poll_fini(), etc. Change it to only be set if the polling is actually running. Tie HPD enablement to this flag. This fixes the following warning reported after merging the HPD series: Hot plug detection already enabled WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_bridge.c:1257 drm_bridge_hpd_enable+0x94/0x9c [drm] Modules linked in: videobuf2_memops snd_soc_simple_card snd_soc_simple_card_utils fsl_imx8_ddr_perf videobuf2_common snd_soc_imx_spdif adv7511 etnaviv imx8m_ddrc imx_dcss mc cec nwl_dsi gov CPU: 2 PID: 9 Comm: kworker/u8:0 Not tainted 6.2.0-rc2-15208-g25b283acd578 #6 Hardware name: NXP i.MX8MQ EVK (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_bridge_hpd_enable+0x94/0x9c [drm] lr : drm_bridge_hpd_enable+0x94/0x9c [drm] sp : ffff800009ef3740 x29: ffff800009ef3740 x28: ffff000009331f00 x27: 0000000000001000 x26: 0000000000000020 x25: ffff800001148ed8 x24: ffff00000a8fe000 x23: 00000000fffffffd x22: ffff000005086348 x21: ffff800001133ee0 x20: ffff00000550d800 x19: ffff000005086288 x18: 0000000000000006 x17: 0000000000000000 x16: ffff8000096ef008 x15: 97ffff2891004260 x14: 2a1403e194000000 x13: 97ffff2891004260 x12: 2a1403e194000000 x11: 7100385f29400801 x10: 0000000000000aa0 x9 : ffff800008112744 x8 : ffff000000250b00 x7 : 0000000000000003 x6 : 0000000000000011 x5 : 0000000000000000 x4 : ffff0000bd986a48 x3 : 0000000000000001 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000000250000 Call trace: drm_bridge_hpd_enable+0x94/0x9c [drm] drm_bridge_connector_enable_hpd+0x2c/0x3c [drm_kms_helper] drm_kms_helper_poll_enable+0x94/0x10c [drm_kms_helper] drm_helper_probe_single_connector_modes+0x1a8/0x510 [drm_kms_helper] drm_client_modeset_probe+0x204/0x1190 [drm] __drm_fb_helper_initial_config_and_unlock+0x5c/0x4a4 [drm_kms_helper] drm_fb_helper_initial_config+0x54/0x6c [drm_kms_helper] drm_fbdev_client_hotplug+0xd0/0x140 [drm_kms_helper] drm_fbdev_generic_setup+0x90/0x154 [drm_kms_helper] dcss_kms_attach+0x1c8/0x254 [imx_dcss] dcss_drv_platform_probe+0x90/0xfc [imx_dcss] platform_probe+0x70/0xcc really_probe+0xc4/0x2e0 __driver_probe_device+0x80/0xf0 driver_probe_device+0xe0/0x164 __device_attach_driver+0xc0/0x13c bus_for_each_drv+0x84/0xe0 __device_attach+0xa4/0x1a0 device_initial_probe+0x1c/0x30 bus_probe_device+0xa4/0xb0 deferred_probe_work_func+0x90/0xd0 process_one_work+0x200/0x474 worker_thread+0x74/0x43c kthread+0xfc/0x110 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- Reported-by: Laurentiu Palcu <[email protected]> Fixes: c8268795c9a9 ("drm/probe-helper: enable and disable HPD on connectors") Tested-by: Marek Szyprowski <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Acked-by: Laurentiu Palcu <[email protected]> Tested-by: Laurentiu Palcu <[email protected]> Tested-by: Laurent Pinchart <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit d33a54e3991dfce88b4fc6d9c3360951c2c5660d) Signed-off-by: Thomas Zimmermann <[email protected]>
2023-02-07drm/probe_helper: extract two helper functionsDmitry Baryshkov1-27/+41
Extract drm_kms_helper_enable_hpd() and drm_kms_helper_disable_hpd(), two helpers that enable and disable HPD handling on all device's connectors. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit cbf143b282c64e59559cc8351c0b5b1ab4bbdcbe) Signed-off-by: Thomas Zimmermann <[email protected]>
2023-02-07drm/client: fix circular reference counting issueChristian König1-13/+20
We reference dump buffers both by their handle as well as their object. The problem is now that when anybody iterates over the DRM framebuffers and exports the underlying GEM objects through DMA-buf we run into a circular reference count situation. The result is that the fbdev handling holds the GEM handle preventing the DMA-buf in the GEM object to be released. This DMA-buf in turn holds a reference to the driver module which on unload would release the fbdev. Break that loop by releasing the handle as soon as the DRM framebuffer object is created. The DRM framebuffer and the DRM client buffer structure still hold a reference to the underlying GEM object preventing its destruction. Signed-off-by: Christian König <[email protected]> Fixes: c76f0f7cb546 ("drm: Begin an API for in-kernel clients") Cc: <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Tested-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-06drm/i915/huc: Add and use HuC oriented print macrosMichal Wajdeczko1-21/+23
Like we did it for GuC, introduce some helper print macros for HuC to have unified format of messages that also include GT#. While around improve some messages and use %pe if possible. v2: update GSC/PXP timeout message Signed-off-by: Michal Wajdeczko <[email protected]> Cc: John Harrison <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-06drm/bridge: panel: Set orientation on panel_bridge connectorJohn Keeping1-0/+2
Commit 15b9ca1641f0 ("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 <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-06drm/virtio: exbuf->fence_fd unmodified on interrupted waitRyan Neph1-4/+1
An interrupted dma_fence_wait() becomes an -ERESTARTSYS returned to userspace ioctl(DRM_IOCTL_VIRTGPU_EXECBUFFER) calls, prompting to retry the ioctl(), but the passed exbuf->fence_fd has been reset to -1, making the retry attempt fail at sync_file_get_fence(). The uapi for DRM_IOCTL_VIRTGPU_EXECBUFFER is changed to retain the passed value for exbuf->fence_fd when returning anything besides a successful result from the ioctl. Fixes: 2cd7b6f08bc4 ("drm/virtio: add in/out fence support for explicit synchronization") Signed-off-by: Ryan Neph <[email protected]> Reviewed-by: Rob Clark <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-06drm/i915: Fix memory leaks in scatterlistMatt Atwood1-2/+6
This patch fixes memory leaks on error escapes in i915_scatterlist.c Fixes: c3bfba9a2225 ("drm/i915: Check for integer truncation on scatterlist creation") Cc: Chris Wilson <[email protected]> Signed-off-by: Matt Atwood <[email protected]> Reviewed-by: Harish Chegondi <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-06drm/i915/doc: Escape wildcard in method namesBagas Sanjaya1-3/+3
Stephen Rothwell reported htmldocs warnings: Documentation/gpu/i915:64: drivers/gpu/drm/i915/gt/intel_workarounds.c:32: WARNING: Inline emphasis start-string without end-string. Documentation/gpu/i915:64: drivers/gpu/drm/i915/gt/intel_workarounds.c:57: WARNING: Inline emphasis start-string without end-string. Documentation/gpu/i915:64: drivers/gpu/drm/i915/gt/intel_workarounds.c:66: WARNING: Inline emphasis start-string without end-string. Escape wildcards in *_ctx_workarounds_init(), *_gt_workarounds_init(), and *_whitelist_build() to fix above warnings. Link: https://lore.kernel.org/linux-next/[email protected]/ Fixes: 0c3064cf33fbfa ("drm/i915/doc: Document where to implement register workarounds") Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Bagas Sanjaya <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-06drm/i915: Initialize the obj flags for shmem objectsAravind Iddamsetty1-1/+1
Obj flags for shmem objects is not being set correctly. Fixes in setting BO_ALLOC_USER flag which applies to shmem objs as well. v2: Add fixes tag (Tvrtko, Matt A) Fixes: 13d29c823738 ("drm/i915/ehl: unconditionally flush the pages on acquire") Cc: <[email protected]> # v5.15+ Cc: Matthew Auld <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Aravind Iddamsetty <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> [tursulin: Grouped all tags together.] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit bca0d1d3ceeb07be45a51c0fa4d57a0ce31b6aed) Signed-off-by: Rodrigo Vivi <[email protected]>
2023-02-06drm/i915: Move fd_install after last use of fenceRob Clark1-7/+7
Because eb_composite_fence_create() drops the fence_array reference after creation of the sync_file, only the sync_file holds a ref to the fence. But fd_install() makes that reference visable to userspace, so it must be the last thing we do with the fence. Signed-off-by: Rob Clark <[email protected]> Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)") Cc: <[email protected]> # v5.15+ [tursulin: Added stable tag.] Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 960dafa30455450d318756a9896a02727f2639e0) Signed-off-by: Rodrigo Vivi <[email protected]>
2023-02-06drm/i915/fbdev: Implement fb_dirty for intel custom fb helperJouni Högander1-0/+12
After disconnecting damage worker from update logic it's left to fbdev emulation implementation to have fb_dirty function. Currently intel fbdev doesn't have it. This is causing problems to features (PSR, FBC, DRRS) relying on dirty callback. Implement simple fb_dirty callback to deliver notifications about updates in fb console. v4: Add proper Fixes tag and modify commit message v3: Check damage clip v2: Improved commit message and added Fixes tag Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from update logic") Cc: Ville Syrjälä <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Jouni Högander <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 1af546c2cec6e28b6bbe01a4ad0c38e96e54fcb4) Signed-off-by: Rodrigo Vivi <[email protected]>
2023-02-06drm/i915: Don't do the WM0->WM1 copy w/a if WM1 is already enabledVille Syrjälä1-1/+2
Due to a workaround we have to make sure the WM1 watermarks block/lines values are sensible even when WM1 is disabled. To that end we copy those values from WM0. However since we now keep each wm level enabled on a per-plane basis it doesn't seem necessary to do that copy when we already have an enabled WM1 on the current plane. That is, we might be in a situation where another plane can only do WM0 (and thus needs the copy) but the current plane's WM1 is still perfectly valid (ie. fits into the current DDB allocation). Skipping the copy could avoid reprogramming the plane's registers needlessly in some cases. Fixes: a301cb0fca2d ("drm/i915: Keep plane watermarks enabled more aggressively") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Stanislav Lisovskiy <[email protected]> (cherry picked from commit c580c2d27ac8754cc6f01da1d715b7272f5f9cbb) Signed-off-by: Rodrigo Vivi <[email protected]>
2023-02-06drm/i915/hwmon: Enable PL1 power limitAshutosh Dixit1-0/+5
Previous documentation suggested that PL1 power limit is always enabled. However we now find this not to be the case on some platforms (such as ATSM). Therefore enable PL1 power limit during hwmon initialization. Bspec: 51864 v2: Add Bspec reference (Gwan-gyeong) v3: Add Fixes tag Fixes: 99f55efb79114 ("drm/i915/hwmon: Power PL1 limit and TDP setting") Signed-off-by: Ashutosh Dixit <[email protected]> Reviewed-by: Gwan-gyeong Mun <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-06drm/i915: fix up merge with usb-next branchGreg Kroah-Hartman1-1/+1
In the manual fixup of the list_count_nodes() logic in drivers/gpu/drm/i915/gt/intel_execlists_submission.c in the usb-next branch, I missed that the print modifier was incorrect, resulting in loads of build warnings on 32bit systems. Fix this up by using "%su" instead of "%lu". Reported-by: kernel test robot <[email protected]> Fixes: 924fb3ec50f5 ("Merge 6.2-rc7 into usb-next") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-02-06drm/ttm: prevent moving of pinned BOsChristian König6-37/+14
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: Christian König <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-06drm/ttm: stop allocating a dummy resource for pipelined guttingChristian König1-13/+2
That should not be necessary any more when drivers should at least be able to handle a move without a resource. Signed-off-by: Christian König <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Acked-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-06drm/ttm: stop allocating dummy resources during BO creationChristian König1-7/+0
That should not be necessary any more when drivers should at least be able to handle the move without a resource. Signed-off-by: Christian König <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Acked-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-06drm/ttm: clear the ttm_tt when bo->resource is NULLMatthew Auld1-2/+1
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: Matthew Auld <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Nirmoy Das <[email protected]> Signed-off-by: Christian König <[email protected]>
2023-02-06drm/i915/ttm: audit remaining bo->resourceMatthew Auld4-5/+18
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: 516198d317d8 ("drm/i915: audit bo->resource usage v3") Signed-off-by: Matthew Auld <[email protected]> Cc: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Nirmoy Das <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Acked-by: Christian König <[email protected]> Signed-off-by: Christian König <[email protected]>
2023-02-06drm/i915/ttm: fix sparse warningMatthew Auld1-2/+3
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: 516198d317d8 ("drm/i915: audit bo->resource usage v3") Reported-by: kernel test robot <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Nirmoy Das <[email protected]> Acked-by: Christian König <[email protected]> Signed-off-by: Christian König <[email protected]>
2023-02-06drm/i915: Initialize the obj flags for shmem objectsAravind Iddamsetty1-1/+1
Obj flags for shmem objects is not being set correctly. Fixes in setting BO_ALLOC_USER flag which applies to shmem objs as well. v2: Add fixes tag (Tvrtko, Matt A) Fixes: 13d29c823738 ("drm/i915/ehl: unconditionally flush the pages on acquire") Cc: <[email protected]> # v5.15+ Cc: Matthew Auld <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Aravind Iddamsetty <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> [tursulin: Grouped all tags together.] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-06drm/i915: Move fd_install after last use of fenceRob Clark1-7/+7
Because eb_composite_fence_create() drops the fence_array reference after creation of the sync_file, only the sync_file holds a ref to the fence. But fd_install() makes that reference visable to userspace, so it must be the last thing we do with the fence. Signed-off-by: Rob Clark <[email protected]> Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)") Cc: <[email protected]> # v5.15+ [tursulin: Added stable tag.] Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-06Merge 6.2-rc7 into usb-nextGreg Kroah-Hartman49-199/+439
We need the USB fixes in here, and this resolves a merge conflict with the i915 driver as reported in linux-next Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-02-05drm/rockchip: Drop unbalanced obj unrefRob Clark1-3/+0
In the error path, rockchip_drm_gem_object_mmap() is dropping an obj reference that it doesn't own. Fixes: 41315b793e13 ("drm/rockchip: use drm_gem_mmap helpers") Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-05drm/rockchip: avoid duplicate mappings for IOMMU devicesJohn Keeping1-3/+10
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: John Keeping <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-05drm/rockchip: vop: Quiet always-warning AFBC logBrian Norris1-4/+1
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 <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20221031101557.1.Ic1569d394173c1c3016142fee4bb87a09753db94@changeid
2023-02-05drm/rockchip: vop2: add support for the rgb output blockMichael Riesch1-0/+44
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 <[email protected]> Reviewed-by: Sascha Hauer <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-05drm/rockchip: vop2: use symmetric function pair vop2_{create,destroy}_crtcsMichael Riesch1-15/+16
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 <[email protected]> Reviewed-by: Sascha Hauer <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-05drm/rockchip: rgb: add video_port parameter to init functionMichael Riesch3-7/+10
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 <[email protected]> Reviewed-by: Sascha Hauer <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-05drm/rockchip: rgb: embed drm_encoder into rockchip_encoderMichael Riesch1-5/+5
Commit 540b8f271e53 ("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 <[email protected]> Reviewed-by: Sascha Hauer <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-05drm/rockchip: vop2: initialize possible_crtcs properlyMichael Riesch1-3/+4
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: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Michael Riesch <[email protected]> Reviewed-by: Sascha Hauer <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-03drm/i915: Make sure dsm_size has correct granularityNirmoy Das1-1/+1
DSM granularity is 1MB so make sure we stick to that. The address set by firmware in GEN12_DSMBASE in driver initialization doesn't mean "anything above that and until end of lmem is part of DSM". In fact, there may be a few KB that is not part of DSM on the end of lmem. How large is that space is platform-dependent, but since it's always less than the DSM granularity, it can be simplified by simply aligning the size down. v2: replace "1 * SZ_1M" with SZ_1M (Andrzej). v3: reword commit message to explain why the round down is needed (Lucas) Cc: Matthew Auld <[email protected]> Suggested-by: Lucas De Marchi <[email protected]> Signed-off-by: Nirmoy Das <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-03Revert "drm/amd/display: disable S/G display on DCN 3.1.4"Alex Deucher1-0/+1
This reverts commit 9aa15370819294beb7eb67c9dcbf654d79ff8790. This is fixed now so we can re-enable S/G display on DCN 3.1.4. Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-03Revert "Revert "drm/amdgpu/gmc11: enable AGP aperture""Alex Deucher4-9/+12
This reverts commit 1a65327a84db5b9081a51ccb1c562083f59bfcec. This should be resolved so we can re-enable this. Also, the AGP apeture was bring programmed to 0 on MMHUB 3.0.1 since agp_start and end were not being set. Acked-by: Harry Wentland <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-03drm/amd/display: properly handling AGP aperture in vm setupAlex Deucher1-14/+28
Take into account whether or not the AGP aperture is enabled or not when calculating the system aperture. Fixes white screens with DCN 3.1.4. Based on a patch from Yifan Zhang <[email protected]> Cc: Yifan Zhang <[email protected]> Acked-by: Harry Wentland <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-03drm/amd/display: disable S/G display on DCN 3.1.2/3Alex Deucher1-2/+0
Causes flickering or white screens in some configurations. Disable it for now until we can fix the issue. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2352 Cc: [email protected] Cc: [email protected] Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-03drm/amd/display: disable S/G display on DCN 2.1.0Alex Deucher1-1/+0
Causes flickering or white screens in some configurations. Disable it for now until we can fix the issue. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2352 Cc: [email protected] Cc: [email protected] Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-03drm/amdgpu: Remove writing GRBM_GFX_CNTL in RLCG interface under SRIOVYifan Zha1-2/+0
[Why] Accessing GRBM_GFX_CNTL in full access time has risk when VF is doing MMIO attacking. Therefore, VF writing GRBM_GFX_CNTL are blocked by L1 Policy. For RLCG interface, RLCG use SCRATCH_REG2 which is copied from GRBM_GFX_CNTL. [How] Remove writing GRBM_GFX_CNTL in amdgpu_virt_rlcg_reg_rw. v2: Remove directly writing GRBM_GFX_INDEX in amdgpu_virt_rlcg_reg_rw as RLCG interface no need to use it. Signed-off-by: Yifan Zha <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-03drm/amdgpu: always sending PSP messages LOAD_ASD and UNLOAD_TAVitaly Prosyak1-3/+13
We allow sending PSP messages LOAD_ASD and UNLOAD_TA without acquiring a lock in drm_dev_enter during driver unload because we must call drm_dev_unplug as the beginning of unload driver sequence. Added WARNING if other PSP messages are sent without a lock. After this commit, the following commands would work -sudo modprobe -r amdgpu -sudo modprobe amdgpu Signed-off-by: Vitaly Prosyak <[email protected]> Reviewed-by Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-03drm/amd/display: Trivial swizzle-related code clean-upsGuilherme G. Piccoli3-11/+4
This is a very trivial code clean-up related to commit 5468c36d6285 ("drm/amd/display: Filter Invalid 420 Modes for HDMI TMDS"). This commit added a validation on driver probe to prevent invalid TMDS modes, but one of the fake properties (swizzle) ended-up causing a warning on driver probe; was reported here: https://gitlab.freedesktop.org/drm/amd/-/issues/2264. It was fixed by commit a1cbe6916f44 ("drm/amd/display: patch cases with unknown plane state to prevent warning"), but the validation code had a double variable assignment, which we hereby remove. Also, the fix relies in the dcn2{0,1}patch_unknown_plane_state() callbacks, so while at it we took the opportunity to perform a small code clean-up in such routines. Cc: Aurabindo Pillai <[email protected]> Cc: Daniel Wheeler <[email protected]> Cc: Fangzhi Zuo <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Leo Li <[email protected]> Cc: Mark Broadworth <[email protected]> Cc: Melissa Wen <[email protected]> Cc: Rodrigo Siqueira <[email protected]> Cc: Sung Joon Kim <[email protected]> Cc: Swapnil Patel <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Guilherme G. Piccoli <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-03drm/amd/display: reduce else-if to else in dcn32_calculate_dlg_params()Tom Rix1-1/+1
cppcheck reports drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c:1403:76: style: Expression is always true because 'else if' condition is opposite to previous condition at line 1396. [multiCondition] } else if (context->res_ctx.pipe_ctx[i].stream->mall_stream_config.type == SUBVP_PHANTOM) { ^ drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c:1396:69: note: first condition if (context->res_ctx.pipe_ctx[i].stream->mall_stream_config.type != SUBVP_PHANTOM) { ^ drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c:1403:76: note: else if condition is opposite to first condition } else if (context->res_ctx.pipe_ctx[i].stream->mall_stream_config.type == SUBVP_PHANTOM) { It is not necessary to explicitly the check != condition, an else is simplier. Fixes: 238debcaebe4 ("drm/amd/display: Use DML for MALL SS and Subvp allocation calculations") Signed-off-by: Tom Rix <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-03drm/amd/display: reduce else-if to else in dcn10_blank_pixel_data()Tom Rix1-1/+1
checkpatch reports drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:2902:13: style: Expression is always true because 'else if' condition is opposite to previous condition at line 2895. [multiCondition] } else if (blank) { ^ drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:2895:6: note: first condition if (!blank) { ^ drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:2902:13: note: else if condition is opposite to first condition } else if (blank) { It is not necessary to explicitly the check != condition, an else is simplier. Fixes: aa5a57773042 ("drm/amd/display: Vari-bright looks disabled near end of MM14") Signed-off-by: Tom Rix <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-03drm/amdgpu/display: remove duplicate include header in filesye xingchen1-1/+0
opp.h is included more than once. Signed-off-by: ye xingchen <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-03drm/amdgpu: Fix a typo ("boradcast")Jonathan Neuschäfer1-1/+1
Spell it as "broadcast". Signed-off-by: Jonathan Neuschäfer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-03drm/amdgpu: fix memory leak in amdgpu_cs_sync_ringsBert Karwatzki1-1/+4
amdgpu_sync_get_fence deletes the returned fence from the syncobj, so the refcount of fence needs to lowered to avoid a memory leak. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2360 Reviewed-by: Alex Deucher <[email protected]> Tested-by: Mikhail Gavrilov <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Bert Karwatzki <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-03Merge tag 'drm-fixes-2023-02-03' of git://anongit.freedesktop.org/drm/drmLinus Torvalds35-121/+295
Pull drm fixes from Dave Airlie: "A few more fixes this week, a bit more spread out though. We have a bunch of nouveau regression and stabilisation fixes, along with usual amdgpu, and i915. Otherwise just some minor misc ones: dma-fence: - fix signaling bit for private fences panel: - boe-tv101wum-nl6 disable fix nouveau: - gm20b acr regression fix - tu102 scrub status fix - tu102 wait for firmware fix i915: - Fixes for potential use-after-free and double-free - GuC locking and refcount fixes - Display's reference clock value fix amdgpu: - GC11 fixes - DCN 3.1.4 fixes - NBIO 4.3 fix - DCN 3.2 fixes - Properly handle additional cases where DCN is not supported - SMU13 fixes vc4: - fix CEC adapter names ssd130x: - fix display init regression" * tag 'drm-fixes-2023-02-03' of git://anongit.freedesktop.org/drm/drm: (23 commits) drm/amd/display: Properly handle additional cases where DCN is not supported drm/amdgpu: Enable vclk dclk node for gc11.0.3 drm/amd: Fix initialization for nbio 4.3.0 drm/amdgpu: enable HDP SD for gfx 11.0.3 drm/amd/pm: drop unneeded dpm features disablement for SMU 13.0.4/11 drm/amd/display: Reset DMUB mailbox SW state after HW reset drm/amd/display: Unassign does_plane_fit_in_mall function from dcn3.2 drm/amd/display: Adjust downscaling limits for dcn314 drm/amd/display: Add missing brackets in calculation drm/amdgpu: update wave data type to 3 for gfx11 drm/panel: boe-tv101wum-nl6: Ensure DSI writes succeed during disable drm/nouveau/acr/gm20b: regression fixes drm/nouveau/fb/tu102-: fix register used to determine scrub status drm/nouveau/devinit/tu102-: wait for GFW_BOOT_PROGRESS == COMPLETED drm/i915/adlp: Fix typo for reference clock drm/i915: Fix potential bit_17 double-free drm/i915: Fix up locking around dumping requests lists drm/i915: Fix request ref counting during error capture & debugfs dump drm/i915/guc: Fix locking when searching for a hung request drm/i915: Avoid potential vm use-after-free ...
2023-02-03drm/arm/malidp: use sysfs_emit in show function callbackDeepak R Varma1-1/+1
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 <[email protected]> Signed-off-by: Liviu Dudau <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-03drm/i915/dsb: Introduce intel_dsb_finish()Ville Syrjälä3-4/+9
Introduce a function to emits whatever commands we need at the end of the DSB command buffer. For the moment we only do the tail cacheline alignment there, but eventually we might want to eg. emit an interrupt. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Animesh Manna <[email protected]>
2023-02-03drm/i915/dsb: Split intel_dsb_wait() from intel_dsb_commit()Ville Syrjälä3-3/+13
Starting the DSB execution vs. waiting for it stop are two totally different things. Split intel_dsb_wait() from intel_dsb_commit() so that we can eventually allow the DSB to execute asynchronously. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Animesh Manna <[email protected]>
2023-02-03drm/i915/dsb: Pimp debug/error printsVille Syrjälä1-4/+8
Print the crtc/DSB id information to make it clear which DSB engine we're talking about. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Animesh Manna <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.