Hi Phil-san, > From: Phil Edworthy, Sent: Monday, August 8, 2022 4:27 PM > > Hi Shimoda-san, > On 08 August 2022 00:47 Yoshihiro Shimoda wrote: > > > From: Phil Edworthy, Sent: Friday, August 5, 2022 10:10 PM > > > > > > Hi Geert, Yoshihiro, > > > > > > I'm a bit stuck with the usb3 drivers for RZ/V2M. > > > > > > The RZ/V2M USB3 is very similar to R-Car Gen3, the main difference being > > > where the DRD registers are located and additional clocks, interrupts > > > and resets exposed. The DRD registers are still part of the USBP address > > > space, though they have been moved above the other USBP regs. > > > > > > There is however, one big difference. On RZ/V2M, you can only access the > > > corresponding registers for whatever DRD mode has been set in the > > > DRD_CON register, PERI_CON bit. That is to say, when PERI_CON=1 (periph > > > mode), reading from a USBH register will cause an abort, and when > > > PERI_CON=0 (host mode), reading from a USBP register will cause an > > > abort. > > > > Thank you for asking me about this topic. I have a question: > > Can the DRD register be accessed from both PERI_CON=1 and 0? > Yes, that is correct. > > > > > This makes role switching rather difficult in Linux as the usb host hub > > > code does some work in a delayed work queue, after role switch. > > > > > > I am therefore advocating that users can only enable host or peripheral > > > in DT, and role switching is not allowed. Is that reasonable? > > > How can I ensure only one driver is enabled? > > > > > > This unfortunately opens up another problem... So that the USBH driver > > > can set the DRD mode, it needs access to the USBP address space. Could > > > that be just be additional reg entry in DT for this? > > > > > > I'm not sure how to go about this, any advice appreciated! > > > > If the DRD register can be accessed from both PERI_CON=1 and 0, > > I have an idea how to handle this. > > # However, I'm not sure whether this is a correct way or not though... > > > > My idea: > > - Make a new role switch driver on drivers/usb/roles/ or drivers/mfd/. > > - No describe any xHCI and USB3 UDC nodes in DT. > > - Describe whole USB3 registers for the role device in DT. > > (Or add sub nodes of xHCI and USB3 UDC into the role device.) > > - The role switch driver handles the DRD register at first. > Ok > > > And then, the driver adds xHCI or USB3 UDC device somehow. > The role switch must shut down the USBH driver so that it no longer > has the hub event work queue running. > How can we do this? I'm sorry for lacking my explanation. My idea is: - To enable host mode, add the USBH driver somehow. -- JFYI. renesas_usb3.c calls device_attach() for it now. - To disable host mode, remove the USBH driver somehow. -- JFYI. renesas_usb3.c calls device_release_driver() for it now. So, I assume readding device_attach() for host can run the hub event work queue again. Best regards, Yoshihiro Shimoda > Thanks > Phil
