Re: [PATCH] drm/radeon: bypass no_64bit_msi with new msi64 parameter

"Arnd Bergmann" <[email protected]>
Newsgroups dev.linux.lists.sophgo,org.freedesktop.lists.amd-gfx,org.freedesktop.lists.dri-devel,org.infradead.lists.linux-riscv,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On Sat, Dec 20, 2025, at 17:33, Han Gao wrote:
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 87fd6255c114..53af28494c03 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -249,6 +249,10 @@ int radeon_cik_support = -1;
>  MODULE_PARM_DESC(cik_support, "CIK support (1 = enabled, 0 = disabled, 
> -1 = default)");
>  module_param_named(cik_support, radeon_cik_support, int, 0444);
> 
> +int radeon_msi64;
> +MODULE_PARM_DESC(msi64, "MSI64 support (1 = enabled, 0 = disabled)");
> +module_param_named(msi64, radeon_msi64, int, 0444);
> +

As with the hda-intel patch, this should not be a module argument,
but we should have the kernel figure out what to do itself.

> diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c 
> b/drivers/gpu/drm/radeon/radeon_irq_kms.c
> index 9961251b44ba..62eb5a6968ff 100644
> --- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
> @@ -250,7 +250,7 @@ static bool radeon_msi_ok(struct radeon_device 
> *rdev)
>  	 * of address for "64-bit" MSIs which breaks on some platforms, 
> notably
>  	 * IBM POWER servers, so we limit them
>  	 */
> -	if (rdev->family < CHIP_BONAIRE) {
> +	if (rdev->family < CHIP_BONAIRE && !radeon_msi64) {
>  		dev_info(rdev->dev, "radeon: MSI limited to 32-bit\n");
>  		rdev->pdev->no_64bit_msi = 1;

According to the comment above it, the device can apparently
do 40-bit addressing but not use the entire 64-bit space.

I assume the SG2042 chip has the irqchip somewhere above the
32-bit line but below the 40-bit line, so it ends up working.

I wonder if the msi_verify_entries() function should check
against dev->coherent_dma_mask instead of checking the
upper 32 bits for being nonzero, that probably gives you
the desired behavior.

     Arnd
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.