Hi Shimoda-san, On 08 August 2022 12:30 Yoshihiro Shimoda wrote: > > 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. Ok, this sounds reasonable. Let's see if Geert has any additional comments. Thanks Phil
