[PATCH v1] Support Intel Xe GPU dirver Porting on RISC-V Architecture

[Simon Richter]

Hi,

On 7/16/25 16:00, zhangzhijie wrote:

>>>      inb/outb speccial wire not support on other ARCH.
>> Are you sure these aren't memory mapped?

>      yes, few arch not has this memory map(SVGAlib.) on .

Is it missing from the root complex IP instantation, so the logic does 
not exist, or just not enabled, which could be fixed by doing the same 
thing as POWER?

The fewer differences there are between platforms, the better.

>> [1] https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1824
>      Got that same with issue link. thanks

That is also an inb/outb pair. If you got it to compile, then you have a 
definition of inb/outb for your platform, and the next step is checking 
where that came from and how it is supposed to work, and the same 
definition can be used to compile the code you proposed to make conditional.

That is a question for the people building your PCIe interface though.

>      I have question that will VGA_CONSOLE support on non-x64 
> architecture? using CONFIG_X86/X86_64 means only support for X86 
> archtecture

VGA_CONSOLE is text mode, with font rendering done by the graphics card.

That requires that the I/O ports in the ranges 0x3bb0 to 0x3bb and 0x3c0 
to 0x3df and memory accesses from 0xa0000 to 0xbffff are forwarded to 
the card (i.e. all PCI(e) bridges above the card need to have the VGA 
bit set, and the root complex needs to generate these accesses -- so 
there needs to be memory mappings in the root complex for legacy I/O 
ports (so working inb/outb) and for the 128kB VGA aperture.

Pretty much nobody on x86 uses VGA_CONSOLE these days, instead they use 
kernel modesetting to switch to a graphical mode, and render into the 
framebuffer with whatever method is available -- CPU and maybe some 
device specific acceleration in the kernel, or Mesa and full 3D 
acceleration in X and Wayland.

So I'd turn off VGA_CONSOLE, that also seems to avoid issues when the 
non-generic drivers take over (that is what the code in the linked issue 
does -- I haven't fully understood the problem there, but someone 
deliberately added this, and I'd expect that they understood it enough 
to say that this was necessary.

If someone from Intel knows more, this information would be great to 
have, so I can tell how much time to invest on fixing this for the 
various platforms (if that is the source of the 400,000 interrupts per 
second I'm seeing, then it gets higher priority than if it is only 
relevant if someone activated text mode before).

    Simon