summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-23gpu: nova-core: extract FWSEC from BIOS and patch it to run FWSEC-FRTSAlexandre Courbot
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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-23mtd: intel-dg: align 64bit read and writeAlexander Usyskin
GSC NVM controller HW errors on quad access overlapping 1K border. Align 64bit read and write to avoid readq/writeq over 1K border. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://lore.kernel.org/r/20250617145159.3803852-6-alexander.usyskin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-06-23mtd: intel-dg: register with mtdAlexander Usyskin
Register the on-die nvm device with the mtd subsystem. Refcount nvm object on _get and _put mtd callbacks. For erase operation address and size should be 4K aligned. For write operation address and size has to be 4bytes aligned. CC: Rodrigo Vivi <rodrigo.vivi@intel.com> CC: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Co-developed-by: Tomas Winkler <tomasw@gmail.com> Signed-off-by: Tomas Winkler <tomasw@gmail.com> Co-developed-by: Vitaly Lubart <lubvital@gmail.com> Signed-off-by: Vitaly Lubart <lubvital@gmail.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://lore.kernel.org/r/20250617145159.3803852-5-alexander.usyskin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-06-23mtd: intel-dg: implement access functionsAlexander Usyskin
Implement read(), erase() and write() functions. CC: Lucas De Marchi <lucas.demarchi@intel.com> CC: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Co-developed-by: Tomas Winkler <tomasw@gmail.com> Signed-off-by: Tomas Winkler <tomasw@gmail.com> Co-developed-by: Vitaly Lubart <lubvital@gmail.com> Signed-off-by: Vitaly Lubart <lubvital@gmail.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://lore.kernel.org/r/20250617145159.3803852-4-alexander.usyskin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-06-23mtd: intel-dg: implement region enumerationAlexander Usyskin
In intel-dg, there is no access to the spi controller, the information is extracted from the descriptor region. CC: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Co-developed-by: Tomas Winkler <tomasw@gmail.com> Signed-off-by: Tomas Winkler <tomasw@gmail.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://lore.kernel.org/r/20250617145159.3803852-3-alexander.usyskin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-06-23mtd: add driver for intel graphics non-volatile memory deviceAlexander Usyskin
Add auxiliary driver for intel discrete graphics non-volatile memory device. CC: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Co-developed-by: Tomas Winkler <tomasw@gmail.com> Signed-off-by: Tomas Winkler <tomasw@gmail.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://lore.kernel.org/r/20250617145159.3803852-2-alexander.usyskin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-06-23Merge drm/drm-next into drm-xe-nextRodrigo Vivi
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
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
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
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
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
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
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-23rust: sizes: add constants up to SZ_2GAlexandre Courbot
nova-core will need to use SZ_1M, so make the remaining constants available. Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-5-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23rust: make ETIMEDOUT error availableAlexandre Courbot
We will use this error in the nova-core driver. Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-4-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23Merge tag 'topic/dma-features-2025-06-23' of ↵Danilo Krummrich
https://github.com/Rust-for-Linux/linux.git DMA features for v6.17 - Clarify wording and be consistent in 'coherent' nomenclature. - Convert the read!() / write!() macros to return a Result. - Add as_slice() / write() methods in CoherentAllocation. - Fix doc-comment of dma_handle(). - Expose count() and size() in CoherentAllocation and add the corresponding type invariants. - Implement CoherentAllocation::dma_handle_with_offset().
2025-06-23rust: dma: add dma_handle_with_offset method to CoherentAllocationAlexandre Courbot
Sometimes one may want to obtain a DMA handle starting at a given offset. This can be done by adding said offset to the result of `dma_handle()`, but doing so on the client side carries the risk that the operation will go outside the bounds of the allocation. Thus, add a `dma_handle_with_offset` method that adds the desired offset after checking that it is still valid. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-3-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23rust: dma: expose the count and size of CoherentAllocationAlexandre Courbot
These properties are very useful to have (and to be used by nova-core) and should be accessible, hence add them. Additionally, add type invariants for the size of an allocation. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-2-ecf41ef99252@nvidia.com [ Slightly extend the commit message. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23rust: dma: fix doc-comment of dma_handle()Alexandre Courbot
A word was apparently missing in this sentence, hence fix it. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-1-ecf41ef99252@nvidia.com Fixes: ad2907b4e308 ("rust: add dma coherent allocator abstraction") [ Slightly expand commit subject and add 'Fixes:' tag. - Danilo ] 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ä
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ä
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ä
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ä
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ä
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ä
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ä
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ä
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ä
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-23rust: dma: add as_slice/write functions for CoherentAllocationAbdiel Janulgue
Add unsafe accessors for the region for reading or writing large blocks of data. Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250602085444.1925053-4-abdiel.janulgue@gmail.com [ Fix line length and slightly reword safety comment in doc-test of CoherentAllocation::write(); fix formatting issue. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23rust: dma: convert the read/write macros to return ResultAbdiel Janulgue
We could do better here by having the macros return `Result`, so that we don't have to wrap these calls in a closure for validation which is confusing. Co-developed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/rust-for-linux/87h63qhz4q.fsf@kernel.org/ Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@gmail.com> Link: https://lore.kernel.org/r/20250602085444.1925053-3-abdiel.janulgue@gmail.com [ Fix line length in dma_read!(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-20 20:30:14 +0000