Re: [RFC PATCH 0/4] Misc OHCI patches

[BALATON Zoltan]

On Sat, 2 Oct 2021, BALATON Zoltan wrote:
> Interestingly on pegasos2 which has UHCI instead of OHCI MorphOS does not 
> even correctly detect the emulated usb-audio device and trying to get info 
> makes it freeze so looks like the UHCI model may also have some problems of 
> its own.

So it's not the UHCI model but a problem with IRQ routing with vt8231. 
I've noticed that it sends USB requests to the usb-audio device but the 
replies come back very slowly. This lead me to think the interrupts may 
not be handled correctly. What happens is that vt82c686-uhci-pci that 
models the USB function of the VT82xx super-southbridge chips is 
implemented as a PCIDevice (it's a subclass of TYPE_UHCI) and hcd-uhci is 
using pci_set_irq() to comminicate interrupts which will generate PCI 
interrupts. But the docs of both VT82c686b and vt8231 say that the 
interrupt line PCI config register (0x3c) of most sub functions of this 
chip selects which ISA IRQ that function is routed to. (This is also 
mentioned at https://wiki.osdev.org/PCI so probably this is generally true 
for such multifunction bridge chips while other PCI cards plugged in the 
PCI bus provided by these bridge chips use normal PCI interrupts.) On the 
other hand some of these functions may also exist as separate PCI cards 
where using the PCI interrupt is correct. If for testing I change 
uhci_update_irq() to set the appropriate ISA IRQ instead of pci_set_irq() 
then it works on pegasos2 and gets the same result as with mac99 and 
sam460ex but I wonder what would be a good way to model this? (Especially 
because in case of usb-uhci we can't cahnge it easily as that's also used 
by other devices.)

This is similar problem we've seen with the via-ide device (although 
that's a bit more complex due to that also disregards the PCI config 
register despite what the docs say and always uses ISA IRQ 14+15). We have 
that call qemu_set_irq(isa_get_irq()) now as it's only used as part of the 
VT82xx chips. We'll have the same problem when implementing via-audio so 
eventually we should come up with a solution for this.

What I can think of is maybe have these devices somehow detect if they are 
a standalone PCI device or a sub function of a bridge chip and use either 
pci_set_irq or isa_get_irq() accordingly which could work but if anybody 
has a better idea (that does not involve rewriting and QOM'ifying the 
whole ISA mess because I won't have time for that) please share.

Regards,
BALATON Zoltan