summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorLines
2025-06-23gpu: nova-core: load and run FWSEC-FRTSAlexandre Courbot-13/+136
With all the required pieces in place, load FWSEC-FRTS onto the GSP falcon, run it, and check that it successfully carved out the WPR2 region out of framebuffer memory. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-23-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: extract FWSEC from BIOS and patch it to run FWSEC-FRTSAlexandre Courbot-15/+434
The FWSEC firmware needs to be extracted from the VBIOS and patched with the desired command, as well as the right signature. Do this so we are ready to load and run this firmware into the GSP falcon and create the FRTS region. [joelagnelf@nvidia.com: give better names to FalconAppifHdrV1's fields] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-22-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: add types for patching firmware binariesAlexandre Courbot-0/+64
Some of the firmwares need to be patched at load-time with a signature. Add a couple of types and traits that sub-modules can use to implement this behavior, while ensuring that the correct kind of signature is applied to the firmware. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-21-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: compute layout of the FRTS regionAlexandre Courbot-2/+224
FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: vbios: Add support for FWSEC ucode extractionJoel Fernandes-11/+304
Using the support for navigating the VBIOS, add support to extract vBIOS ucode data required for GSP to boot. The main data extracted from the vBIOS is the FWSEC-FRTS firmware which runs on the GSP processor. This firmware runs in high secure mode, and sets up the WPR2 (Write protected region) before the Booter runs on the SEC2 processor. Tested on my Ampere GA102 and boot is successful. Cc: Alexandre Courbot <acourbot@nvidia.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Shirish Baskaran <sbaskaran@nvidia.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Timur Tabi <ttabi@nvidia.com> Cc: Ben Skeggs <bskeggs@nvidia.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> [ acourbot@nvidia.com: remove now-unneeded Devres acquisition ] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-19-ecf41ef99252@nvidia.com [ Re-format and use markdown in comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23drm/xe/compat: remove old pcode compat interfaceJani Nikula-36/+2
With display code using the struct drm_device based pcode interface, we can drop the old pcode compat interface. We can also drop the __compat_uncore_to_tile() helper from intel_uncore.h compat header. Turns out a couple of headers depended on the intel_uncore.h include via intel_pcode.h. Fix them. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/948016a031dcb2acef0c97071aac09fa49613e07.1750678991.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/i915/dram: switch to struct drm_device based pcode interfaceJani Nikula-2/+2
With the struct drm_device based pcode interface in place in both i915 and xe, we can switch dram code to use that. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/e0d74a3317cc61d1cbb096b962cfbd7c60f038d4.1750678991.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/i915/display: switch to struct drm_device based pcode interfaceJani Nikula-76/+58
With the struct drm_device based pcode interface in place in both i915 and xe, we can switch display code to use that, and ditch a number of struct drm_i915_private uses. Also drop the dependency on i915_drv.h from a couple of files. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/f948fad1b8208522e15140692c17cf493ef305d9.1750678991.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/xe/pcode: add struct drm_device based interfaceJani Nikula-1/+37
In preparation for dropping the dependency on struct intel_uncore or struct xe_tile from display code, add a struct drm_device based interface to pcode. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/eeaa9cc8438caab2e22f9cb2142fbc18cc0fd861.1750678991.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/i915/pcode: add struct drm_device based interfaceJani Nikula-0/+34
In preparation for dropping the dependency on struct intel_uncore from display code, add a struct drm_device based interface to pcode. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/e4ee176ca5454cfc636cbe71feb9f55d9e91f4ea.1750678991.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/i915/pcode: drop fast wait from snb_pcode_write_timeout()Jani Nikula-15/+9
Only use the ms granularity wait in snb_pcode_write_timeout(), primarily to better align with the xe driver, which also only has the millisecond wait. Use an arbitrary 250 us fast wait before the specified ms wait, and have snb_pcode_write() default to 1 ms. This means snb_pcode_write() and snb_pcode_write_timeout() will always be sleeping functions. There should not be any atomic users for pcode writes though, and any display code using pcode via xe has already been non-atomic. The uncore wait will do a might_sleep() annotation that should catch any problems. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/ba86280f53cea2d020308db35f1ecbd615d07d8a.1750678991.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/connector: move HDR sink metadata to display infoJani Nikula-12/+13
Information parsed from the display EDID should be stored in display info. Move HDR sink metadata there. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250519112900.1383997-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23gpu: nova-core: vbios: Add support to look up PMU table in FWSECJoel Fernandes-2/+180
The PMU table in the FWSEC image has to be located to locate the start of the Falcon ucode in the same or another FWSEC image. Add support for the same. Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-18-ecf41ef99252@nvidia.com [ Re-format and use markdown in comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: vbios: Add base support for VBIOS construction and iterationJoel Fernandes-2/+688
Add support for navigating the VBIOS images required for extracting ucode data for GSP to boot. Later patches will build on this. Debug log messages will show the BIOS images: [102141.013287] NovaCore: Found BIOS image at offset 0x0, size: 0xfe00, type: PciAt [102141.080692] NovaCore: Found BIOS image at offset 0xfe00, size: 0x14800, type: Efi [102141.098443] NovaCore: Found BIOS image at offset 0x24600, size: 0x5600, type: FwSec [102141.415095] NovaCore: Found BIOS image at offset 0x29c00, size: 0x60800, type: FwSec Cc: Alexandre Courbot <acourbot@nvidia.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Shirish Baskaran <sbaskaran@nvidia.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Timur Tabi <ttabi@nvidia.com> Cc: Ben Skeggs <bskeggs@nvidia.com> [ acourbot@nvidia.com: fix clippy warnings, read_more() function ] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-17-ecf41ef99252@nvidia.com [ Replace extend_with() and copy_from_slice() with extend_from_slice(); re-format and use markdown in comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: firmware: add ucode descriptor used by FWSEC-FRTSAlexandre Courbot-0/+45
FWSEC-FRTS is the first firmware we need to run on the GSP falcon in order to initiate the GSP boot process. Introduce the structure that describes it. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-16-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: add falcon register definitions and base codeAlexandre Courbot-0/+916
Booting the GSP on Ampere requires an intricate dance between the GSP and SEC2 falcons, where the GSP starts by running the FWSEC firmware to create the WPR2 region , and then SEC2 loads the actual RISC-V firmware into the GSP. Add the common Falcon code and HAL for Ampere GPUs, and instantiate the GSP and SEC2 Falcons that will be required to perform that dance and boot the GSP. Thanks to Ben Skeggs for pointing out an important bug in the memory scrubbing code that could lead to a race condition and ultimately a failure to boot the GSP! Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-15-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: register sysmem flush pageAlexandre Courbot-2/+215
Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: add DMA object structAlexandre Courbot-0/+62
Since we will need to allocate lots of distinct memory chunks to be shared between GPU and CPU, introduce a type dedicated to that. It is a light wrapper around CoherentAllocation. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-13-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: wait for GFW_BOOT completionAlexandre Courbot-1/+72
Upon reset, the GPU executes the GFW (GPU Firmware) in order to initialize its base parameters such as clocks. The driver must ensure that this step is completed before using the hardware. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-12-ecf41ef99252@nvidia.com [ Slightly adjust comments in wait_gfw_boot_completion(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23drm/xe/nvm: add support for non-posted eraseReuven Abliyev-0/+25
Erase command is slow on discrete graphics storage and may overshot PCI completion timeout. BMG introduces the ability to have non-posted erase. Add driver support for non-posted erase with polling for erase completion. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Reuven Abliyev <reuven.abliyev@intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://lore.kernel.org/r/20250617145159.3803852-9-alexander.usyskin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-06-23drm/xe/nvm: add support for access modeAlexander Usyskin-5/+41
Check NVM access mode from GSC FW status registers and overwrite access status read from SPI descriptor, if needed. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://lore.kernel.org/r/20250617145159.3803852-8-alexander.usyskin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-06-23drm/xe/nvm: add on-die non-volatile memory deviceAlexander Usyskin-0/+140
Enable access to internal non-volatile memory on DGFX with GSC/CSC devices via a child device. The nvm child device is exposed via auxiliary bus. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://lore.kernel.org/r/20250617145159.3803852-7-alexander.usyskin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-06-23Merge drm/drm-next into drm-xe-nextRodrigo Vivi-8880/+18661
Catch up on i915 changes to be able to include mtd driver for both xe and i915. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-06-23gpu: nova-core: add helper function to wait on conditionAlexandre Courbot-0/+29
While programming the hardware, we frequently need to busy-wait until a condition (like a given bit of a register to switch value) happens. Add a basic `wait_on` helper function to wait on such conditions expressed as a closure, with a timeout argument. This is temporary as we will switch to `read_poll_timeout` [1] once it is available. Link: https://lore.kernel.org/lkml/20250220070611.214262-8-fujita.tomonori@gmail.com/ [1] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-11-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: increase BAR0 size to 16MBAlexandre Courbot-2/+2
The Turing+ register address space spans over that range, so increase it as future patches will access more registers. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-10-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: allow register aliasesAlexandre Courbot-2/+38
Some registers (notably scratch registers) don't have a definitive purpose, but need to be interpreted differently depending on context. Expand the register!() macro to support a syntax indicating that a register type should be at the same offset as another one, but under a different name, and with different fields and documentation. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-9-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: expose the offset of each register as a type constantAlexandre Courbot-3/+8
Although we want to access registers using the provided methods, it is sometimes needed to use their raw offset, for instance when working with a register array. Expose the offset of each register using a type constant to avoid resorting to hardcoded values. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-8-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: add delimiter for helper rules in register!() macroAlexandre Courbot-0/+2
This macro is pretty complex, and most rules are just helper, so add a delimiter to indicate when users only interested in using it can stop reading. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-7-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: use absolute paths in register!() macroAlexandre Courbot-6/+6
Fix the paths that were not absolute to prevent a potential local module from being picked up. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-6-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23drm/i915/dmc: Do not enable the pipe DMC on TGL when PSR is possibleVille Syrjälä-0/+20
On TGL/derivatives the pipe DMC state is lost when PG1 is disabled, and the main DMC does not restore any of it. This means the state will also be lost during PSR+DC5/6. It seems safest to not even enable the pipe DMC in that case (the main DMC does restore the pipe DMC enable bit in PIPEDMC_CONTROL_A for some reason). Since pipe DMC is only needed for "fast LACE" on these platforms we aren't actually losing anything here. In the future if we do want to enable "fast LACE" we'll just have to remember that it won't be compatible with PSR. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-10-ville.syrjala@linux.intel.com
2025-06-23drm/i915/dmc: Pass crtc_state to intel_dmc_{enable,disable}_pipe()Ville Syrjälä-9/+24
I'll need to examine the crtc state during intel_dmc_enable_pipe(). To that end pass the whole crtc into intel_dmc_{enable,disable}_pipe(). Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-9-ville.syrjala@linux.intel.com
2025-06-23drm/i915/dmc: Assert DMC is loaded harderVille Syrjälä-18/+48
Currently we have some asserts to make sure the main DMC has been loaded. Add similar asserts for the pipe DMCs. And we might as well just check all the mmio registers the firmware has asked us to initialize. That also covers the hardcoded SSP/HTP registers we were checking for the main DMC. TODO: Maybe always configure DMC_EVT_CTL_ENABLE the way the firmware has it set so that we wouldn't need to special case in the assert? v2: Also assert in intel_dmc_load_program() Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-8-ville.syrjala@linux.intel.com
2025-06-23drm/i915/dmc: Reload pipe DMC MMIO registers for pipe C/D on various platformsVille Syrjälä-6/+61
On ADL/MTL pipe DMC MMIO state evidently lives in PG0. The main DMC saves/restores it for pipes A/B, but for pipes C/D we have to do it in the driver. On PTL the situation is mostly the same, except the main DMC firmware doesn't seem to have the PG0 save/restore code anymore, and instead the hardware (or maybe Punit?) seems to take care of this job now. Pipes C/D still need a manual restore by the driver. On LNL I've been unable to lose any pipe DMC state, despite the main DMC firmware still implementing the PG0 save/restore for pipes A/B. Not sure what's going on here. On DG2 I've also not been able to lose the pipe DMC state. DG2 doesn't support DC6, so that might explain part of it. But even DC9 doesn't make a difference here. Perhaps PG0 is just always on for DG2? BMG I've not tested at all. The main DMC firmware does appaer to implement the PG0 pipe A/B save/restore logic. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-7-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2025-06-23drm/i915/dmc: Reload pipe DMC state on TGL when enabling pipe AVille Syrjälä-0/+9
On TGL/derivatives the entire pipe DMC state (program + MMIO) is lost when PG1 is disabled, and the main DMC does not restore any of it. Reload the state when enabling a pipe. The other option would be to not load the pipe DMC at all since it's only needed for "fast LACE" (which we don't use) on these platforms. But let's keep it around just in case we ever decide that "fast LACE" is something we want. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-6-ville.syrjala@linux.intel.com
2025-06-23drm/i915/dmc: Extract dmc_load_program()Ville Syrjälä-36/+42
We'll be needing to reload the program for individual DMCs. To make that possible pull the code to load the program for a single DMC into a new function. This does change the order of things during init/resume a bit; previously we loaded the program RAM for all DMCs first, and then loaded the MMIO registers for all DMCs. Now those operations will be interleaved between different DMCs. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-5-ville.syrjala@linux.intel.com
2025-06-23drm/i915/dmc: Shuffle code aroundVille Syrjälä-72/+72
Shuffle the DMC_EVT_CTL related stuff around once more. We'll need this stuff during intel_dmc_enable_pipe(), and this lets us avoid forward declarations. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-4-ville.syrjala@linux.intel.com
2025-06-23drm/i915/dmc: Parametrize MTL_PIPEDMC_GATING_DISVille Syrjälä-3/+3
The MTL+ pipe DMC clock gating bits can be parametrized. Make it so. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-3-ville.syrjala@linux.intel.com
2025-06-23drm/i915/dmc: Limit pipe DMC clock gating w/a to just ADL/DG2/MTLVille Syrjälä-1/+1
Supposedly nothing post-MTL (even BMG) needs the pipe DMC clock gating w/a (Wa_16015201720), so don't apply it. TODO: check if the ADL/DG2 "clock gating needed during DMC loading" part is actually needed, not seeing anything in the docs about it... Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-2-ville.syrjala@linux.intel.com
2025-06-23drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUSImre Deak-1/+1
Reading DPCD registers has side-effects in general. In particular accessing registers outside of the link training register range (0x102-0x106, 0x202-0x207, 0x200c-0x200f, 0x2216) is explicitly forbidden by the DP v2.1 Standard, see 3.6.5.1 DPTX AUX Transaction Handling Mandates 3.6.7.4 128b/132b DP Link Layer LTTPR Link Training Mandates Based on my tests, accessing the DPCD_REV register during the link training of an UHBR TBT DP tunnel sink leads to link training failures. Solve the above by using the DP_LANE0_1_STATUS (0x202) register for the DPCD register access quirk. Cc: <stable@vger.kernel.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250605082850.65136-2-imre.deak@intel.com (cherry picked from commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2025-06-23drm/i915/snps_hdmi_pll: Fix 64-bit divisor truncation by using div64_u64Ankit Nautiyal-2/+2
DIV_ROUND_CLOSEST_ULL uses do_div(), which expects a 32-bit divisor. When passing a 64-bit constant like CURVE2_MULTIPLIER, the value is silently truncated to u32, potentially leading to incorrect results on large divisors. Replace DIV_ROUND_CLOSEST_ULL with DIV64_U64_ROUND_CLOSEST which correctly handles full 64-bit division. v2: Use DIV64_U64_ROUND_CLOSEST instead of div64_u64 macro. (Jani) Fixes: 5947642004bf ("drm/i915/display: Add support for SNPS PHY HDMI PLL algorithm for DG2") Reported-by: Vas Novikov <vasya.novikov@gmail.com> Closes: https://lore.kernel.org/all/8d7c7958-9558-4c8a-a81a-e9310f2d8852@gmail.com/ Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Vas Novikov <vasya.novikov@gmail.com> Cc: stable@vger.kernel.org # v6.15+ Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250618130951.1596587-2-ankit.k.nautiyal@intel.com (cherry picked from commit b300a175a11e6a934d728317dc39787723cc7917) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2025-06-23drm/ci: Add jobs to run KUnit testsVignesh Raman-0/+55
Add jobs to run KUnit tests using tools/testing/kunit/kunit.py tool. Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Acked-by: Helen Koike <helen.fornazier@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250623085033.39680-3-vignesh.raman@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-23drm/ci: Add jobs to validate devicetreesVignesh Raman-0/+106
Add jobs to run dt_binding_check and dtbs_check. If warnings are seen, exit with a non-zero error code while configuring them as warning in the GitLab CI pipeline. Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Acked-by: Helen Koike <helen.fornazier@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250623085033.39680-2-vignesh.raman@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-23drm/bochs: Add support for drm_panicRyosuke Yasuoka-0/+19
Add drm_panic module for bochs drm so that panic screen can be displayed on panic. Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250613132023.106946-1-ryasuoka@redhat.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-06-23drm/i915/panel: make panel funcs staticJani Nikula-1/+1
The drm panel funcs should be static, fix it. Fixes: 3fdd5bfbd638 ("drm/i915/panel: register drm_panel and call prepare/unprepare for ICL+ DSI") Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20250612124617.626958-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm: writeback: Fix drm_writeback_connector_cleanup signatureLouis Chauvet-3/+4
The drm_writeback_connector_cleanup have the signature: static void drm_writeback_connector_cleanup( struct drm_device *dev, struct drm_writeback_connector *wb_connector) But it is stored and used as a drmres_release_t typedef void (*drmres_release_t)(struct drm_device *dev, void *res); While the current code is valid and does not produce any warning, the CFI runtime check (CONFIG_CFI_CLANG) can fail because the function signature is not the same as drmres_release_t. In order to fix this, change the function signature to match what is expected by drmres_release_t. Fixes: 1914ba2b91ea ("drm: writeback: Create drmm variants for drm_writeback_connector initialization") Suggested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20250429-drm-fix-writeback-cleanup-v2-1-548ff3a4e284@bootlin.com Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
2025-06-23Merge drm/drm-next into drm-intel-nextJani Nikula-4799/+15540
Sync with drm_panel changes from drm-misc-next, and xe driver changes from drm-xe-next. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/xe/display: read PCON capability only when presentChaitanya Kumar Borah-0/+3
Avoid reading the PCON capabilities redundantly on non-branch devices. v2: - Make commit description more accurate. (Imre) - Clear intel_dp->pcon_dsc_dpcd irrespective of presense of PCON. (Imre) Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250619042629.3980244-1-chaitanya.kumar.borah@intel.com
2025-06-23Merge 6.16-rc3 into driver-core-nextGreg Kroah-Hartman-232/+660
We need the driver-core fixes that are in 6.16-rc3 into here as well to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-23Merge tag 'drm-intel-next-2025-06-18' of ↵Dave Airlie-5206/+6287
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next drm/i915 feature pull for v6.17: Features and functionality: - Add support for DSC fractional link bpp on DP MST (Imre) - Add support for simultaneous Panel Replay and Adaptive Sync (Jouni) - Add support for PTL+ double buffered LUT registers (Chaitanya, Ville) - Add PIPEDMC event handling in preparation for flip queue (Ville) Refactoring and cleanups: - Rename lots of DPLL interfaces to unify them (Suraj) - Allocate struct intel_display dynamically (Jani) - Abstract VLV IOSF sideband better (Jani) - Use str_true_false() helper (Yumeng Fang) - Refactor DSB code in preparation for flip queue (Ville) - Use drm_modeset_lock_assert_held() instead of open coding (Luca) - Remove unused arg from skl_scaler_get_filter_select() (Luca) - Split out a separate display register header (Jani) - Abstract DRAM detection better (Jani) - Convert LPT/WPT SBI sideband to struct intel_display (Jani) Fixes: - Fix DSI HS command dispatch with forced pipeline flush (Gareth Yu) - Fix BMG and LNL+ DP adaptive sync SDP programming (Ankit) - Fix error path for xe display workqueue allocation (Haoxiang Li) - Disable DP AUX access probe where not required (Imre) - Fix DKL PHY access if the port is invalid (Luca) - Fix PSR2_SU_STATUS access on ADL+ (Jouni) - Add sanity checks for porch and sync on BXT/GLK DSI (Ville) DRM core changes: - Change AUX DPCD access probe address (Imre) - Refactor EDID quirks, amd make them available to drivers (Imre) - Add quirk for DPCD access probe (Imre) - Add DPCD definitions for Panel Replay capabilities (Jouni) Merges: - Backmerges to sync with v6.15-rcs and v6.16-rc1 (Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/fff9f231850ed410bd81b53de43eff0b98240d31@intel.com
2025-06-22rust: enable `clippy::cast_lossless` lintTamir Duberstein-4/+4
Before Rust 1.29.0, Clippy introduced the `cast_lossless` lint [1]: > Rust’s `as` keyword will perform many kinds of conversions, including > silently lossy conversions. Conversion functions such as `i32::from` > will only perform lossless conversions. Using the conversion functions > prevents conversions from becoming silently lossy if the input types > ever change, and makes it clear for people reading the code that the > conversion is lossless. While this doesn't eliminate unchecked `as` conversions, it makes such conversions easier to scrutinize. It also has the slight benefit of removing a degree of freedom on which to bikeshed. Thus apply the changes and enable the lint -- no functional change intended. Link: https://rust-lang.github.io/rust-clippy/master/index.html#cast_lossless [1] Suggested-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/all/D8ORTXSUTKGL.1KOJAGBM8F8TN@proton.me/ Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Acked-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Acked-by: Jocelyn Falempe <jfalempe@redhat.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250615-ptr-as-ptr-v12-5-f43b024581e8@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
generated by cgit v1.2.3 (git 2.46.0) at 2026-05-09 22:21:57 +0000