Fix occasionally freezing USB OHCI

[frno7]

Commit 05bd9f2 is a workaround for a problem whereby USB OHCI interrupts occasionally seem to disappear, which results in a device driver freeze. This bug has been present since at least the 2.6.35.14 kernel from 2010. An alternative but much less efficient workaround is to assert extra interrupts using for example a 1000 Hz timer.

USB OHCI interrupts are asserted on the I/O Processor (IOP), and then forwarded to the R5900 Emotion Engine main processor. This forwarding can be done in at least two different ways: via a mailbox (SMFLAG) register or via remote procedure calls (RPC). Both methods fail similarly, which suggests that the problem is somewhere on the IOP side.

[sp193]

Does Linux now have its own equivalent to USBD? If not, what USBD module did you use? If you have been using a homebrew module and if it was from before late 2014, please upgrade.

[frno7]

What is the USBD? At the moment I am using intrelay-direct.irx for IOP interrupt relays. I have tested a few different variants of interrupt relays, all randomly failing in a similar manner. The critical part appears to be rather simple in the intr_usb_handler function:

int intr_usb_handler(void *unused)
{
#ifndef RPC_IRQ_SUPPORT
	_sw(TGE_SBUS_IRQ_USB, SIF_SMFLAG);

	_sw(_lw(0xbf801450) | 2, 0xbf801450);
	_sw(_lw(0xbf801450) & 0xfffffffd, 0xbf801450);
	_lw(0xbf801450);
#else
	sifCmdBufferIrq.data[0] = IRQ_SBUS_USB;
	isceSifSendCmd(SIF_CMD_INTERRUPT, &sifCmdBufferIrq, 64, NULL,
                NULL, 0);
#endif
	
	return 1;
}

The Linux USB OHCI driver manipulates the HCD registers directly via hcd->regs = ioremap(hcd->rsrc_start, hcd->rsrc_len) with IOP_OHCI_BASE defined to be 0x1f801600, without involving the IOP.

There is also a mysterious iop_set_dma_dpcr2(IOP_DMA_DPCR2_OHCI) in the Linux USB OHCI driver. It would be good to bring some clarity into what it actually does, and the DPCR2 register in general.

USB OHCI support is required for an initial Linux kernel submission, see #1. Unfortunately it brings significant complexity with its dependency on IOP infrastructure, including IOP memory allocations.

[sp193]

USBD.IRX is the USB HCD Driver for the PlayStation 2. I don't know what PS2Linux uses because I never heard of it having its own USB driver, so I presumed that the official PS2Linux involved USBD.IRX.
After all, we had no code to refer to, when working on our own homebrew USBD.IRX.

So does this use the standard Linux OHCI driver? There is also a need to ensure that the hardware errata is properly handled.

DPCR2 is the DMA Primary Control Register 2, which is used to control the DMA channels of the 2nd DMA controller. The PlayStation 2 IOP has 3 DMACs.
Each DMA channel has 4 bits, with the highest bit being the enable bit and the lower 3 representing the priority of the channel.

[frno7]

So does this use the standard Linux OHCI driver?

Yes, the Linux kernel manipulates the HCD registers directly from the EE, as for all other kinds of USB OHCI hardware, and it does not use USBD.IRX. What kind of services does the USBD provide? What does its interface look like?

There is also a need to ensure that the hardware errata is properly handled.

I have been told that there is an erratum about storing unaligned USB frames that are 63 or 64 bytes in length. However, I believe that the Linux USB OHCI buffers are always aligned, so this particular problem should not be a concern. Would you be able to provide other known errata?

Also, the USB OHCI bounce buffer is a grave limitation, as noted in #17.

Thanks for explaining the DPCR2! The DMA channels eventually need to be documented in the Linux kernel source code.

[sp193]

USBD provides APIs for registering Logical Device Drivers (LDD), managing transfers to USB devices, managing USB devices and linking with a USB LDD Autoloader. For more information, you should refer to the official documentation.

Yes, the difficulty with transferring 63/64-byte frames from an unaligned buffer is the only known errata. You need to ensure that the buffers on the IOP side are aligned.

The available documentation of all the DMA channels is not very complete as the controllers are proprietary. But most of the channels are known.
As for the lesser known ones:

• According to wisi, channel 67 ('C') is for the CPU Core.
• Channel 85 ('U') is for the USB OHCI controller.
• Channels 13 is for i.Link PHT0 (unidirectional?) and 15 is for i.Link PHT1. Only channels 14 and 15 seem to be capable of automatic responses, since Silverbull's dump of the CHCR13, CHCR14 and CHCR15 registers show that only 14 and 15 have the control bits for automatic responses. I forgot what 14 is connected to.

There is a large topic on the busses and the SSBUSC service as well: https://assemblergames.com/threads/the-playstation-2-busses-dev9.67961/

[frno7]

USBD provides APIs for registering Logical Device Drivers (LDD), managing transfers to USB devices, managing USB devices and linking with a USB LDD Autoloader.

Hmm... To proceed with the USBD we need to somehow adapt its services to the Linux kernel USB host driver stack, at a suitable level of abstraction.

Does the USBD transfer data via SIF DMA, thereby avoiding IOP memory constraints?

Ethernet support, as in #19, would simplify development of a Linux kernel USBD adapter.

The question remains, though, why the current interrupt relay method fails. Of course, there may be an underlying problem, perhaps related to the EE manipulating USB OHCI registers directly. It would be interesting to figure out what kind of state the OHCI hardware gets stuck in, and trace the series of register manipulations leading up to that point. The failure is easily reproducible. However, I am not an expert on the details of the USB OHCI.

For more information, you should refer to the official documentation.

Do you have links, code or other sources describing the USBD?

[sp193]

No, it does not involve the SIF on its own as it is an IOP module. 2MB is more than sufficient, if used properly. The 256KB limit you mentioned before, is a Linux thing.

You can refer to the USBD module source from the homebrew PS2SDK. But only the Sony documentation is most complete.

You might want to establish whether it is a problem with the USB driver itself or if it is a problem with relaying the interrupt. The latter is less related to USB.

[frno7]

2MB is more than sufficient, if used properly.

USB wireless networking devices want huge buffers to operate efficiently. I assume that additional IOP drivers for hard disks, sound, i.LINK, Ethernet etc. will claim a significant amount of IOP memory for code if not for their buffers. 😁

You might want to establish whether it is a problem with the USB driver itself or if it is a problem with relaying the interrupt.

The Linux USB OHCI subsystem is used by many millions of computers, so presumably it works well unless there is a problem with the hardware, or in this particular case the interrupt relay.

[sp193]

Unless you do all your processing on the IOP, you probably would not need large buffers. I know that you could possibly reach higher speeds with larger buffers and some devices, but the PS2 was not a console with a lot of memory. Data is read and kept in RAM, only as needed.

What I have done (and what @rickgaiser did) for the SMAP, was to maintain a ring buffer on the IOP for transfers to the EE.

If you are convinced that the problem is with how interrupts are routed, then you should not implement workarounds that involve changing the way the USB OHCI driver work. You could be just masking the true problem.

If it is not already done and you would like to, it is also possible to route interrupts by getting the IOP to trigger the EE-side SBUS interrupt from the IOP, after setting the MSFLAG/SMFLAG bits. The SBUS SMFLAG (sub to main)/MSFLAG (main to sub) register is set by the remote CPU, but cleared when the local CPU writes. These SIF registers can be used to indicate the interrupt cause.

If Linux will not expose or share the SBUS registers and interrupt with other software, then you are free to use it as desired. This could be an even lighter implementation than using SIFCMD.

[frno7]

I know that you could possibly reach higher speeds with larger buffers and some devices, but the PS2 was not a console with a lot of memory.

That is true. For the PlayStation 2, I think, the problem is not primarily loss of speed but the fact that many useful Linux USB devices will not work unless their drivers are patched to consume much less memory. As an example, commit 0b3a20c reduces the (hard-coded) memory requirements for wireless rt2x00 devices. They refuse to operate otherwise, which is less than ideal for users plugging in their favourite devices expecting them work. The mass-storage device driver apparently busy-waits to claim the memory it desires. Of course, attaching several USB devices increases memory pressure.

What I have done (and what @rickgaiser did) for the SMAP, was to maintain a ring buffer on the IOP for transfers to the EE.

That sounds like a reasonable thing to do for PlayStation 2 specific devices. 😄

If you are convinced that the problem is with how interrupts are routed, then you should not implement workarounds that involve changing the way the USB OHCI driver work. You could be just masking the true problem.

Hopefully the true root cause will be identified, eventually, and a proper fix can be implemented. Meanwhile, the current USB OHCI workaround is provisional and designed for system usability.

If it is not already done and you would like to, it is also possible to route interrupts by getting the IOP to trigger the EE-side SBUS interrupt from the IOP, after setting the MSFLAG/SMFLAG bits. The SBUS SMFLAG (sub to main)/MSFLAG (main to sub) register is set by the remote CPU, but cleared when the local CPU writes. These SIF registers can be used to indicate the interrupt cause.

If Linux will not expose or share the SBUS registers and interrupt with other software, then you are free to use it as desired. This could be an even lighter implementation than using SIFCMD.

Hmm... these two approaches sound exactly like ones already described and tested negative in this issue? Maybe I have misunderstood something? Also, Ethernet, for example, seemingly continues to operate perfectly even when USB fails, suggesting that the problem is not a failure of the relay channel in the case of SIF RPC. I suspect that the OHCI interrupt is lost or perhaps not even asserted on the IOP side, for whatever reason.