RE: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

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

 



Hi Simon-san,

> On Fri, Oct 31, 2014 at 02:06:14AM +0000, yoshihiro shimoda wrote:
> > Hi Simon-san,
> >
> > > On Wed, Oct 29, 2014 at 08:19:30PM +0900, Yoshihiro Shimoda wrote:
> > > > Hi Magnus-san,
> > > >
> > > > (2014/10/29 15:53), Magnus Damm wrote:
> > < snip >
> > > > >
> > > > > Hi Shimoda-san,
> > > > >
> > > > > Thanks for your patch. I'm fine with this patch as a first step,
> > > > > but I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0?
> > > >
> > > > I investigated this reason today, and I found the reason is
> > > > request_firmware().  I checked the following environments:
> > > >
> > > > Case 1: xHCI and EHCI and OHCI are enabled "=y"
> > > > Case 2: xHCI and EHCI and OHCI are loadable modules "=m"
> > > > Case 3: xHCI and EHCI and OHCI are enabled "=y",
> > > >         and CONFIG_EXTRA_FIRMWARE is enabled
> > > >
> > > > The results are:
> > > > - In "Case 1", EHCI and OHCI are probed first because xHCI didn't find the firmware.
> > > > - In "Case 2" and "Case 3", xHCI is probed first.
> > > >
> > > > > Is the current order just based on device init order? In my mind
> > > > > the expected behavior would be to always use USB 3.0 if it
> > > > > happens to be available in the hardware, specified in the DTS,
> > > > > enabled by the kernel configuration and firmware is loadable. Or
> > > > > does some case exist where it is better to use USB 2.0? I suspect no.
> > > >
> > > > I agree with you.
> > > >
> > > > > So I wonder if you have any plans how to make USB 3.0 enabled by
> > > > > default on Lager?
> > > >
> > > > It depends on a kernel config. I'm not sure of the
> > > > shmobile_defconfig strategy.  But, in my opinion, one of a
> > > > solution is kernel modules (this means the "Case 2".)
> > >
> > > It sounds like we should enable CONFIG_EXTRA_FIRMWARE in
> > > shmobile_defconfig. I wonder what if any fallout we can foresee occurring if we do that.
> >
> > According to the firmware/README.AddingFirmware, we are unable to add a new firmware image to the firmware directory
> now.
> > So, if we enable CONFIG_EXTRA_FIRMWARE with the xHCI firmware, we will not build kernel because the xHCI firmware doesn't
> exist in the linux.git.
> >
> > === from  firmware/README.AddingFirmware
> > =====================================
> > This directory is _NOT_ for adding arbitrary new firmware images. The
> > place to add those is the separate linux-firmware repository:
> >
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.
> > git
> > ======================================================================
> > ========
> 
> Thanks. It seems that EXTRA_FIRMWARE is not an option from a mainline point of view after all.
> 
> Is the problem in case 1 that the firmware can't be found because userspace does exist yet and thus can't be loaded from
> there?

That's correct.
If EXTRA_FIRMWARE is not set, the following error happens:

xhci-hcd ee000000.usb: Direct firmware load for r8a779x_usb3_v1.dlmem failed with error -2
xhci-hcd ee000000.usb: can't setup: -2
xhci-hcd ee000000.usb: USB bus 1 deregistered
xhci-hcd: probe of ee000000.usb failed with error -2

Best regards,
Yoshihiro Shimoda

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux