devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: yoshihiro shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Magnus Damm <magnus.damm@gmail.com>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Linux-USB <linux-usb@vger.kernel.org>,
	SH-Linux <linux-sh@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0
Date: Fri, 31 Oct 2014 14:04:22 +0900	[thread overview]
Message-ID: <20141031050422.GC10619@verge.net.au> (raw)
In-Reply-To: <2b89f66c72894bdf8bdce7aab7c69281@HKNPR06MB322.apcprd06.prod.outlook.com>

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?

  reply	other threads:[~2014-10-31  5:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-24 10:41 [PATCH v2 0/2] ARM: shmobile: add USB3.0 device node on r8a7790 Yoshihiro Shimoda
2014-10-24 10:41 ` [PATCH v2 1/2] ARM: shmobile: r8a7790: add USB3.0 device node Yoshihiro Shimoda
2014-10-24 10:41 ` [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0 Yoshihiro Shimoda
     [not found]   ` <1414147307-4584-3-git-send-email-yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
2014-10-29  6:53     ` Magnus Damm
2014-10-29 11:19       ` Yoshihiro Shimoda
2014-10-29 23:57         ` Simon Horman
2014-10-31  2:06           ` yoshihiro shimoda
2014-10-31  5:04             ` Simon Horman [this message]
2014-10-31 13:22               ` yoshihiro shimoda
2014-11-04  0:44                 ` Simon Horman
2014-10-27  0:22 ` [PATCH v2 0/2] ARM: shmobile: add USB3.0 device node on r8a7790 Simon Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141031050422.GC10619@verge.net.au \
    --to=horms@verge.net.au \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=magnus.damm@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).