aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2024-03-13drm/xe/lnl: Enable display supportBalasubramani Vivekanandan1-0/+1
Enable display support for Lunar Lake. Signed-off-by: Balasubramani Vivekanandan <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Gustavo Sousa <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-03-13drm/i915/xe2lpd: Load DMCBalasubramani Vivekanandan1-1/+8
Load DMC for Xe2LPD. The value 0x8000 is the maximum payload size for any Xe2LPD DMC firmware. v2: - s/XE2LPD_MAX_FW_SIZE/XE2LPD_DMC_MAX_FW_SIZE/. (Lucas) Signed-off-by: Balasubramani Vivekanandan <[email protected]> Signed-off-by: Dnyaneshwar Bhadane <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Gustavo Sousa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-03-13drm/i915/xe2lpd: Support MDCLK:CDCLK ratio changesGustavo Sousa5-16/+77
Commit 394b4b7df9f7 ("drm/i915/lnl: Add CDCLK table") and commit 3d3696c0fed1 ("drm/i915/lnl: Start using CDCLK through PLL") started adding support for CDCLK programming support for Xe2LPD. One final piece is missing, which is the programming necessary for changed in the ratio between MDCLK and CDCLK. Let's do that now. BSpec instructs us to update MBUS_CTL and DBUF_CTL_S* registers when the ratio between MDCLK and CDCLK changes. The updates must be done before changing the CDCLK when decreasing the frequency; or after it when increasing the frequency. Ratio-related updates to MBUS_CTL also depend on the state of MBus joining, so they are performed by either CDCLK change sequence or by changes in MBus joining. Since one might happen independently of the other, we need to make sure that both logics see the necessary state values when programming that register. MBus joining logic needs to know the MDCLK:CDCLK ratio and that's already provided via mdclk_cdclk_ratio field of struct intel_dbuf_state. For the CDCLK logic, we need to have something similar: we need to propagate the status of MBus joining to struct intel_cdclk_state. Do that by adding the field joined_mbus to struct intel_cdclk_config. (Preferably, that field would be added to intel_cdclk_state, however currently only intel_cdclk_config is passed down to the functions that do the register programming. We might revisit this decision if we find that refactoring the code to pass the whole intel_cdclk_state is worth it.) Bspec: 68864, 68868, 69090, 69482 Reviewed-by: Stanislav Lisovskiy <[email protected]> Signed-off-by: Gustavo Sousa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-03-13drm/i915: Add mdclk_cdclk_ratio to intel_dbuf_stateGustavo Sousa4-1/+42
Xe2LPD always selects the CDCLK PLL as source for the MDCLK. Because of that, the ratio between MDCLK and CDCLK is not be constant anymore. As such, make sure to have the current ratio available in intel_dbuf_state so that it can be used during dbuf programming. Note that we write-lock the global state instead of serializing to a hardware commit because a change in the ratio should be rather handled in the CDCLK change sequence, which will need to take care of updating the necessary registers in that case. We will implement that in upcoming changes. That said, changes in the MBus joining state should be handled by the DBUF/MBUS logic, just like it is already done, but the logic will need to know the ratio to properly update the registers. v2: - Make first sentence of commit message more intelligible. (Matt) Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Gustavo Sousa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-03-13drm/i915: Extract intel_dbuf_mdclk_cdclk_ratio_update()Gustavo Sousa1-11/+19
As of Xe2LPD, it is now possible to select the source of the MDCLK as either the CD2XCLK or the CDCLK PLL. Previous display IPs were hardcoded to use the CD2XCLK. For those, the ratio between MDCLK and CDCLK remained constant, namely 2. For Xe2LPD, when we select the CDCLK PLL as the source, the ratio will vary according to the squashing configuration (since the cd2x divisor is fixed for all supported configurations). To help the transition to supporting changes in the ratio, extract the function intel_dbuf_mdclk_cdclk_ratio_update() from the existing logic and call it using 2 as hardcoded ratio. Upcoming changes will use that function for updates in the ratio due to CDCLK changes. Bspec: 50057, 69445, 49213, 68868 Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Gustavo Sousa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-03-13drm/i915/cdclk: Only compute squash waveform when necessaryGustavo Sousa1-3/+3
It is no use computing the squash waveform if we are not going to use it. Move the call to cdclk_squash_waveform() inside the block guarded by HAS_CDCLK_SQUASH(dev_priv). v2: - Move "u16 waveform" declaration to inside the block where it is initialized and used. (Matt) Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Gustavo Sousa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-03-13drm/i915/cdclk: Add and use mdclk_source_is_cdclk_pll()Gustavo Sousa2-2/+17
Currently, only Xe2LPD uses CDCLK PLL as the source of MDCLK and previous display IPs use the CD2XCLK. There will be changes in code paths common to those platforms that will rely on which source is being used. As such, let's make that information explicit with the addition of the predicate function mdclk_source_is_cdclk_pll(). Arguably, an enum could be created, but using a boolean should suffice here, since we there are only two possible sources and the logic that will rely on it will be very localized. In order to get the code into a more consistent state, let's also take this opportunity to hook the selection of CDCLK_CTL's "MDCLK Source Select" to that new function. Even though currently only MDCLK_SOURCE_SEL_CDCLK_PLL will be returned, having this extra logic is arguably better than keeping stuff untied and prone to bugs. v2: - Extract mdclk_source_is_cdclk_pll() out of xe2lpd_mdclk_source_sel() to make latter only about the register's field. Bspec: 69090, 68861 Cc: Matt Roper <[email protected]> Signed-off-by: Gustavo Sousa <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-03-13drm/i915/cdclk: Rename lnl_cdclk_table to xe2lpd_cdclk_tableGustavo Sousa1-2/+2
The CDCLK table is tied to Xe2LPD display and not to the platform. Let's rename lnl_cdclk_table to xe2lpd_cdclk_table in order to reflect that. Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Gustavo Sousa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-03-13drm/exynos: simplify the return value handling in exynos_dp_get_modes()Jani Nikula1-4/+3
Just use 0 and 1 directly, instead of the confusing local variable that's always set to 0. Cc: Inki Dae <[email protected]> Cc: Seung-Woo Kim <[email protected]> Cc: Kyungmin Park <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/64cc680f14d961cedb726a6fd5c6dfd53ca9bb85.1709913674.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-03-13drm/bridge: lt9611uxc: use int for holding number of modesJani Nikula1-1/+1
lt9611uxc_connector_get_modes() propagates the return value of drm_edid_connector_add_modes() but stores the int temporarily in an unsigned int. Use the correct type. Cc: Andrzej Hajda <[email protected]> Cc: Neil Armstrong <[email protected]> Cc: Robert Foss <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ed97f4f036263cdc4f34330cef91214970f99a77.1709913674.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-03-13drm/vc4: hdmi: do not return negative values from .get_modes()Jani Nikula1-1/+1
The .get_modes() hooks aren't supposed to return negative error codes. Return 0 for no modes, whatever the reason. Cc: Maxime Ripard <[email protected]> Cc: [email protected] Acked-by: Maxime Ripard <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/dcda6d4003e2c6192987916b35c7304732800e08.1709913674.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-03-13drm/imx/ipuv3: do not return negative values from .get_modes()Jani Nikula1-2/+2
The .get_modes() hooks aren't supposed to return negative error codes. Return 0 for no modes, whatever the reason. Cc: Philipp Zabel <[email protected]> Cc: [email protected] Acked-by: Philipp Zabel <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/311f6eec96d47949b16a670529f4d89fcd97aefa.1709913674.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-03-13drm/bridge: lt8912b: do not return negative values from .get_modes()Jani Nikula1-9/+7
The .get_modes() hooks aren't supposed to return negative error codes. Return 0 for no modes, whatever the reason. Cc: Adrien Grassein <[email protected]> Cc: [email protected] Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/dcdddcbcb64b6f6cdc55022ee50c10dee8ddbc3d.1709913674.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-03-13drm/exynos: do not return negative values from .get_modes()Jani Nikula2-4/+4
The .get_modes() hooks aren't supposed to return negative error codes. Return 0 for no modes, whatever the reason. Cc: Inki Dae <[email protected]> Cc: Seung-Woo Kim <[email protected]> Cc: Kyungmin Park <[email protected]> Cc: [email protected] Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/d8665f620d9c252aa7d5a4811ff6b16e773903a2.1709913674.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-03-13drm/panel: do not return negative error codes from drm_panel_get_modes()Jani Nikula1-6/+11
None of the callers of drm_panel_get_modes() expect it to return negative error codes. Either they propagate the return value in their struct drm_connector_helper_funcs .get_modes() hook (which is also not supposed to return negative codes), or add it to other counts leading to bogus values. On the other hand, many of the struct drm_panel_funcs .get_modes() hooks do return negative error codes, so handle them gracefully instead of propagating further. Return 0 for no modes, whatever the reason. Cc: Neil Armstrong <[email protected]> Cc: Jessica Zhang <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: [email protected] Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Jessica Zhang <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/79f559b72d8c493940417304e222a4b04dfa19c4.1709913674.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-03-13drm/probe-helper: warn about negative .get_modes()Jani Nikula1-0/+7
The .get_modes() callback is supposed to return the number of modes, never a negative error code. If a negative value is returned, it'll just be interpreted as a negative count, and added to previous calculations. Document the rules, but handle the negative values gracefully with an error message. Cc: [email protected] Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/50208c866facc33226a3c77b82bb96aeef8ef310.1709913674.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-03-13Merge drm/drm-fixes into drm-misc-fixesThomas Zimmermann46-295/+416
Backmerging to sync before merging the patchset at [1]. [1] https://lore.kernel.org/all/[email protected]/ Signed-off-by: Thomas Zimmermann <[email protected]>
2024-03-13drm/i915/opregion: add intel_opregion_vbt_present() stub for ACPI=nJani Nikula1-0/+5
The opregion code needs stubs for ACPI=n. Add the missing stub for intel_opregion_vbt_present(). Reported-by: Thomas Weißschuh <[email protected]> Closes: https://lore.kernel.org/r/20240312120240-afdb1b83-8517-434b-be79-06f41bafd71f@linutronix.de Fixes: 9d9bb71f3e11 ("drm/i915: Extract opregion vbt presence check") Cc: Radhakrishna Sripada <[email protected]> Reviewed-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-03-12Merge tag 'docs-6.9' of git://git.lwn.net/linuxLinus Torvalds1-24/+20
Pull documentation updates from Jonathan Corbet: "A moderatly busy cycle for development this time around. - Some cleanup of the main index page for easier navigation - Rework some of the other top-level pages for better readability and, with luck, fewer merge conflicts in the future. - Submit-checklist improvements, hopefully the first of many. - New Italian translations - A fair number of kernel-doc fixes and improvements. We have also dropped the recommendation to use an old version of Sphinx. - A new document from Thorsten on bisection ... and lots of fixes and updates" * tag 'docs-6.9' of git://git.lwn.net/linux: (54 commits) docs: verify/bisect: fixes, finetuning, and support for Arch docs: Makefile: Add dependency to $(YNL_INDEX) for targets other than htmldocs docs: Move ja_JP/howto.rst to ja_JP/process/howto.rst docs: submit-checklist: use subheadings docs: submit-checklist: structure by category docs: new text on bisecting which also covers bug validation docs: drop the version constraints for sphinx and dependencies docs: kerneldoc-preamble.sty: Remove code for Sphinx <2.4 docs: Restore "smart quotes" for quotes docs/zh_CN: accurate translation of "function" docs: Include simplified link titles in main index docs: Correct formatting of title in admin-guide/index.rst docs: kernel_feat.py: fix build error for missing files MAINTAINERS: Set the field name for subsystem profile section kasan: Add documentation for CONFIG_KASAN_EXTRA_INFO Fixed case issue with 'fault-injection' in documentation kernel-doc: handle #if in enums as well Documentation: update mailing list addresses doc: kerneldoc.py: fix indentation scripts/kernel-doc: simplify signature printing ...
2024-03-12drm/xe/uapi: Add IP version and stepping to GT list queryMatt Roper1-0/+8
For modern platforms (MTL and later), both kernel and userspace drivers are expected to apply GT programming and workarounds based on the IP version and stepping self-reported by the GT hardware via the GMD_ID registers. Since userspace drivers can't access these registers directly, pass along the version and stepping information via the GT list query. Note that the new query fields will remain 0's when running on pre-GMD_ID platforms. Userspace is expected to continue using PCI devid / revid on those older platforms. Although the hardware also has a GMD_ID register for display version/stepping, that value is intentionally *not* included anywhere in the Xe uapi. Display userspace should be using platform-agnostic APIs and auto-detecting platform capabilities rather than matching specific IP versions. v2: - s/revid/rev/ (Lucas) - Fix kerneldoc copy/paste mistakes Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-12drm/nouveau: fix kerneldoc warningsTimur Tabi1-0/+9
kernel test robot complains about missing kerneldoc entries: drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning: Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg Signed-off-by: Timur Tabi <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-12nouveau: reset the bo resource bus info after an evictionDave Airlie1-0/+2
Later attempts to refault the bo won't happen and the whole GPU does to lunch. I think Christian's refactoring of this code out to the driver broke this not very well tested path. Fixes: 141b15e59175 ("drm/nouveau: move io_reserve_lru handling into the driver v5") Cc: Christian König <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Acked-by: Christian König <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-12drm/shmem-helper: Remove duplicate includeJiapeng Chong1-1/+0
./drivers/gpu/drm/drm_gem_shmem_helper.c: linux/module.h is included more than once. Reported-by: Abaci Robot <[email protected]> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4567 Signed-off-by: Jiapeng Chong <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-12drm/i915/dp: Fix DSC state HW readout for SST connectorsImre Deak1-0/+1
Commit a62e14598150 ("drm/i915/dp: Fix connector DSC HW state readout") moved the DSC HW state readout to a connector specific hook, however only added the hook for DP MST connectors, not for DP SST ones. Fix adding the hook for SST connectors as well. This fixes the following warn on platforms where BIOS enables DSC: [ 66.208601] i915 0000:00:02.0: drm_WARN_ON(!connector->dp.dsc_decompression_aux || !connector->dp.dsc_decompression_enabled) ... [ 66.209024] RIP: 0010:intel_dp_sink_disable_decompression+0x76/0x110 [i915] ... [ 66.209333] ? intel_dp_sink_disable_decompression+0x76/0x110 [i915] ... [ 66.210068] intel_disable_ddi+0x135/0x1d0 [i915] [ 66.210302] intel_encoders_disable+0x9b/0xc0 [i915] [ 66.210565] hsw_crtc_disable+0x153/0x170 [i915] [ 66.210823] intel_old_crtc_state_disables+0x52/0xb0 [i915] [ 66.211107] intel_atomic_commit_tail+0x5cf/0x1330 [i915] [ 66.211366] intel_atomic_commit+0x39d/0x3f0 [i915] [ 66.211612] ? intel_atomic_commit+0x39d/0x3f0 [i915] [ 66.211872] drm_atomic_commit+0x9d/0xd0 [drm] [ 66.211921] ? __pfx___drm_printfn_info+0x10/0x10 [drm] [ 66.211975] intel_initial_commit+0x1a8/0x260 [i915] [ 66.212234] intel_display_driver_probe+0x2a/0x80 [i915] [ 66.212479] i915_driver_probe+0x7c6/0xc60 [i915] [ 66.212664] ? drm_privacy_screen_get+0x168/0x190 [drm] [ 66.212711] i915_pci_probe+0xe2/0x1c0 [i915] Fixes: a62e14598150 ("drm/i915/dp: Fix connector DSC HW state readout") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10410 Cc: Ankit Nautiyal <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11Merge tag 'x86-apic-2024-03-10' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 APIC updates from Thomas Gleixner: "Rework of APIC enumeration and topology evaluation. The current implementation has a couple of shortcomings: - It fails to handle hybrid systems correctly. - The APIC registration code which handles CPU number assignents is in the middle of the APIC code and detached from the topology evaluation. - The various mechanisms which enumerate APICs, ACPI, MPPARSE and guest specific ones, tweak global variables as they see fit or in case of XENPV just hack around the generic mechanisms completely. - The CPUID topology evaluation code is sprinkled all over the vendor code and reevaluates global variables on every hotplug operation. - There is no way to analyze topology on the boot CPU before bringing up the APs. This causes problems for infrastructure like PERF which needs to size certain aspects upfront or could be simplified if that would be possible. - The APIC admission and CPU number association logic is incomprehensible and overly complex and needs to be kept around after boot instead of completing this right after the APIC enumeration. This update addresses these shortcomings with the following changes: - Rework the CPUID evaluation code so it is common for all vendors and provides information about the APIC ID segments in a uniform way independent of the number of segments (Thread, Core, Module, ..., Die, Package) so that this information can be computed instead of rewriting global variables of dubious value over and over. - A few cleanups and simplifcations of the APIC, IO/APIC and related interfaces to prepare for the topology evaluation changes. - Seperation of the parser stages so the early evaluation which tries to find the APIC address can be seperately overridden from the late evaluation which enumerates and registers the local APIC as further preparation for sanitizing the topology evaluation. - A new registration and admission logic which - encapsulates the inner workings so that parsers and guest logic cannot longer fiddle in it - uses the APIC ID segments to build topology bitmaps at registration time - provides a sane admission logic - allows to detect the crash kernel case, where CPU0 does not run on the real BSP, automatically. This is required to prevent sending INIT/SIPI sequences to the real BSP which would reset the whole machine. This was so far handled by a tedious command line parameter, which does not even work in nested crash scenarios. - Associates CPU number after the enumeration completed and prevents the late registration of APICs, which was somehow tolerated before. - Converting all parsers and guest enumeration mechanisms over to the new interfaces. This allows to get rid of all global variable tweaking from the parsers and enumeration mechanisms and sanitizes the XEN[PV] handling so it can use CPUID evaluation for the first time. - Mopping up existing sins by taking the information from the APIC ID segment bitmaps. This evaluates hybrid systems correctly on the boot CPU and allows for cleanups and fixes in the related drivers, e.g. PERF. The series has been extensively tested and the minimal late fallout due to a broken ACPI/MADT table has been addressed by tightening the admission logic further" * tag 'x86-apic-2024-03-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (76 commits) x86/topology: Ignore non-present APIC IDs in a present package x86/apic: Build the x86 topology enumeration functions on UP APIC builds too smp: Provide 'setup_max_cpus' definition on UP too smp: Avoid 'setup_max_cpus' namespace collision/shadowing x86/bugs: Use fixed addressing for VERW operand x86/cpu/topology: Get rid of cpuinfo::x86_max_cores x86/cpu/topology: Provide __num_[cores|threads]_per_package x86/cpu/topology: Rename topology_max_die_per_package() x86/cpu/topology: Rename smp_num_siblings x86/cpu/topology: Retrieve cores per package from topology bitmaps x86/cpu/topology: Use topology logical mapping mechanism x86/cpu/topology: Provide logical pkg/die mapping x86/cpu/topology: Simplify cpu_mark_primary_thread() x86/cpu/topology: Mop up primary thread mask handling x86/cpu/topology: Use topology bitmaps for sizing x86/cpu/topology: Let XEN/PV use topology from CPUID/MADT x86/xen/smp_pv: Count number of vCPUs early x86/cpu/topology: Assign hotpluggable CPUIDs during init x86/cpu/topology: Reject unknown APIC IDs on ACPI hotplug x86/topology: Add a mechanism to track topology via APIC IDs ...
2024-03-11drm/i915: Reuse RPLU cdclk fns for MTL+Radhakrishna Sripada1-9/+2
MTL/LNL use the same cdclk functions as RPLU albeit with different tables. Having separate tables and not requiring special handling for the platforms, reuse RPLU cdclk functions. v2: Update subject and the commit message(Jani) Cc: Gustavo Sousa <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11Merge tag 'linux_kselftest-kunit-6.9-rc1' of ↵Linus Torvalds3-14/+14
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull KUnit updates from Shuah Khan: - fix to make kunit_bus_type const - kunit tool change to Print UML command - DRM device creation helpers are now using the new kunit device creation helpers. This change resulted in DRM helpers switching from using a platform_device, to a dedicated bus and device type used by kunit. kunit devices don't set DMA mask and this caused regression on some drm tests as they can't allocate DMA buffers. Fix this problem by setting DMA masks on the kunit device during initialization. - KUnit has several macros which accept a log message, which can contain printf format specifiers. Some of these (the explicit log macros) already use the __printf() gcc attribute to ensure the format specifiers are valid, but those which could fail the test, and hence used __kunit_do_failed_assertion() behind the scenes, did not. These include: KUNIT_EXPECT_*_MSG(), KUNIT_ASSERT_*_MSG(), and KUNIT_FAIL() A nine-patch series adds the __printf() attribute, and fixes all of the issues uncovered. * tag 'linux_kselftest-kunit-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: kunit: Annotate _MSG assertion variants with gnu printf specifiers drm: tests: Fix invalid printf format specifiers in KUnit tests drm/xe/tests: Fix printf format specifiers in xe_migrate test net: test: Fix printf format specifier in skb_segment kunit test rtc: test: Fix invalid format specifier. time: test: Fix incorrect format specifier lib: memcpy_kunit: Fix an invalid format specifier in an assertion msg lib/cmdline: Fix an invalid format specifier in an assertion msg kunit: test: Log the correct filter string in executor_test kunit: Setup DMA masks on the kunit device kunit: make kunit_bus_type const kunit: Mark filter* params as rw kunit: tool: Print UML command
2024-03-11drm/i915: Drop WA 16015675438Lucas De Marchi2-6/+2
With dynamic load-balancing disabled on the compute side, there's no reason left to enable WA 16015675438. Drop it from both PVC and DG2. Note that this can be done because now the driver always set a fixed partition of EUs during initialization via the ccs_mode configuration. The flag to GuC is still needed because of 18020744125, so update the comment accordingly. Cc: Rodrigo Vivi <[email protected]> Acked-by: Mateusz Jablonski <[email protected]> Acked-by: Michal Mrozek <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-03-11Merge branch 'pm-runtime'Rafael J. Wysocki2-2/+5
Merge changes related to the runtime power management of devices for 6.9-rc1: - Simplify pm_runtime_get_if_active() usage and add a replacement for pm_runtime_put_autosuspend() (Sakari Ailus). - Add a tracepoint for runtime_status changes tracking (Vilas Bhat). - Fix section title markdown in the runtime PM documentation (Yiwei Lin). * pm-runtime: Documentation: PM: Fix runtime_pm.rst markdown syntax PM: runtime: add tracepoint for runtime_status changes PM: runtime: Add pm_runtime_put_autosuspend() replacement PM: runtime: Simplify pm_runtime_get_if_active() usage
2024-03-11drm/qxl: Do not pin buffer objects for vmapThomas Zimmermann1-5/+0
Pin and vmap are distinct operations. Do not perform a pin as part of the vmap call. This used to be necessary to keep the fbdev buffer in place while it is being updated. Fbdev emulation has meanwhile been fixed to lock the buffer correctly. Same for vunmap. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> # virtio-gpu Acked-by: Christian König <[email protected]> Acked-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/gem-vram: Do not pin buffer objects for vmapThomas Zimmermann1-58/+32
Pin and vmap are distinct operations. Do not perform a pin as part of the vmap call. This used to be necessary to keep the fbdev buffer in place while it is being updated. Fbdev emulation has meanwhile been fixed to lock the buffer correctly. Same for vunmap. For refactoring the code, remove the pin calls from the helper's vmap implementation in drm_gem_vram_vmap() and inline the call to drm_gem_vram_kmap_locked(). This gives a vmap helper that only maps the buffer object's memory pages without pinning or locking. Do a similar refactoring for vunmap. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Christian König <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> # virtio-gpu Acked-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/client: Pin vmap'ed GEM buffersThomas Zimmermann1-3/+21
The function drm_client_buffer_vmap() establishes a long-term mapping of the client's buffer object into the kernel address space. Make sure that buffer does not move by pinning it to its current location. Same for vunmap with unpin. The only caller of drm_client_buffer_vmap() is fbdev-dma, which uses gem-dma. As DMA-backed GEM buffers do not move, this change is for correctness with little impact in practice. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Christian König <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> # virtio-gpu Acked-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/fbdev-generic: Fix locking with drm_client_buffer_vmap_local()Thomas Zimmermann3-10/+74
Temporarily lock the fbdev buffer object during updates to prevent memory managers from evicting/moving the buffer. Moving a buffer object while update its content results in undefined behaviour. Fbdev-generic updates its buffer object from a shadow buffer. Gem-shmem and gem-dma helpers do not move buffer objects, so they are safe to be used with fbdev-generic. Gem-vram and qxl are based on TTM, but pin buffer objects are part of the vmap operation. So both are also safe to be used with fbdev-generic. Amdgpu and nouveau do not pin or lock the buffer object during an update. Their TTM-based memory management could move the buffer object while the update is ongoing. The new vmap_local and vunmap_local helpers hold the buffer object's reservation lock during the buffer update. This prevents moving the buffer object on all memory managers. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Christian König <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> # virtio-gpu Acked-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/gem: Acquire reservation lock in drm_gem_{pin/unpin}()Thomas Zimmermann9-85/+32
Acquire the buffer object's reservation lock in drm_gem_pin() and remove locking the drivers' GEM callbacks where necessary. Same for unpin(). DRM drivers and memory managers modified by this patch will now have correct dma-buf locking semantics: the caller is responsible for holding the reservation lock when calling the pin or unpin callback. DRM drivers and memory managers that are not modified will now be protected against concurent invocation of their pin and unpin callbacks. PRIME does not implement struct dma_buf_ops.pin, which requires the caller to hold the reservation lock. It does implement struct dma_buf_ops.attach, which requires to callee to acquire the reservation lock. The PRIME code uses drm_gem_pin(), so locks are now taken as specified. Same for unpin and detach. The patch harmonizes GEM pin and unpin to have non-interruptible reservation locking across all drivers, as is already the case for vmap and vunmap. This affects gem-shmem, gem-vram, loongson, qxl and radeon. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Christian König <[email protected]> Reviewed-by: Zack Rusin <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> # virtio-gpu Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/qxl: Acquire reservation lock in GEM pin/unpin callbacksThomas Zimmermann1-2/+14
Acquire the reservation lock directly in GEM pin callback. Same for unpin. Prepares for further changes. Dma-buf locking semantics require callers to hold the buffer's reservation lock when invoking the pin and unpin callbacks. Prepare qxl accordingly by pushing locking out of the implementation. A follow-up patch will fix locking for all GEM code at once. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> # virtio-gpu Acked-by: Christian König <[email protected]> Acked-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/qxl: Provide qxl_bo_{pin,unpin}_locked()Thomas Zimmermann2-12/+15
Rename __qxl_bo_pin() to qxl_bo_pin_locked() and update all callers. The function will be helpful for implementing the GEM pin callback with correct semantics. Same for __qxl_bo_unpin(). Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> # virtio-gpu Acked-by: Christian König <[email protected]> Acked-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/nouveau: Acquire reservation lock in GEM pin/unpin callbacksThomas Zimmermann1-4/+15
Acquire the reservation lock directly in GEM pin callback. Same for unpin. Prepares for further changes. Dma-buf locking semantics require callers to hold the buffer's reservation lock when invoking the pin and unpin callbacks. Prepare nouveau accordingly by pushing locking out of the implementation. A follow-up patch will fix locking for all GEM code at once. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> # virtio-gpu Acked-by: Christian König <[email protected]> Acked-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/nouveau: Provide nouveau_bo_{pin,unpin}_locked()Thomas Zimmermann2-13/+32
Implement pinning without locking in nouveau_bo_pin_locked(). Keep nouveau_bo_pin() for acquiring the buffer object's reservation lock. The new helper will be useful for implementing the GEM pin callback with correct semantics. Same for unpin. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> # virtio-gpu Acked-by: Christian König <[email protected]> Acked-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/msm: Acquire reservation lock in GEM pin/unpin callbackThomas Zimmermann3-13/+27
Export msm_gem_pin_pages_locked() and acquire the reservation lock directly in GEM pin callback. Same for unpin. Prepares for further changes. Dma-buf locking semantics require callers to hold the buffer's reservation lock when invoking the pin and unpin callbacks. Prepare msm accordingly by pushing locking out of the implementation. A follow-up patch will fix locking for all GEM code at once. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> # virtio-gpu Acked-by: Christian König <[email protected]> Acked-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/msm: Provide msm_gem_get_pages_locked()Thomas Zimmermann1-4/+4
Rename msm_gem_pin_pages_locked() to msm_gem_get_pages_locked(). The function doesn't pin any pages, but only acquires them. Renaming the function makes the old name available. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> # virtio-gpu Acked-by: Christian König <[email protected]> Acked-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/gem-vram: Acquire reservation lock in GEM pin/unpin callbacksThomas Zimmermann1-3/+21
Acquire the reservation lock directly in GEM pin callback. Same for unpin. Prepares for further changes. Dma-buf locking semantics require callers to hold the buffer's reservation lock when invoking the pin and unpin callbacks. Prepare gem-vram accordingly by pushing locking out of the implementation. A follow-up patch will fix locking for all GEM code at once. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Christian König <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> # virtio-gpu Acked-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/gem-shmem: Acquire reservation lock in GEM pin/unpin callbacksThomas Zimmermann1-2/+4
Export drm_gem_shmem_pin_locked() and acquire the reservation lock directly in GEM pin callback. Same for unpin. Prepares for further changes. Dma-buf locking semantics require callers to hold the buffer's reservation lock when invoking the pin and unpin callbacks. Prepare gem-shmem accordingly by pushing locking out of the implementation. A follow-up patch will fix locking for all GEM code at once. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> # virtio-gpu Acked-by: Christian König <[email protected]> Acked-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/panfrost: Replace fdinfo's profiling debugfs knob with sysfsAdrián Larumbe6-44/+37
Debugfs isn't always available in production builds that try to squeeze every single byte out of the kernel image, but we still need a way to toggle the timestamp and cycle counter registers so that jobs can be profiled for fdinfo's drm engine and cycle calculations. Drop the debugfs knob and replace it with a sysfs file that accomplishes the same functionality, and document its ABI in a separate file. Signed-off-by: Adrián Larumbe <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Reviewed-by: Steven Price <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11Revert "drm/panthor: Fix undefined panthor_device_suspend/resume symbol issue"Jani Nikula2-1/+2
This reverts commit 674dc7f61aefea81901c21402946074927e63f1a. The commit causes a recursive dependency in kconfig: drivers/iommu/Kconfig:14:error: recursive dependency detected! drivers/iommu/Kconfig:14: symbol IOMMU_SUPPORT is selected by DRM_PANTHOR drivers/gpu/drm/panthor/Kconfig:3: symbol DRM_PANTHOR depends on PM kernel/power/Kconfig:183: symbol PM is selected by PM_SLEEP kernel/power/Kconfig:117: symbol PM_SLEEP depends on HIBERNATE_CALLBACKS kernel/power/Kconfig:35: symbol HIBERNATE_CALLBACKS is selected by XEN_SAVE_RESTORE arch/x86/xen/Kconfig:67: symbol XEN_SAVE_RESTORE depends on XEN arch/x86/xen/Kconfig:6: symbol XEN depends on PARAVIRT arch/x86/Kconfig:781: symbol PARAVIRT is selected by HYPERV drivers/hv/Kconfig:5: symbol HYPERV depends on X86_LOCAL_APIC arch/x86/Kconfig:1106: symbol X86_LOCAL_APIC depends on X86_UP_APIC arch/x86/Kconfig:1081: symbol X86_UP_APIC prompt is visible depending on PCI_MSI drivers/pci/Kconfig:39: symbol PCI_MSI is selected by AMD_IOMMU drivers/iommu/amd/Kconfig:3: symbol AMD_IOMMU depends on IOMMU_SUPPORT For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" Fixes: 674dc7f61aef ("drm/panthor: Fix undefined panthor_device_suspend/resume symbol issue") Cc: Boris Brezillon <[email protected]> Cc: Liviu Dudau <[email protected]> Cc: Steven Price <[email protected]> Acked-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-03-11drm/i915: Show bios vbt when read from firmware/spi/opromRadhakrishna Sripada1-29/+33
Make debugfs vbt only shows valid vbt when read from ACPI opregion. Make it work when read from firmware/spi/pci oprom cases. In the cases where VBT needs to be read from spi/pci oprom, take the wakeref to prevent WARN while reading DE registers during debugfs vbt dump. v2: Extract getting vbt from different sources to its own function. Protect sysfs write with vbt check(Jani) v3: Fix CI error by probing bios vbt with runtime_pm wakeref v4: Update commit message and skip waking up runtime while accessing vbt from opregion/firmware(Jani) v5: Skip grabbing unnecessary wakeref(Jani) Cc: Jani Nikula <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/i915: Duplicate opregion vbt memoryRadhakrishna Sripada2-3/+5
In the case of vbt residing in opregion, we simply remap the region into the kernel and pass the memory reference. Instead duplicate the memory to handle a saner cleanup in intel_bios_init. Cc: Jani Nikula <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/i915: Extract opregion vbt presence checkRadhakrishna Sripada3-2/+12
We want to later change intel_opregion_get_vbt to duplicate the vbt memory if present, which would be an overkill when we just want to peek into the presence of opregion vbt. Carve out the presence check into its own function to use in places where only the presence of vbt is required. Suggested-by: Jani Nikula <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/i915: Move vbt read from firmware to intel_bios.cRadhakrishna Sripada2-47/+44
VBT read from firmware is currently nested within opregion vbt read. Extract it and place it together with other vbt read mechanisms and dis-associate vbt-firmware from opregion structure. v2: Return NULL in failure cases and use a null check in intel_bios_init(Jani) Cc: Jani Nikula <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/i915: Pass size to spi_oprom_get_vbtRadhakrishna Sripada1-2/+6
spi_oprom_get_vbt will later be used to show the contents of vbt for which the size of vbt is needed. Cc: Jani Nikula <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-11drm/i915: Pass size to oprom_get_vbtRadhakrishna Sripada1-2/+6
oprom_get_vbt will later be used to show the contents of vbt for which the size of vbt is needed. v2: Avoid overuse of *size and remove dummy size variable in intel_bios_init(Jani) Cc: Jani Nikula <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.