RE: RZ/V2M USB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux