[Top][All Lists]

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

Re: [PATCH 0/5] Pegasos2 fixes and audio output support

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 think
your 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 correct

It seems that Mark (cc'd), I, the commenter in
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
. 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.


reply via email to

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