On Thu, Nov 28, 2019 at 12:13:49PM +0530, aaron.zakh...@gmail.com wrote:
> From: Aaron Dominick <aaron.zakh...@gmail.com>
> 
> 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