Some parts of the GSP boot process are chip-specific actions, whereas others (like sending the initial post-boot messages) deal directly with the working GSP.
Reorganize the boot code a bit so the chipset-specific parts are clumped together, which will make their extraction into a HAL easier. This has no effect on the GSP boot process. Reviewed-by: Eliot Courtney <[email protected]> Signed-off-by: Alexandre Courbot <[email protected]> --- drivers/gpu/nova-core/gsp/boot.rs | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/nova-core/gsp/boot.rs b/drivers/gpu/nova-core/gsp/boot.rs index e75c4b235aab..2e1401cd6171 100644 --- a/drivers/gpu/nova-core/gsp/boot.rs +++ b/drivers/gpu/nova-core/gsp/boot.rs @@ -187,18 +187,13 @@ pub(crate) fn boot( let fb_layout = FbLayout::new(chipset, bar, &gsp_fw)?; dev_dbg!(dev, "{:#x?}\n", fb_layout); + let wpr_meta = Coherent::init(dev, GFP_KERNEL, GspFwWprMeta::new(&gsp_fw, &fb_layout))?; + // FWSEC-FRTS is not executed on chips where the FRTS region size is 0 (e.g. GA100). if !fb_layout.frts.is_empty() { Self::run_fwsec_frts(dev, chipset, gsp_falcon, bar, &bios, &fb_layout)?; } - let wpr_meta = Coherent::init(dev, GFP_KERNEL, GspFwWprMeta::new(&gsp_fw, &fb_layout))?; - - self.cmdq - .send_command_no_wait(bar, commands::SetSystemInfo::new(pdev))?; - self.cmdq - .send_command_no_wait(bar, commands::SetRegistry::new())?; - gsp_falcon.reset(bar)?; let libos_handle = self.libos.dma_handle(); let (mbox0, mbox1) = gsp_falcon.boot( @@ -227,6 +222,11 @@ pub(crate) fn boot( dev_dbg!(pdev, "RISC-V active? {}\n", gsp_falcon.is_riscv_active(bar),); + self.cmdq + .send_command_no_wait(bar, commands::SetSystemInfo::new(pdev))?; + self.cmdq + .send_command_no_wait(bar, commands::SetRegistry::new())?; + // Create and run the GSP sequencer. let seq_params = GspSequencerParams { bootloader_app_version: gsp_fw.bootloader.app_version, -- 2.54.0
