|
From: | BALATON Zoltan |
Subject: | Re: [PATCH 0/5] Pegasos2 fixes and audio output support |
Date: | Thu, 23 Feb 2023 15:23:56 +0100 (CET) |
On Thu, 23 Feb 2023, Bernhard Beschow wrote:
On Thu, Feb 23, 2023 at 1:34 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:I don't get your approach.I hope that I could help you get a better understanding. The linked .pdf is good and comprehensive reading material.I'm not sure the via-ide confirms to that doc but it's also not any more a problem with via-ide now. That was discussed to death back then and "fixed" to work for the cases we want it to work with. We probably never agreed on how this really works but at least what we ended up with works with guests that run on real hardware. I'm OK with also making these cases work that we want now such as network and sound card under AmigaOS and sound under MorphOS (as long as you don't use USB) on pegasos2. This series does that so unless it breaks something that worked before I condider this moving forward and we can always improve adn fix it later. I'm not saying I'm not interested in your improvements just that let's that not hold this back now as we can fix and improve it later but otherwise users will have to wait until September to be able to use it. I know a few who want this and getting this out as it is would allow more people to test it and report problems so unless there are clearly wrong parts I'm OK with less than perfect but working solution as long as it's not too messy.Patch 1 really seems like duplicating PCI code that already exists in QEMU. This is not needed and we should avoid that. Moreover, usage of the IRQ line register (0x3c) for interrupt routing should be switched to using the 0x55-0x57 regs to be PCI compliant.That would not work because then guests were not able to separately configure IRQs for PCI interrupt lines and internal functions which is what the datasheet says should be possible. The internal functions' IRQs are not affeceted by 0x55-0x57 but routed by different registers.How do you know?
The datasheet says so. It says that 0x55-0x57 are controlling what ISA interrupts the PIRQA-D pins should raise while internal functions are documented to have 0x3c register to select what ISA IRQ they use. It's not said internal functions would use PCI interrupts that are separate and connected to the PIRQ pins.
I thinkyour series only work because pegasos2 firmware progeams everything to IRQ9 but if a guest decided to change that and route e.g. USB somewhere else then it would break. My series models that a bit better but may still break if a guest routes a function to an IRQ also controlled by some ISA device (like serial or ps2 keyboard) which are currently done within QEMU's ISA model so I can't easily channel those IRQs through the via-isa.for proper routing but it's unliikely guests would want to do that so in practice my series should work. We may duplicate PCI IRQ routing here but this chip does that and more so we need to implement it as it handles more than the 4 PCI interrupts so that implementation is not enough to handle all sources this chip has. This isn't a complex piece of code though so having a similar implementation is not a problem IMO.Thanks to your great work to make via-ac97 work we can confirm that both IRQ routing implementations basically work for now. Let's work out a solution that relies on existing code, sticks to the standard and hopefully works for i386 and MIPS, too.I'm still not convinced your implementation is correctIt seems that Mark (cc'd), I, the commenter in https://community.osr.com/discussion/30399/read-only-pci-interrupt-line-register and the PCI specification agree that the 0x3c regs aren't supposed to be interpreted by hardware.
You could still all be wrong if the PCI spec does not apply to the internal functions of the VIA chip which is just an assumption you made but the docs and experience never proved that so I don't believe that's a valid assumption. According to the datasheet internal functions' interrupts are routed independently from PCI interrupts which is what I've tried to model.
I've provided a working example with no functional downsides to the 0x3c approach. I've provided the PCI-IDE reading material that Mark suggested for reading in b38987d5-5530-ecd9-2fd2-3a57e1a611dd@ilande.co.uk/">https://lore.kernel.org/qemu-devel/b38987d5-5530-ecd9-2fd2-3a57e1a611dd@ilande.co.uk/ . I'm running out of ideas now on how to proceed.
Please submit an alternative series that we can test and if it works with the guests that I want to run like mine we can take that instead even if I believe your way is wrong. I don't care about who's right as long as it works. But make sure it gets in for 8.0 as I do care that it should work in the next release.
Regards, BALATON Zoltan
[Prev in Thread] | Current Thread | [Next in Thread] |