public inbox for sophgo@lists.linux.dev
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Vivian Wang <wangruikang@iscas.ac.cn>,
	Arnd Bergmann <arnd@arndb.de>, Han Gao <gaohan@iscas.ac.cn>,
	Alex Deucher <alexander.deucher@amd.com>,
	Dave Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>
Cc: Han Gao <rabenda.cn@gmail.com>,
	linux-riscv@lists.infradead.org, sophgo@lists.linux.dev
Subject: Re: [PATCH] drm/radeon: bypass no_64bit_msi with new msi64 parameter
Date: Tue, 6 Jan 2026 16:34:12 +0100	[thread overview]
Message-ID: <b4fc76aa-290b-4cdf-aff7-30ccc9cb1f44@amd.com> (raw)
In-Reply-To: <5ea0ff13-04b3-4b2a-80e2-4f87146d00d5@iscas.ac.cn>

Hi Vivian,

adding Bjorn as well.

On 12/23/25 16:31, Vivian Wang wrote:
> Hi Christian,
> 
> I have a question about this 40-bit restriction.
> 
> On 12/23/25 22:55, Christian König wrote:
>> On 12/22/25 22:32, Arnd Bergmann wrote:
>>> On Sat, Dec 20, 2025, at 17:33, Han Gao wrote:
>>> [...]
>>>> 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.
>> Again completely agree, that sounds like a plan to me.
>>
>> IIRC the modified code here is basically just a workaround because the MSI control dword on older radeon HW was not setup correctly.
> 
> Does this mean that on Bonaire and onwards, MSI can reach full 64-bit
> space, while DMA still only does 40-bit?
> (drivers/gpu/drm/radeon/radeon_device.c sets DMA mask to at most 40 bits.)

I need to double check with the HW guys and/or documentation, but I don't think so.

As far as I know the bus interface of the HW can only handle 40bits of address space. Later HW generations extend that to 44 or 48bits, but never the full 64bits.

I could be that the interrupt handler block for the MSI functionality has a special handling, but I strongly doubt that.

> 
> If so, checking coherent_dma_mask would be wrong for those devices.
> 
> Do you think maybe it would be safer to introduce a msi_addr_mask for
> occasions like these? We can have msi_addr_mask = DMA_BIT_MASK(40) for
> pre-Bonaire, and then the ppc PCI stuff can check the mask and see if
> it's usable. Probably something similar for hda.

That sounds like it would be rather clean, but it might be overkill.

As far as I know we have exactly one PCIe device (the pre-Bonaire HW generation) which messed up the bit in the MSI descriptor and so can only do 32bit MSI while the rest of the device can do 64bit accesses.

A good part of the confusion is comes because the PCIe spec is a bit unspecific what that 64bit support actually means. The original intent was probably to indicate 64bit address space support to operating systems.

But in reality devices only indicate that they can issue 64bit read and write requests but can only handle 40/44/48 or 57 bit addresses.

It's a bit messed up but that's what it is.

Regards,
Christian.

> 
> Vivian "dramforever" Wang
> 


      reply	other threads:[~2026-01-06 15:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-20 16:33 [PATCH] drm/radeon: bypass no_64bit_msi with new msi64 parameter Han Gao
2025-12-22 21:32 ` Arnd Bergmann
2025-12-23 14:55   ` Christian König
2025-12-23 15:31     ` Vivian Wang
2026-01-06 15:34       ` Christian König [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b4fc76aa-290b-4cdf-aff7-30ccc9cb1f44@amd.com \
    --to=christian.koenig@amd.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gaohan@iscas.ac.cn \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=rabenda.cn@gmail.com \
    --cc=simona@ffwll.ch \
    --cc=sophgo@lists.linux.dev \
    --cc=wangruikang@iscas.ac.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox