Hi
Am 05.12.25 um 20:50 schrieb René Rebe:
Hi,
On 5. Dec 2025, at 20:46, Thomas Zimmermann <[email protected]> wrote:
Hi
Am 05.12.25 um 19:31 schrieb Timothy Pearson:
----- Original Message -----
From: "René Rebe" <[email protected]>
To: [email protected]
Cc: "dri-devel" <[email protected]>, "linux-kernel"
<[email protected]>, "Dave Airlie"
<[email protected]>, "Timothy Pearson" <[email protected]>
Sent: Friday, December 5, 2025 9:14:59 AM
Subject: Re: [PATCH] drm/ast: Fix big-endian support
Hello Thomas,
On Wed, 3 Dec 2025 10:40:17 +0100, Thomas Zimmermann <[email protected]>
wrote:
[2]
https://gitlab.freedesktop.org/drm/misc/kernel/-/blob/drm-misc-next-2025-12-01-1/drivers/gpu/drm/ast/ast_mode.c?ref_type=tags#L559
[3]
https://gitlab.freedesktop.org/drm/misc/kernel/-/blob/drm-misc-next-2025-12-01-1/drivers/gpu/drm/ast/ast_cursor.c?ref_type=tags#L209
+ case DRM_FORMAT_RGB565:
+ ast_set_index_reg_mask(ast, AST_IO_VGACRI, AST_IO_VGACRA2, 0x3f,
0x40);
+ break;
+ case DRM_FORMAT_XRGB8888
While working on it I discovered that the Big-Endian byte-swapping
bits do apparently not just-work on a newer AST2400 in our Power 8
while my initial patch did work as tested with an AST2200 in the Sun
T4-1 :-/
In the upcoming v6.19-rc1, ast will support per-chip quirks. So we can control
this by chip version, if necessary
Maybe that is what Timothy meant with "This is due to a ppc64 hardware
quirk, which when combined with a hardware design fault in the AST2500
VGA controller results in a need to use software-based red-blue
channel swapping." [1]
Is there a way to simply specify the frame-buffer as BGRX8888? In a
quick test the drm layer complaint about "not supported" and "no
compatible format found"?
I've been all around that loop. You can't do that -- the fb code has no idea
how to drive such a framebuffer, and elsewhere in the kernel it's made clear
that the GPU driver *must* provide a RGBX8888 linear framebuffer if the Linux
fb code is going to be able to display a console.
Does the Sun T4 CPU perform automatic byte swapping on PCI[e] data
transactions? That might be the difference; POWER performs the byte swapping,
and since the ASpeed device is broken in BE mode we can't swap back by setting
the BE register bit in the AST GPU hardware.
Fun fact -- it'll sorta work on the framebuffer side, but we lose the entire control BAR
in the process. ASpeed seems OK with this, they just say something along the lines of
"oh, BE is not supported despite our documentation" :facepalm:
On the 2400-and-onwards models, ast could set
drm_device.mode_config.quirk_addfb_prefer_host_byte_order. If set, the format
lookup will select a different format on BE machines. [1] For example
requesting XRGB8888 returns BGRX8888 instead. If ast later sees such a format
in the atomic_update code, it could transparently swap bytes when writing out
pixels to the video memory. IIRC this works transparently to DRM clients and
fbcon. I think this would be the preferred way of fixing the issue.
Uff, I get better than nothing ;-)
Well, you can set the quirk in mode config. And then in
ast_handle_damage(), you'll require a switch for the big-endian formats. [1]
ast_handle_damage(...)
{
...
switch (fb->format->format) {
default:
drm_fb_memcyp()
break;
case DRM_FORMAT_BGRX8888:
case DRM_FORMAT_RGB565 | DRM_FORMAT_BIG_ENDIAN:
/* Swap bytes on big-endian formats */
drm_fb_swab(dst, fb->pitches, src, fb, clip, false,
fmtcnv_state);
break;
}
}
You can get that final argument fmtcnv_state from the DMR shadow-plane
state. [2]
[1]
https://elixir.bootlin.com/linux/v6.18/source/drivers/gpu/drm/ast/ast_mode.c#L549
[2]
https://elixir.bootlin.com/linux/v6.18/source/drivers/gpu/drm/ast/ast_mode.c#L558
Does that fix the color corruption?
[1]
https://elixir.bootlin.com/linux/v6.18/source/drivers/gpu/drm/drm_fourcc.c#L123
For the pre-2400 chips, I suggest to fix this problem with the hardware byte
swapping if possible. That seems like the correct approach.
I had re-done the code as you suggested, should I send a v2 as tested on the
sparc64 t4-1 and we quirk later, non working chips or ppc64 later?
Not sure what you mean. If splitting by chip model is too complicated,
we can also do only the software variant that works with all chips.
Thanks for sticking with it.
Best regards
Thomas
René
Best regards
Thomas
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
