Hi Phil,
On Tue, Aug 9, 2022 at 12:10 PM Phil Edworthy <phil.edworthy@xxxxxxxxxxx> wrote:
> 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.
I think Shimoda-san is the actual USB expert here ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
