On Mon, Feb 27, 2023 at 2:45 PM BALATON Zoltan <bala...@eik.bme.hu> wrote:
> On Mon, 27 Feb 2023, Bernhard Beschow wrote: > > On Mon, Feb 27, 2023 at 2:00 PM BALATON Zoltan <bala...@eik.bme.hu> > wrote: > > > >> On Mon, 27 Feb 2023, Bernhard Beschow wrote: > >>> On behalve of Zoltan BALATON: > >> > >> You don't have to do that and in fact please don't. I'll handle this > >> series just reply to the one patch that needs update with only the > changes > >> that were asked by review. > >> > >> Regards, > >> BALATON Zoltan > >> > > > > Google seems to agree with me by not letting me send your patches :/ > > > > Sent [PATCH v4 0/7] Pegasos2 fixes and audio output support > > Sent [PATCH v4 1/7] hw/display/sm501: Implement more 2D raster > operations > > Sent [PATCH v4 2/7] hw/display/sm501: Add fallbacks to pixman routines > > Sent [PATCH v4 3/7] hw/display/sm501: Add debug property to control > > pixman usage > > 4.3.0 Mail server temporarily rejected message. > > bk4-20020a170906b0c400b008d7a8083dffsm3186414ejb.222 - gsmtp > > > > As said before I don't want to iterate on the changes of this series. I > > can't test them and from my POV they seem unnecessary to me since all the > > test cases I can perform still work without the IRQ changes. > > Then why do you make me track your series and asking me to check if you > broke anything in my patches during your rebase that I've asked you not > to do? Because I couldn't convince you about the PCI IRQ router changes ;) I've asked how to proceed and got the suggestion to post an alternative series. > The series I've submitted (both my original and the one with your > changes) were tested and made sure it worked with AmigaOS that you say you > can't test. > Unfortunately my patches had changes merged in. This now makes it hard to show what really changed (spoiler: nothing that affects behavior). As you probably noticed in the "resend" version of this iteration I split off a patch introducing the priq properties. It belongs to the sub series of the Pegasos2 IRQ fixes which appear unnecessary to me, so I don't want to show up in `git blame` as the author of any of these changes. I attributed it to you because this was really your change which I'm not even sure is legal. Let's avoid such complications by keeping our series separate. > > Looking at the schematics I get the impression that the PCI IRQs actually > > work the other way around: Instead of the INTx lines of the 2nd PCI bus > > triggering both the north and the south bridge IRQ controllers, the two > PCI > > buses of the north bridge both trigger the VT82xx PCI IRQ router. I'm > not a > > hardware engineer so I could be totally off here. That's why I rather > leave > > my hands off of this stuff. > > You don't seem to leave your hands off and got involved voluntarily so now > don't run away :-) > I'm happy to comment on it but please don't make me change anything there for now. Feature freeze is approaching soon after all which in turn raises the temperature for development. > I'm no hardware engineer either but in any case pci_set_irq cannot be used > from a PCIDevice as I explained in the other message so your approach with > that is clearly wrong and we need gpios that something else connects to > the PCI bus. You could only do that if the VIA chip was a north bridge > that had a PCI bus but it doesn't. In pegasos2 the north bridge is the > MV64361 but the PCI interrupt lines are connected to its GPP (General > purpose or multi purpose pins in docs that are just gpio lines, which are > programmable inputs or outputs). These can generate an interrupt in the > MV64361 but the VT8231 also has an ability to route PCI IRQs to ISA > interrupts which some guests use. So I think the way I've modeled it is > correct by connecting the PCI bus interrupt pins to both of these chips > and since they are independent models the only place you can do it cleanly > is the board code. Other boards may connect the VIA PIRQ pins differently > but this model allows for that now. What is that you still don't like > about it? > On page 13 there is a note saying "Southbridge is INT controller". Another note says "AGP uses A as first Int for none shared operation". These notes describe hardware, so should apply to all guests. Furthermore, I couldn't find any remotely useful documentation for the MV64361 chip. This turns any discussion into guesswork. Best regards, Bernhard > > Regards, > BALATON Zoltan
