[Top][All Lists]

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

Re: [Qemu-ppc] R128 interrupts

From: BALATON Zoltan
Subject: Re: [Qemu-ppc] R128 interrupts
Date: Sun, 11 Aug 2019 04:36:18 +0200 (CEST)
User-agent: Alpine 2.21.9999 (BSF 287 2018-06-16)

Hello Gerd,

Just a note that I've sent some ati-vga patches during the freeze but I'm going to have v2 for some of them. I'll plan to resend all outstading patches as one series after 4.1 release for your convenience so you don't have to go back and find those patches one by one.

More comments/questions below:

On Sat, 10 Aug 2019, BALATON Zoltan wrote:
On Fri, 9 Aug 2019, Jd Lyons wrote:
At this point, what we need is correct handling of the interrupts, I’ve looked into how the USB and Network adapters handle interrupts, but it didn’t provide me with any code I could hack into the Rage128 support.

A simple example on how to implement an interrupt on a PCI card might be the hw/ide/sii3112.c although it does not raise the interrupts itself as that's done in the ide code so maybe there are simpler devices somewhere. But I'm not sure if we can implement the interrupt for ati-vga yet.

It’s going to take a skilled programmer, not a hacker like me.

I think it's more knowledge about ati vga chips (or reading the docs) is needed than skills here. Once we know what we need to implement it's probably easy the hard part is to gather the info on what should be impemented and understand how it should work.

The next step would be the GA plugin, but we can’t debug that until we get a correctly working interrupt situation.

Someone should check what the interrupt is used for on the ati card. My guess without knowing would be that maybe it should raise it for some buffers full or empty (in which case we would first need to actually implement handling of buffers before we can meaningfully implement interrupt) or maybe it could signal end of some operation in which case we might be able to implement an interrupt for that as we do all operations synchronously at the moment on register writes. (Later this should be made async.)

Well, I forgot about the most obvious reason for interrupts in a video card which is VBlank. Looks like register 0x40 has bits to enable interrupts and 0x44 has status bits. The MacOS driver seems to enable VBLank and FP detect interrupts then polls the status for a while so I think it may try to detect a flat panel display there but not sure it really needs VBlank interrupts afterwards as it seems to boot anyway. (Although seems to stop later so might be it wants VBlank interrupts?)

Now question is how to emulate this. Ideally this should be locked to the host's VBlank so we avoid tearing which is the usual reason to use this interrupt but we would need a way to get this on different platforms. On the other hand the guest might expect this to happen at the frequency of the mode it has programmed the card to which means that first we would need to understand the clocking that we currently conveniently ignore to find out the frequency and if that does not match the hosts mode we can't sync them. Or for simplicity and a first version to try if it improves anything we could ignore all this and just run a timer at 60Hz and generate VBlank interrupt by that when enabled? Any better idea anyone? I'm not going to try to implement this now so feel free to try if you want.

Another question to Gerd is how to set the maximum and preferred modes for ddc-edid? I know about the maxx,maxy and xres,yres properties of the edid generator but the way it's passed on by stdvga and other cards don't work for ati-vga because instead of embedding the edid we use i2c-ddc so not sure how I could pass these options. I've tried setting them with -global i2c-ddc,maxx=... or similar but that does not seem to work. Should that work or how to set this correctly? This is a problem because with the current edid data clients tend to select a very high res mode (around 2000x1500 don't know exact numbers) which is bigger than some people's screens so we'd need a way to tell what mode this should use for sane default.


reply via email to

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