Re: [PATCH 6/7] gpu: nova-core: falcon: allow DMA transfers to read from a framebuffer address

["Alexandre Courbot" <acourbot@nvidia.com>]

On Fri Nov 6, 2026 at 3:14 PM JST, Eliot Courtney wrote:
> On Tue Nov 3, 2026 at 7:22 PM JST, Alexandre Courbot wrote:
>> The r000 boot protocol has a load-and-execute event in which GSP-RM asks
>> the driver to load a Heavy-Secured binary from framebuffer memory into
>> the GSP falcon's memory by DMA in order to run it.
>>
>> Nova-core's falcon DMA loading method currently only supports loading
>> from a DMA object that the driver had allocated, so there is no way to
>> copy an image from framebuffer memory that an event supplied.
>>
>> Address this by making the source of a falcon DMA transfer an enum,
>> which can be either a DMA object, or a GPU framebuffer address.
>>
>> The framebuffer address source has no user yet, but will be used by the
>> r000 boot protocol.
>>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>
> [...]
>
>> @@ -626,9 +649,13 @@ fn dma_load<F: FalconFirmware<Target = E> + FalconDmaLoadable>(&self, fw: &F) ->
>>                      .with_mem_type(FalconFbifMemType::Physical)
>>              });
>>  
>
> Suggest moving the NV_PFALCON_FBIF_TRANSCFG write into dma_wr because
> once we make the source configurable (i.e. allowing vram as a source)
> it's now possible to call dma_wr with a bogus NV_PFALCON_FBIF_TRANSCFG
> setup with the wrong FalconFbifTarget (but that's determinable from
> `FalconDmaSource`).

Indeed, and actually even without the source being configuration this
should have been programmed there from the get-go! Thanks, will add a
patch for that.