On Mon, 27 Feb 2023, Bernhard Beschow wrote:
> On Mon, Feb 27, 2023 at 2:00 PM BALATON Zoltan <balaton@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