summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2024-02-07drm/i915: s/phys_base/dma_addr/Ville Syrjälä
The address we read from the PTE is a dma address, not a physical address. Rename the variable to say so. Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-11-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Fix MTL initial plane readoutVille Syrjälä
MTL stolen memory looks more like local memory, so use the (now fixed) lmem path when doing the initial plane readout. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-10-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Fix region start during initial plane readoutVille Syrjälä
On MTL the stolen region starts at offset 8MiB from the start of LMEMBAR. The dma addresses are thus also offset by 8MiB. However the mm_node/etc. is zero based, and i915_pages_create_for_stolen() will add the appropriate region.start into the sg dma address. So when we do the readout we need to convert the dma address read from the PTE to be zero based as well. Note that currently we don't take this path on MTL, but we should and thus this needs to be fixed. For lmem this works correctly already as the lmem region.start==0. While at it let's also make sure the address points to somewhere within the memory region. We don't need to check the size as i915_gem_object_create_region_at() should later fail if the object size exceeds the region size. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-9-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Fix PTE decode during initial plane readoutVille Syrjälä
When multiple pipes are enabled by the BIOS we try to read out each in turn. But we do the readout for the second only after the inherited vma for the first has been rebound into its original place (and thus the PTEs have been rewritten). Unlike the BIOS we set some high caching bits in the PTE on MTL which confuses the readout for the second plane. Filter out the non-address bits from the PTE value appropriately to fix this. I suppose it might also be possible that the BIOS would already set some caching bits as well, in which case we'd run into this same issue already for the first plane. TODO: - should abstract the PTE decoding to avoid details leaking all over - should probably do the readout for all the planes before we touch anything (including the PTEs) so that we truly read out the BIOS state Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-8-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Rename the DSM/GSM registersVille Syrjälä
0x108100 and 0x1080c0 have been around since snb. Rename the defines appropriately. v2: Rebase Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-7-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Disable the "binder"Ville Syrjälä
Now that the GGTT PTE updates go straight to GSMBASE (bypassing GTTMMADR) there should be no more risk of system hangs? So the "binder" (ie. update the PTEs via MI_UPDATE_GTT) is no longer necessary, disable it. My main worry with the MI_UPDATE_GTT are: - only used on this one platform so very limited testing coverage - async so more opprtunities to screw things up - what happens if the engine hangs while we're waiting for MI_UPDATE_GTT to finish? - requires working command submission, so even getting a working display now depends on a lot more extra components working correctly TODO: MI_UPDATE_GTT might be interesting as an optimization though, so perhaps someone should look into always using it (assuming the GPU is alive and well)? v2: Keep using MI_UPDATE_GTT on VM guests v3: use i915_direct_stolen_access() Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-6-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory accessVille Syrjälä
On MTL accessing stolen memory via the BARs is somehow borked, and it can hang the machine. As a workaround let's bypass the BARs and just go straight to DSMBASE/GSMBASE instead. Note that on every other platform this itself would hang the machine, but on MTL the system firmware is expected to relax the access permission guarding stolen memory to enable this workaround, and thus direct CPU accesses should be fine. The raw stolen memory areas won't be passed to VMs so we'll need to risk using the BAR there for the initial setup. Once command submission is up we should switch to MI_UPDATE_GTT which at least shouldn't hang the whole machine. v2: Don't use direct GSM/DSM access on guests Add w/a number v3: Check register 0x138914 to see if pcode did its job Add some debug prints Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-5-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Remove ad-hoc lmem/stolen debugsVille Syrjälä
Now that intel_memory_regions_hw_probe() prints out each and every memory region there's no reason to have ad-hoc debugs to do similar things elsewhere. Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-4-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Print memory region info during probeVille Syrjälä
Dump the details about every memory region into dmesg at probe time. Avoids having to dig those out from random places when debugging stuff. Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-3-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Use struct resource for memory region IO as wellVille Syrjälä
mem->region is a struct resource, but mem->io_start and mem->io_size are not for whatever reason. Let's unify this and convert the io stuff into a struct resource as well. Should make life a little less annoying when you don't have juggle between two different approaches all the time. Mostly done using cocci (with manual tweaks at all the places where we mutate io_size by hand): @@ struct intel_memory_region *M; expression START, SIZE; @@ - M->io_start = START; - M->io_size = SIZE; + M->io = DEFINE_RES_MEM(START, SIZE); @@ struct intel_memory_region *M; @@ - M->io_start + M->io.start @@ struct intel_memory_region M; @@ - M.io_start + M.io.start @@ expression M; @@ - M->io_size + resource_size(&M->io) @@ expression M; @@ - M.io_size + resource_size(&M.io) Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-2-ville.syrjala@linux.intel.com
2024-02-06drm/xe: Remove TEST_VM_ASYNC_OPS_ERRORMatthew Brost
TEST_VM_ASYNC_OPS_ERROR is broken and unused. Remove for now and will pull back in a later time when it is used, fixed, and properly hidden behind a Kconfig option. Also fixup the supported flags value. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240206045010.2981051-1-matthew.brost@intel.com
2024-02-06drm/xe/pm: add debug logs for D3coldRiana Tauro
add additional debug logs for PME# capability and presence of ACPI _PR3 resources. This is to identify the reason why the card is not capable of D3cold. No functional changes Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240206055917.2629027-1-riana.tauro@intel.com
2024-02-06drm/xe/hwmon: Refactor xe hwmonKarthik Poosa
Check latest platform first in xe_hwmon_get_reg. Move PVC HWMON registers to regs/xe_pcode.h. Suggested-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240201180600.434822-1-karthik.poosa@intel.com
2024-02-06drm/xe/vm: don't ignore error when in_kthreadMatthew Auld
If GUP fails and we are in_kthread, we can have pinned = 0 and ret = 0. If that happens we call sg_alloc_append_table_from_pages() with n_pages = 0, which is not well behaved and can trigger: kernel BUG at include/linux/scatterlist.h:115! depending on if the pages array happens to be zeroed or not. Even if we don't hit that it crashes later when trying to dma_map the returned table. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202171435.427630-2-matthew.auld@intel.com
2024-02-06drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMILucas Stach
Add a simple wrapper driver for the DWC HDMI bridge driver that implements the few bits that are necessary to abstract the i.MX8MP SoC integration. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Marek Vasut <marex@denx.de> Tested-by: Adam Ford <aford173@gmail.com> #imx8mp-beacon Tested-by: Richard Leitner <richard.leitner@skidata.com> Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Adam Ford <aford173@gmail.com> Link: https://lore.kernel.org/r/20240203165307.7806-11-aford173@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240203165307.7806-11-aford173@gmail.com
2024-02-06drm/sched: Re-queue run job worker when drm_sched_entity_pop_job() returns NULLMatthew Brost
Rather then loop over entities until one with a ready job is found, re-queue the run job worker when drm_sched_entity_pop_job() returns NULL. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Fixes: 66dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job worker") Reviewed-by: Luben Tuikov <ltuikov89@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240130030413.2031009-1-matthew.brost@intel.com
2024-02-05drm/xe: Assume large page size if VMA not yet boundMatthew Brost
The calculation to determine max page size of a VMA during a REMAP operations assumes the VMA has been bound. This assumption is not true if the VMA is from an eariler operation in an array of binds. If a VMA has not been bound use the maximum page size which will ensure the previous / next REMAP operations are not incorrectly skipped. Fixes: 8f33b4f054fc ("drm/xe: Avoid doing rebinds") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240205231714.2956225-1-matthew.brost@intel.com
2024-02-05drm/nouveau: nvkm_gsp_radix3_sg() should use nvkm_gsp_mem_ctor()Timur Tabi
Function nvkm_gsp_radix3_sg() uses nvkm_gsp_mem objects to allocate the radix3 tables, but it unnecessarily creates those objects manually instead of using the standard nvkm_gsp_mem_ctor() function like the rest of the code does. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202230608.1981026-2-ttabi@nvidia.com
2024-02-05drm/nouveau: fix several DMA buffer leaksTimur Tabi
Nouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects. Several of these buffers are never dealloced. Some of them can be deallocated right after GSP-RM is initialized, but the rest need to stay until the driver unloads. Also futher bullet-proof these objects by poisoning the buffer and clearing the nvkm_gsp_mem object when it is deallocated. Poisoning the buffer should trigger an error (or crash) from GSP-RM if it tries to access the buffer after we've deallocated it, because we were wrong about when it is safe to deallocate. Finally, change the mem->size field to a size_t because that's the same type that dma_alloc_coherent expects. Cc: <stable@vger.kernel.org> # v6.7 Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM") Signed-off-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202230608.1981026-1-ttabi@nvidia.com
2024-02-05nouveau/gsp: use correct size for registry rpc.Dave Airlie
Timur pointed this out before, and it just slipped my mind, but this might help some things work better, around pcie power management. Cc: <stable@vger.kernel.org> # v6.7 Fixes: 8d55b0a940bb ("nouveau/gsp: add some basic registry entries.") Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240130032643.2498315-1-airlied@gmail.com
2024-02-05drm/i915/hdcp: Pin the hdcp gsc message high in ggttVille Syrjälä
AFAICS there is no hardware restriction on where in ggtt the hdcp gsc message object needs to be bound. And as it's a regular shmem object we don't need it be in the mappabe range either. So pin it high to make avoid needlessly wasting the precious mappable range for it. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231215110933.9188-3-ville.syrjala@linux.intel.com Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
2024-02-05drm/i915/hdcp: Do intel_hdcp_component_init() much later during initVille Syrjälä
intel_hdcp_component_init()->...->intel_hdcp_gsc_initialize_message() will allocate ggtt address space for some hdcp gsc message thing. That is currently being done way too early as we haven't even taken over the BIOS fb yet. So this has the potential of corrupting ggtt PTEs that need to be preserved until the BIOS fb takover is done. Only call intel_hdcp_component_init() once all the BIOS fb takeover, and full ggtt init (which currently also needs to reserve very specific ranges of ggtt, thus assuming that no one else has stolen them yet) is done. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231215110933.9188-2-ville.syrjala@linux.intel.com Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
2024-02-05Merge tag 'gvt-fixes-2024-02-05' of https://github.com/intel/gvt-linux into ↵Joonas Lahtinen
drm-intel-fixes gvt-fixes-2024-02-05 - Fix broken gvt doc link (Zhenyu) - Fix one uninitialized variable bug in warning (Dan) - Update Zhi's new email address in MAINTAINERS file. (Zhi) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZcBULqJAL2CWJoHh@debian-scheme
2024-02-05Merge drm-misc-next-fixes-2024-01-19 into drm-misc-fixesMaxime Ripard
Merge the last drm-misc-next-fixes tag that fell through the cracks. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-02-05drm/bridge: imx: add driver for HDMI TX Parallel Video InterfaceLucas Stach
This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a full timing generator and can switch between different video sources. On the i.MX8MP however the only supported source is the LCDIF. The block just needs to be powered up and told about the polarity of the video sync signals to act in bypass mode. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Vasut <marex@denx.de> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Richard Leitner <richard.leitner@skidata.com> Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Adam Ford <aford173@gmail.com> Link: https://lore.kernel.org/r/20240203165307.7806-9-aford173@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240203165307.7806-9-aford173@gmail.com
2024-02-05drm/panel: visionox-r66451: Set prepare_prev_first flagJessica Zhang
The DSI host needs to be enabled for the panel to be initialized in prepare(). Ensure this happens by setting prepare_prev_first. Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240202-visionox-r66451-prev-first-v1-1-c267dc889284@quicinc.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240202-visionox-r66451-prev-first-v1-1-c267dc889284@quicinc.com
2024-02-05Merge tag 'drm-misc-next-2024-01-11' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v6.9: UAPI Changes: virtio: - add Venus capset defines Cross-subsystem Changes: Core Changes: - fix drm_fixp2int_ceil() - documentation fixes - clean ups - allow DRM_MM_DEBUG with DRM=m - build fixes for debugfs support - EDID cleanups - sched: error-handling fixes - ttm: add tests Driver Changes: bridge: - ite-6505: fix DP link-training bug - samsung-dsim: fix error checking in probe - tc358767: fix regmap usage efifb: - use copy of global screen_info state hisilicon: - fix EDID includes mgag200: - improve ioremap usage - convert to struct drm_edid nouveau: - disp: use kmemdup() - fix EDID includes - documentation fixes panel: - ltk050h3146w: error-handling fixes - panel-edp: support delay between power-on and enable; use put_sync in unprepare; support Mediatek MT8173 Chromebooks, BOE NV116WHM-N49 V8.0, BOE NV122WUM-N41, CSO MNC207QS1-1 plus DT bindings - panel-lvds: support EDT ETML0700Z9NDHA plus DT bindings - panel-novatek: FRIDA FRD400B25025-A-CTK plus DT bindings qaic: - fixes to BO handling - make use of DRM managed release - fix order of remove operations rockchip: - analogix_dp: get encoder port from DT - inno_hdmi: support HDMI for RK3128 - lvds: error-handling fixes simplefb: - fix logging ssd130x: - support SSD133x plus DT bindings tegra: - fix error handling tilcdc: - make use of DRM managed release v3d: - show memory stats in debugfs vc4: - fix error handling in plane prepare_fb - fix framebuffer test in plane helpers vesafb: - use copy of global screen_info state virtio: - cleanups vkms: - fix OOB access when programming the LUT - Kconfig improvements vmwgfx: - unmap surface before changing plane state - fix memory leak in error handling - documentation fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240111154902.GA8448@linux-uq9g
2024-02-05drm/i915/gvt: Fix uninitialized variable in handle_mmio()Dan Carpenter
This code prints the wrong variable in the warning message. It should print "i" instead of "info->offset". On the first iteration "info" is uninitialized leading to a crash and on subsequent iterations it prints the previous offset instead of the current one. Fixes: e0f74ed4634d ("i915/gvt: Separate the MMIO tracking table from GVT-g") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/11957c20-b178-4027-9b0a-e32e9591dd7c@moroto.mountain Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2024-02-05drm/i915: Replace dead 01.org linkZhenyu Wang
01.org is dead so replace old gvt link with current wiki page. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Zhi Wang <zhi.wang.linux@gmail.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20230804040544.1972958-1-zhenyuw@linux.intel.com
2024-02-02drm/xe/query: Use kzalloc for drm_xe_query_enginesNirmoy Das
Use kzalloc like other routines for better consistency. v2: Improve the subject(Matt) Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240131051838.24705-1-nirmoy.das@intel.com
2024-02-02drm/xe/guc: Add support for LNL firmwareJohn Harrison
First release of GuC firmware for LNL is now available, so start using it. v2: Actually use xe directory. Doh! (review feedback from Lucas) Signed-off-by: John Harrison <John.C.Harrison@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/20240202200017.2133438-6-John.C.Harrison@Intel.com
2024-02-02drm/xe/guc: Update to GuC firmware 70.19.2John Harrison
API compatibility version: 1.8.2 Signed-off-by: John Harrison <John.C.Harrison@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/20240202200017.2133438-5-John.C.Harrison@Intel.com
2024-02-02drm/xe/uc: Include patch version in expectationsJohn Harrison
Patch level releases can be just as important as major level releases if they fix a critical bug. So include the patch version in the expectation check so the user is properly informed if they need to update. Signed-off-by: John Harrison <John.C.Harrison@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/20240202200017.2133438-4-John.C.Harrison@Intel.com
2024-02-02drm/xe/display: Fix memleak in display initializationXiaoming Wang
intel_power_domains_init is called twice in xe_device_probe: 1) intel_power_domains_init() xe_display_init_nommio() xe_device_probe() 2) intel_power_domains_init() intel_display_driver_probe_noirq() xe_display_init_noirq() xe_device_probe() It needs remove one to avoid power_domains->power_wells double malloc. unreferenced object 0xffff88811150ee00 (size 512): comm "systemd-udevd", pid 506, jiffies 4294674198 (age 3605.560s) hex dump (first 32 bytes): 10 b4 9d a0 ff ff ff ff ff ff ff ff ff ff ff ff ................ ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff8134b901>] __kmem_cache_alloc_node+0x1c1/0x2b0 [<ffffffff812c98b2>] __kmalloc+0x52/0x150 [<ffffffffa08b0033>] __set_power_wells+0xc3/0x360 [xe] [<ffffffffa08562fc>] xe_display_init_nommio+0x4c/0x70 [xe] [<ffffffffa07f0d1c>] xe_device_probe+0x3c/0x5a0 [xe] [<ffffffffa082e48f>] xe_pci_probe+0x33f/0x5a0 [xe] [<ffffffff817f2187>] local_pci_probe+0x47/0xa0 [<ffffffff817f3db3>] pci_device_probe+0xc3/0x1f0 [<ffffffff8192f2a2>] really_probe+0x1a2/0x410 [<ffffffff8192f598>] __driver_probe_device+0x78/0x160 [<ffffffff8192f6ae>] driver_probe_device+0x1e/0x90 [<ffffffff8192f92a>] __driver_attach+0xda/0x1d0 [<ffffffff8192c95c>] bus_for_each_dev+0x7c/0xd0 [<ffffffff8192e159>] bus_add_driver+0x119/0x220 [<ffffffff81930d00>] driver_register+0x60/0x120 [<ffffffffa05e50a0>] 0xffffffffa05e50a0 The call to intel_power_domains_cleanup() needs to stay where it is for now. The main issue is that while the init is called by the display side, shared by i915 and xe, the cleanup is called by a non-shared code path. Fixing that will be done as a separate commit. Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Signed-off-by: Xiaoming Wang <xiaoming.wang@intel.com> [ reword commit message and explain why the fini needs to stay where it is ] 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/20240202215658.561298-1-lucas.demarchi@intel.com
2024-02-02drm/xe: Map both mem.kernel_bb_pool and usm.bb_poolMatthew Brost
For integrated devices we need to map both mem.kernel_bb_pool and usm.bb_pool to be able to run batches from both pools. Fixes: a682b6a42d4d ("drm/xe: Support device page faults on integrated platforms") Tested-by: Brian Welty <brian.welty@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Brian Welty <brian.welty@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202033440.2351862-1-matthew.brost@intel.com
2024-02-02drm/xe: circumvent bogus stringop-overflow warningArnd Bergmann
gcc-13 warns about an array overflow that it sees but that is prevented by the "asid % NUM_PF_QUEUE" calculation: drivers/gpu/drm/xe/xe_gt_pagefault.c: In function 'xe_guc_pagefault_handler': include/linux/fortify-string.h:57:33: error: writing 16 bytes into a region of size 0 [-Werror=stringop-overflow=] include/linux/fortify-string.h:689:26: note: in expansion of macro '__fortify_memcpy_chk' 689 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ | ^~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/xe/xe_gt_pagefault.c:341:17: note: in expansion of macro 'memcpy' 341 | memcpy(pf_queue->data + pf_queue->tail, msg, len * sizeof(u32)); | ^~~~~~ drivers/gpu/drm/xe/xe_gt_types.h:102:25: note: at offset [1144, 265324] into destination object 'tile' of size 8 I found that rewriting the assignment using pointer addition rather than the equivalent array index calculation prevents the warning, so use that instead. I sent a bug report against gcc for the false positive warning. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113214 Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240103114819.2913937-1-arnd@kernel.org
2024-02-02drm/i915/fbc: Allow FBC with CCS modifiers on SKL+Ville Syrjälä
Only display workarounds 0391 and 0475 call for disabling FBC with render compression, and those are listed only for pre-prod SKL steppings. So it should be safe to enable FB+CCS on production hardware. AFAIK CCS is limited to 50% bandwidth reduction (perhaps clear color can do better?). FBC can exceed that number by quite a bit, given the right kind of framebuffer contents. So piling on both kinds of compressions could still make sense. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10125 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240123090244.30025-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-02-02drm/panel: visionox-vtdr6130: Set prepare_prev_first flagJessica Zhang
The DSI host must be enabled for the panel to be initialized in prepare(). Set the prepare_prev_first flag to guarantee this. Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com> Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240201-visionox-vtdr-prev-first-v2-1-32db52867624@quicinc.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240201-visionox-vtdr-prev-first-v2-1-32db52867624@quicinc.com
2024-02-02drm/panel: novatek-nt36523: Set prepare_prev_firstKonrad Dybcio
The .prepare callback contains the init sequence, so the DSI host *must* be enabled at that point. Set the prepare_prev_first flag to ensure that. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Link: https://lore.kernel.org/r/20240201-topic-3623_fix-v1-1-86ee6f20876e@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240201-topic-3623_fix-v1-1-86ee6f20876e@linaro.org
2024-02-02drm/i915: Extract intel_atomic_swap_state()Ville Syrjälä
Pull all the state swap stuff into its own function to declutter intel_atomic_commit() a bit. Note that currently the state swap is spread across both sides of the unprepare branch in intel_atomic_commit(), but we can pull all of it ahead a bit since we bail on the first error, and thus there is no change in behaviour from the reordering. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231219130756.25986-4-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2024-02-02drm/i915: Rework global state serializaitonVille Syrjälä
Instead of injecting extra crtc commits to serialize the global state let's hand roll a bit of commit machinery to take care of the hardware synchronization. Rather than basing everything on the crtc commits we track these as their own thing. I think this makes more sense as the hardware blocks we are working with are not in any way tied to the pipes, so the completion should not be tied in with the vblank machinery either. The difference to the old behaviour is that: - we no longer pull extra crtcs into the commit which should make drm_atomic_check_only() happier - since those crtcs don't get pulled in we also don't end up reprogamming them and thus don't need to wait their vblanks to pass/etc. So this should be tad faster as well. TODO: perhaps have each global object complete its own commit once the post-plane update phase is done? Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6728 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231219130756.25986-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2024-02-02drm/i915: Compute use_sagv_wm differentlyVille Syrjälä
drm_atomic_check_only() gets upset if we try to add extra crtcs to any commit that isn't flagged with DRM_MODE_ATOMIC_ALLOW_MODESET. This conflicts with how SAGV watermarks work on pre-ADL as we need to manually switch over the SAGV watermarks before we can safely enable SAGV. So in order to make SAGV usage possible we need to compute each pipe's use of SAGV watermarks as if there aren't any other active pipes. Ie. if the current pipe isn't the one blocking SAGV then we make it use the SAGV watermarks, even if some other pipe prevents SAGV from actually being used. Otherwise we could end up with a pipes using the normal watermarks (but not blocking SAGV), and some other pipe in parallel enabling SAGV, which would likely cause underruns. The alternative approach of preventing SAGV usage until all pipes simultanously end up using SAGV watermarks would only really work if userspace always adds all pipes to every commits, which isn't the case typically. The downside of this is that we will end up using the less optimal SAGV watermarks even if some other pipe prevents SAGV from actually being enabled. In which case the system won't achieve the minimum possible power consumption. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231219130756.25986-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2024-02-02Merge tag 'drm-fixes-2024-02-03' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pul drm fixes from Dave Airlie: "Regular weekly fixes, mostly amdgpu and xe. One nouveau fix is a better fix for the deadlock and also helps with a sync race we were seeing. dma-buf: - heaps CMA page accounting fix virtio-gpu: - fix segment size xe: - A crash fix - A fix for an assert due to missing mem_acces ref - Only allow a single user-fence per exec / bind. - Some sparse warning fixes - Two fixes for compilation failures on various odd combinations of gcc / arch pointed out on LKML. - Fix a fragile partial allocation pointed out on LKML. - A sysfs ABI documentation warning fix amdgpu: - Fix reboot issue seen on some 7000 series dGPUs - Fix client init order for KFD - Misc display fixes - USB-C fix - DCN 3.5 fixes - Fix issues with GPU scheduler and GPU reset - GPU firmware loading fix - Misc fixes - GC 11.5 fix - VCN 4.0.5 fix - IH overflow fix amdkfd: - SVM fixes - Trap handler fix - Fix device permission lookup - Properly reserve BO before validating it nouveau: - fence/irq lock deadlock fix (second attempt) - gsp command size fix * tag 'drm-fixes-2024-02-03' of git://anongit.freedesktop.org/drm/drm: (35 commits) nouveau: offload fence uevents work to workqueue nouveau/gsp: use correct size for registry rpc. drm/amdgpu/pm: Use inline function for IP version check drm/hwmon: Fix abi doc warnings drm/xe: Make all GuC ABI shift values unsigned drm/xe/vm: Subclass userptr vmas drm/xe: Use LRC prefix rather than CTX prefix in lrc desc defines drm/xe: Don't use __user error pointers drm/xe: Annotate mcr_[un]lock() drm/xe: Only allow 1 ufence per exec / bind IOCTL drm/xe: Grab mem_access when disabling C6 on skip_guc_pc platforms drm/xe: Fix crash in trace_dma_fence_init() drm/amdgpu: Reset IH OVERFLOW_CLEAR bit drm/amdgpu: remove asymmetrical irq disabling in vcn 4.0.5 suspend drm/amdgpu: drm/amdgpu: remove golden setting for gfx 11.5.0 drm/amdkfd: reserve the BO before validating it drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()' drm/amd/display: Fix buffer overflow in 'get_host_router_total_dp_tunnel_bw()' drm/amd/display: Add NULL check for kzalloc in 'amdgpu_dm_atomic_commit_tail()' drm/amd: Don't init MEC2 firmware when it fails to load ...
2024-02-02drm/xe: Pick correct userptr VMA to repin on REMAP op failureMatthew Brost
A REMAP op is composed of 3 VMA's - unmap, prev map, and next map. When op_execute fails with -EAGAIN we need to update the local VMA pointer to the current op state and then repin the VMA if it is a userptr. Fixes a failure seen in xe_vm.munmap-style-unbind-userptr-one-partial. Fixes: b06d47be7c83 ("drm/xe: Port Xe to GPUVA") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240201004849.2219558-3-matthew.brost@intel.com
2024-02-02drm/xe: Take a reference in xe_exec_queue_last_fence_get()Matthew Brost
Take a reference in xe_exec_queue_last_fence_get(). Also fix a reference counting underflow bug VM bind and unbind. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240201004849.2219558-2-matthew.brost@intel.com
2024-02-02drm/imx/dcss: have all init functions use devresPhilipp Stanner
dcss currently allocates and ioremaps quite a few resources in its probe function's call graph. Devres now provides convenient functions which perform the same task but do the cleanup automatically. Port all memory allocations and ioremap() calls to the devres counterparts. Signed-off-by: Philipp Stanner <pstanner@redhat.com> Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240124111904.18261-4-pstanner@redhat.com
2024-02-02drm/imx/dcss: request memory regionPhilipp Stanner
The driver's memory regions are currently just ioremap()ed, but not reserved through a request. That's not a bug, but having the request is a little more robust. Implement the region-request through the corresponding managed devres-function. Signed-off-by: Philipp Stanner <pstanner@redhat.com> Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240124111904.18261-3-pstanner@redhat.com
2024-02-02drm/i915/display: Include debugfs.h in intel_display_debugfs_params.cPaz Zcharya
Commit 8015bee0bfec ("drm/i915/display: Add framework to add parameters specific to display") added the file intel_display_debugfs_params.c, which calls the functions "debugfs_create_{bool, ulong, str}" -- all of which are defined in <linux/debugfs.h>. The missing inclusion of this header file is breaking the ChromeOS build -- add an explicit include to fix that. Signed-off-by: Paz Zcharya <pazz@chromium.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240131204658.795278-1-pazz@chromium.org
2024-02-02nouveau: offload fence uevents work to workqueueDave Airlie
This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue. Cc: linux-stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/576237/
2024-02-02nouveau/gsp: use correct size for registry rpc.Dave Airlie
Timur pointed this out before, and it just slipped my mind, but this might help some things work better, around pcie power management. Fixes: 8d55b0a940bb ("nouveau/gsp: add some basic registry entries.") Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/576336/
generated by cgit v1.2.3 (git 2.51.0) at 2026-11-11 02:58:38 +0000