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
