Re: [Qemu-ppc] R128 interrupts

[BALATON Zoltan]

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.

Regards,
BALATON Zoltan