qemu-devel
[Top][All Lists]
Advanced

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

Re: [RFC 0/1] ATI R300 emulated grpahics card V2


From: Gerd Hoffmann
Subject: Re: [RFC 0/1] ATI R300 emulated grpahics card V2
Date: Thu, 28 Nov 2019 12:30:23 +0100
User-agent: NeoMutt/20180716

On Thu, Nov 28, 2019 at 12:13:49PM +0530, address@hidden wrote:
> From: Aaron Dominick <address@hidden>
> 
> This is the cleaned up patchset to my previous RFC patch set.
> I could not reliably clean up my previous commits so I deleted my fork and 
> started from scratch.
> The patch looks like a lot of changes but most of it is just register 
> definitions copied from the kernel radeon DRM tree.

Adding headers should be a separate patch.

Qemu has some infrastructure to sync files with the linux kernel tree
(see scripts/update-linux-headers.sh).  It's intended for uapi include
files though, so it might not work for you.  Also the register specs are
not going to change, so future updates are unlikely, so doing a one-time
manual copy wouldn't be too bad maintenance-wise.

The code should probably be integrated with the existing ati-vga instead
of just copying the code, i.e. it'll be "-device ati-vga,model=r300".
As far I know crtc programming doesn't change much across models, so
there should be a good chunk of shareable code.

The infrastructure to branch into model-specific code is pretty rough
right now, we might refine that, for example with some helper functions
(ati_get_model() returning an enum, or ati_is_$model() functions
returning bool, or both).

Patches usually should pass scripts/checkpatch.pl codestyle checking.
We can make exceptions when reasonable (headers copied from elsewhere
for example).

> What I have implemented so far seems to get a Linux guest to load the
> DRM and KMS drivers but it cannot find any CRTCs.

Might be the vgabios tables are lacking information,
see https://git.seabios.org/cgit/seabios.git/tree/vgasrc/ati-tables.S

Might be i2c emulation needs tweaks (so EDID fetch works).

Trouble-shooting linux guests shouldn't be too hard, you have the source
code so you can check what the driver tries to do and you can add debug
printk's to trace where exactly things are failing ;)

HTH,
  Gerd




reply via email to

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