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

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

 




On Fri, Oct 31, 2014 at 01:22:22PM +0000, yoshihiro shimoda wrote:
> 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

At the risk of adding noise to this discussion:
It seems like case 2 with a fallback to case 3 is the way to go.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux