qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Linux AMBA-CLCD driver no longer works with Qemu versatilepb target.


From: Peter Maydell
Subject: Re: Linux AMBA-CLCD driver no longer works with Qemu versatilepb target. What to do?
Date: Fri, 9 Feb 2024 17:18:00 +0000

On Fri, 9 Feb 2024 at 16:53, Christopher Davies
<cdavies@28.8bpsmodem.com> wrote:
> I've been down a bit of a rabbit hole trying to get the Linux AMBA-CLCD 
> driver for versatilepb target's graphics to work with modern Linux kernels. 
> After a good deal of reading of both the Linux kernel code and the qemu code, 
> I discovered why it won't work and why it probably has never worked since the 
> transition to devicetree in the kernel about a decade ago.
>
> The driver chooses between PL110 and PL111 mode by taking the identifier from 
> the AMBA bus:
>
> if (amba_manf(fb->dev) == 0x41 && amba_part(fb->dev) == 0x111) {
> fb->off_ienb = CLCD_PL111_IENB;
> fb->off_cntl = CLCD_PL111_CNTL;
> } else {
> fb->off_ienb = CLCD_PL110_IENB;
> fb->off_cntl = CLCD_PL110_CNTL;
> }

This indeed doesn't sound right -- it ought to use a
dtb compatible property to indicate that it's the weird versatilepb
variant.

> While Qemu thinks that the PL110_versatile ought to have the PL110 device ID, 
> but the PL111 behaviour.
>
> static const unsigned char *idregs[] = {
>     pl110_id,
>     /* The ARM documentation (DDI0224C) says the CLCDC on the Versatile board
>      * has a different ID (0x93, 0x10, 0x04, 0x00, ...). However the hardware
>      * itself has the same ID values as a stock PL110, and guests (in
>      * particular Linux) rely on this. We emulate what the hardware does,
>      * rather than what the docs claim it ought to do.
>      */
>     pl110_id,
>     pl111_id
> };
>
> So the Linux driver writes the wrong control register and the device is never 
> enabled.
>
> I'm at a loss to know what to do about this. This hardware emulation worked 
> with pre-devicetree kernels, and possibly making this change will break that, 
> I really don't know. I also don't own the real hardware so I can't observe 
> what the real behaviour is.

The real hardware is almost all going to be in landfill at this
point, I'm pretty sure. But I'm fairly sure that back when I wrote
that comment I would have had access to a real board and I think
I would have tested its behaviour. In fact, checking my email archive
I found the patch email I originally sent:
https://lore.kernel.org/qemu-devel/1378399437-17615-1-git-send-email-peter.maydell@linaro.org/
and there I said:

# I happened to have to check the h/w behaviour in this area today
# during a discussion about some kernel pl11x patches, so I thought
# I might as well record the info and clean up the #if-0 in the
# process.

which seems like pretty good evidence that QEMU here is
behaving like the hardware.

> I'm possibly the only person to actually care about this in about a decade, 
> and the CLCD driver has recently been removed from Linux.

Are we talking something other than drivers/gpu/drm/pl111/ ?

> I'm happy to write a patch for Qemu if anyone can suggest an approach
> to fixing this, anyone have any ideas?

Generally QEMU goes with "behave as the hardware does", though
for these old boards that gets kind of tricky. My gut feeling is
"this is a guest kernel bug that should be fixed in the guest
kernel".

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]