summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2023-02-08drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT listMatt Roper
The UNSLICE_UNIT_LEVEL_CLKGATE register programmed by this workaround has 'BUS' style reset, indicating that it does not lose its value on engine resets. Furthermore, this register is part of the GT forcewake domain rather than the RENDER domain, so it should not be impacted by RCS engine resets. As such, we should implement this on the GT workaround list rather than an engine list. Bspec: 19219 Fixes: 3551ff928744 ("drm/i915/gen11: Moving WAs to rcs_engine_wa_init()") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230201222831.608281-2-matthew.d.roper@intel.com
2023-02-08drm/i915/pvc: Annotate two more workaround/tuning registers as MCRMatt Roper
XEHPC_LNCFMISCCFGREG0 and XEHPC_L3SCRUB are both in MCR register ranges on PVC (with HALFBSLICE and L3BANK replication respectively), so they should be explicitly declared as MCR registers and use MCR-aware workaround handlers. The workarounds/tuning settings should still be applied properly on PVC even without the MCR annotation, but readback verification on CONFIG_DRM_I915_DEBUG_GEM builds could potentitally give false positive "workaround lost on load" warnings on parts fused such that a unicast read targets a terminated register instance. Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230201222831.608281-1-matthew.d.roper@intel.com
2023-02-08drm/i915: Fix VBT DSI DVO port handlingVille Syrjälä
Turns out modern (icl+) VBTs still declare their DSI ports as MIPI-A and MIPI-C despite the PHYs now being A and B. Remap appropriately to allow the panels declared as MIPI-C to work. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 118b5c136c04da705b274b0d39982bb8b7430fc5) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-02-08drm/i915/bios: set default backlight controller indexJani Nikula
With backlight controller set to -1 in intel_panel_init_alloc() to distinguish uninitialized values, and controller later being set only if it's present in VBT, we can end up with -1 for the controller: [drm:intel_bios_init_panel [i915]] VBT backlight PWM modulation frequency 200 Hz, active high, min brightness 0, level 255, controller 4294967295 There's no harm if it happens on platforms that ignore controller due to only one backlight controller being present, like on VLV above, but play it safe. Fixes: bf38bba3e7d6 ("drm/i915: Try to use the correct power sequencer intiially on bxt/glk") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207111626.1839645-1-jani.nikula@intel.com
2023-02-08drm/i915/pxp: fix __le64 access to get rid of sparse warningJani Nikula
__le64 and friends should go through the cpu_to_* and *_to_cpu accessors: drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35: warning: incorrect type in assignment (different base types) drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35: expected restricted __le64 [assigned] [usertype] huc_base_address drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35: got unsigned long long [assigned] [usertype] huc_phys_addr Cc: Tomas Winkler <tomas.winkler@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Tomas Winkler <tomas.winkler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207124026.2105442-4-jani.nikula@intel.com
2023-02-08drm/i915/gt: add sparse lock annotation to avoid warningsJani Nikula
Annotate intel_gt_mcr_lock() and intel_gt_mcr_unlock() to fix sparse warnings: drivers/gpu/drm/i915/gt/intel_gt_mcr.c:397:9: warning: context imbalance in 'intel_gt_mcr_lock' - wrong count at exit drivers/gpu/drm/i915/gt/intel_gt_mcr.c:412:6: warning: context imbalance in 'intel_gt_mcr_unlock' - unexpected unlock Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207124026.2105442-1-jani.nikula@intel.com
2023-02-08drm/i915/uncore: cast iomem to avoid sparse warningJani Nikula
drmm_add_action_or_reset() is unaware of __iomem and the pointer needs to be a plain void *. Cast __iomem away and back while the pointer goes through drmm. drivers/gpu/drm/i915/intel_uncore.c:2463:17: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/intel_uncore.c:2463:17: expected void volatile [noderef] __iomem *addr drivers/gpu/drm/i915/intel_uncore.c:2463:17: got void *regs drivers/gpu/drm/i915/intel_uncore.c:2494:16: warning: incorrect type in argument 3 (different address spaces) drivers/gpu/drm/i915/intel_uncore.c:2494:16: expected void *data drivers/gpu/drm/i915/intel_uncore.c:2494:16: got void [noderef] __iomem *regs Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207124026.2105442-2-jani.nikula@intel.com
2023-02-08drm/i915/dmc: drop "ucode" from function namesJani Nikula
The ucode part in the init, fini, suspend and resume function names is just unnecessary. Drop it. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207110619.1821992-1-jani.nikula@intel.com
2023-02-08drm/i915: Pick the backlight controller based on VBT on ICP+Ville Syrjälä
Use the second backlight controller on ICP+ if the VBT asks us to do so. On pre-MTP we also check the chicken bit to make sure the pins have been correctly muxed by the firmware. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-08drm/i915: Populate encoder->devdata for DSI on icl+Ville Syrjälä
We now have some eDP+DSI dual panel systems floating around where the DSI panel is the secondary LFP and thus needs to consult "panel type 2" in VBT in order to locate all the other panel type dependant stuff correctly. To that end we need to pass in the devdata to intel_bios_init_panel_late(), otherwise it'll just assume we want the primary panel type. So let's try to just populate the vbt.ports[] stuff and encoder->devdata for icl+ DSI panels as well. We can't do this on older platforms as there we risk a DSI port aliasing with a HDMI/DP port, which is a totally legal thing as the DSI ports live in their own little parallel universe. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-08drm/i915: Fix VBT DSI DVO port handlingVille Syrjälä
Turns out modern (icl+) VBTs still declare their DSI ports as MIPI-A and MIPI-C despite the PHYs now being A and B. Remap appropriately to allow the panels declared as MIPI-C to work. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-07drm/etnaviv: show number of NN cores in GPU debugfs infoLucas Stach
For NPUs the number of NN cores is a interesting property, which is useful to show in the debugfs information. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
2023-02-07drm/etnaviv: export client GPU usage statistics via fdinfoLucas Stach
This exposes a accumulated GPU active time per client via the fdinfo infrastructure. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
2023-02-07drm/etnaviv: allocate unique ID per drm_fileLucas Stach
Allows to easily track if several fd are pointing to the same execution context due to being dup'ed. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
2023-02-07drm/scheduler: track GPU active time per entityLucas Stach
Track the accumulated time that jobs from this entity were active on the GPU. This allows drivers using the scheduler to trivially implement the DRM fdinfo when the hardware doesn't provide more specific information than signalling job completion anyways. [Bagas: Append missing colon to @elapsed_ns] Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
2023-02-07drm/i915/pcode: Give the punit time to settle before fatally failingAravind Iddamsetty
During module load the punit might still be busy with its booting routines. During this time we try to communicate with it but we fail because we don't receive any feedback from it and we return immediately with a -EINVAL fatal error. At this point the driver load is "dramatically" aborted. The following error message notifies us about it. i915 0000:4d:00.0: drm_WARN_ON_ONCE(timeout_base_ms > 3) It would be enough to wait a little in order to give the punit the chance to come up bright and shiny, ready to interact with the driver. Wait up 10 seconds for the punit to settle and complete any outstanding transactions upon module load. If it still fails try again with a longer timeout, 180s, 3 minutes. If it still fails then return -EPROBE_DEFER, in order to give the punit a second chance. Even if these timers might look long, we should consider that the punit, depending on the platforms, might need long times to complete its routines. Besides we want to try anything possible to move forward before deciding to abort the driver's load. The issue has been reported in: https://gitlab.freedesktop.org/drm/intel/-/issues/7814 The changes in this patch are valid only and uniquely during boot. The common transactions with the punit during the driver's normal operation are not affected. Signed-off-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Co-developed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230206183236.109908-1-andi.shyti@linux.intel.com
2023-02-07drm/probe_helper: sort out poll_running vs poll_enabledDmitry Baryshkov
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 <laurentiu.palcu@oss.nxp.com> Fixes: c8268795c9a9 ("drm/probe-helper: enable and disable HPD on connectors") Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Tested-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Tested-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230124104548.3234554-2-dmitry.baryshkov@linaro.org (cherry picked from commit d33a54e3991dfce88b4fc6d9c3360951c2c5660d) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2023-02-07drm/probe_helper: extract two helper functionsDmitry Baryshkov
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 <dmitry.baryshkov@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230124104548.3234554-1-dmitry.baryshkov@linaro.org (cherry picked from commit cbf143b282c64e59559cc8351c0b5b1ab4bbdcbe) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2023-02-07drm/client: fix circular reference counting issueChristian König
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 <christian.koenig@amd.com> Fixes: c76f0f7cb546 ("drm: Begin an API for in-kernel clients") Cc: <stable@vger.kernel.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230126102814.8722-1-christian.koenig@amd.com
2023-02-06drm/i915/huc: Add and use HuC oriented print macrosMichal Wajdeczko
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 <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230203085912.1963-1-michal.wajdeczko@intel.com
2023-02-06drm/bridge: panel: Set orientation on panel_bridge connectorJohn Keeping
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 <john@metanate.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230120114313.2087015-1-john@metanate.com
2023-02-06drm/virtio: exbuf->fence_fd unmodified on interrupted waitRyan Neph
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 <ryanneph@chromium.org> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230203233345.2477767-1-ryanneph@chromium.org
2023-02-06drm/i915: Fix memory leaks in scatterlistMatt Atwood
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 <chris@chris-wilson.co.uk> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230201232801.123684-1-matthew.s.atwood@intel.com
2023-02-06drm/i915/doc: Escape wildcard in method namesBagas Sanjaya
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/20230203134622.0b6315b9@canb.auug.org.au/ Fixes: 0c3064cf33fbfa ("drm/i915/doc: Document where to implement register workarounds") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230203100215.31852-2-bagasdotme@gmail.com
2023-02-06drm/i915: Initialize the obj flags for shmem objectsAravind Iddamsetty
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: <stable@vger.kernel.org> # v5.15+ Cc: Matthew Auld <matthew.auld@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> [tursulin: Grouped all tags together.] Link: https://patchwork.freedesktop.org/patch/msgid/20230203135205.4051149-1-aravind.iddamsetty@intel.com (cherry picked from commit bca0d1d3ceeb07be45a51c0fa4d57a0ce31b6aed) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-02-06drm/i915: Move fd_install after last use of fenceRob Clark
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 <robdclark@chromium.org> Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)") Cc: <stable@vger.kernel.org> # v5.15+ [tursulin: Added stable tag.] Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230203164937.4035503-1-robdclark@gmail.com (cherry picked from commit 960dafa30455450d318756a9896a02727f2639e0) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-02-06drm/i915/fbdev: Implement fb_dirty for intel custom fb helperJouni Högander
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ä <ville.syrjala@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230123074437.475103-1-jouni.hogander@intel.com (cherry picked from commit 1af546c2cec6e28b6bbe01a4ad0c38e96e54fcb4) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-02-06drm/i915: Don't do the WM0->WM1 copy w/a if WM1 is already enabledVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230131002127.29305-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (cherry picked from commit c580c2d27ac8754cc6f01da1d715b7272f5f9cbb) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-02-06drm/i915/hwmon: Enable PL1 power limitAshutosh Dixit
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 <ashutosh.dixit@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230203155309.1042297-1-ashutosh.dixit@intel.com
2023-02-06drm/i915: fix up merge with usb-next branchGreg Kroah-Hartman
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 <lkp@intel.com> Fixes: 924fb3ec50f5 ("Merge 6.2-rc7 into usb-next") Link: https://lore.kernel.org/r/20230206124422.2266892-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-06drm/ttm: prevent moving of pinned BOsChristian König
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 <christian.koenig@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130120636.63765-6-matthew.auld@intel.com
2023-02-06drm/ttm: stop allocating a dummy resource for pipelined guttingChristian König
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 <christian.koenig@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130120636.63765-5-matthew.auld@intel.com
2023-02-06drm/ttm: stop allocating dummy resources during BO creationChristian König
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 <christian.koenig@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130120636.63765-4-matthew.auld@intel.com
2023-02-06drm/ttm: clear the ttm_tt when bo->resource is NULLMatthew Auld
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 <matthew.auld@intel.com> Reviewed-by: Christian König <ckoenig.leichtzumerken@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130101230.25347-3-matthew.auld@intel.com Acked-by: Nirmoy Das <nirmoy.das@intel.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2023-02-06drm/i915/ttm: audit remaining bo->resourceMatthew Auld
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 <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130101230.25347-2-matthew.auld@intel.com Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Christian König <ckoenig.leichtzumerken@gmail.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2023-02-06drm/i915/ttm: fix sparse warningMatthew Auld
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 <lkp@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130101230.25347-1-matthew.auld@intel.com Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Acked-by: Christian König <ckoenig.leichtzumerken@gmail.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2023-02-06drm/i915: Initialize the obj flags for shmem objectsAravind Iddamsetty
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: <stable@vger.kernel.org> # v5.15+ Cc: Matthew Auld <matthew.auld@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> [tursulin: Grouped all tags together.] Link: https://patchwork.freedesktop.org/patch/msgid/20230203135205.4051149-1-aravind.iddamsetty@intel.com
2023-02-06drm/i915: Move fd_install after last use of fenceRob Clark
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 <robdclark@chromium.org> Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)") Cc: <stable@vger.kernel.org> # v5.15+ [tursulin: Added stable tag.] Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230203164937.4035503-1-robdclark@gmail.com
2023-02-06Merge 6.2-rc7 into usb-nextGreg Kroah-Hartman
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 <gregkh@linuxfoundation.org>
2023-02-05drm/rockchip: Drop unbalanced obj unrefRob Clark
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 <robdclark@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230119231734.2884543-1-robdclark@gmail.com
2023-02-05drm/rockchip: avoid duplicate mappings for IOMMU devicesJohn Keeping
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 <john@metanate.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20221110172415.2853420-1-john@metanate.com
2023-02-05drm/rockchip: vop: Quiet always-warning AFBC logBrian Norris
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: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20221031101557.1.Ic1569d394173c1c3016142fee4bb87a09753db94@changeid
2023-02-05drm/rockchip: vop2: add support for the rgb output blockMichael Riesch
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: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-6-michael.riesch@wolfvision.net
2023-02-05drm/rockchip: vop2: use symmetric function pair vop2_{create,destroy}_crtcsMichael Riesch
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 <michael.riesch@wolfvision.net> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-5-michael.riesch@wolfvision.net
2023-02-05drm/rockchip: rgb: add video_port parameter to init functionMichael Riesch
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 <michael.riesch@wolfvision.net> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-4-michael.riesch@wolfvision.net
2023-02-05drm/rockchip: rgb: embed drm_encoder into rockchip_encoderMichael Riesch
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 <michael.riesch@wolfvision.net> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-3-michael.riesch@wolfvision.net
2023-02-05drm/rockchip: vop2: initialize possible_crtcs properlyMichael Riesch
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 <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-2-michael.riesch@wolfvision.net
2023-02-03drm/i915: Make sure dsm_size has correct granularityNirmoy Das
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 <matthew.auld@intel.com> Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230202180243.23637-1-nirmoy.das@intel.com
2023-02-03Revert "drm/amd/display: disable S/G display on DCN 3.1.4"Alex Deucher
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 <yifan1.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-02-03Revert "Revert "drm/amdgpu/gmc11: enable AGP aperture""Alex Deucher
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 <harry.wentland@amd.com> Reviewed-by: Yifan Zhang <yifan1.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-23 16:24:27 +0000