----- 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 :-/
>
> 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:
