All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mvebu: usb: Add missing controller reset after initialization
Date: Mon, 4 Jan 2016 00:47:37 +0100	[thread overview]
Message-ID: <201601040047.37162.marex@denx.de> (raw)
In-Reply-To: <20160103233643.3CAC061C7D@mail.nwl.cc>

On Monday, January 04, 2016 at 12:38:07 AM, Phil Sutter wrote:
> Hi,
> 
> On Sun, Jan 03, 2016 at 09:59:23AM +0100, Wolfgang Denk wrote:
> > [added USB custodian to Cc:]
> > 
> > In message <20160102211834.E49A161C74@mail.nwl.cc> you wrote:
> > > In order to allow for Linux properly register the integrated EHCI host,
> > > we have to reset it after initialization. Without this, enumeration
> > > fails if 'usb start' wasn't issued prior to booting Linux.
> > 
> > I think this reset should actually be done in the Linux driver.
> > 
> > From what you write I suspect that after a "usb stop" in U-Boot the
> > Linux driver maight fail, too.  Leaving USB enabled in U-Boot is
> > extremely dangerous - see
> 
> Ah, thanks for pointing this out! I had no idea the HCD does things like
> 
> this. Though I'm a bit confused now how to solve the issue at hand:
> > commit 3d71c81a9bb03f866a1e98da96363ef3f46c76b3
> > Author: Markus Klotzb?cher <mk@denx.de>
> > Date:   Thu Jul 10 14:47:09 2008 +0200
> > 
> >     USB: shutdown USB before booting
> >     
> >     This patch fixes a potentially serious issue related to USB which was
> >     discouvered by Martin Krause <martin.krause@tqs.de> and fixed for
> >     
> >     ARM920T. Martin wrote:
> >       Turn off USB to prevent the host controller from writing to the
> >       SDRAM while Linux is booting. This could happen, because the HCCA
> >       (Host Controller Communication Area) lies within the SDRAM and the
> >       host controller writes continously to this area (as busmaster!),
> >       for example to increase the HccaFrameNumber variable, which
> >       happens every 1 ms.
> >     
> >     This is a slightly modified version of the patch in order to shutdown
> >     USB when booting on all architectures.
> >     
> >     Signed-off-by: Markus Klotzbuecher <mk@denx.de>
> 
> This commit exists in my tree, therefore when I call 'bootm' it should
> stop USB. To be sure, I tested calling 'usb stop' manually before doing
> 'tftpboot; bootm' and the enumeration still succeeds in Linux.
> 
> Since this all does not seem to make much sense, I reviewed my changes
> again to see if the controller really is enabled after the reset - it is
> not, but I found something more important: The reset is actually not
> necessary at all!
> 
> The bit which really was missing is the USB mode setting I smuggled in
> along with my patch - setting the devices to host mode is sufficient for
> Linux to successfully enumerate the HCD.

OK, so the controller is OTG capable and upon reset, it's in Gadget mode?

> Checking the logs of the vendor's U-Boot fork, it appears that devices 1
> and 2 are configured to host mode, while the third is set to device
> mode. I changed my code to copy that, but am not sure it's necessary at
> all: The DS414 exports only a single port of the SoC's EHCI, and Linux
> 
> detects that:
> | orion-ehci f1050000.usb: EHCI Host Controller
> | orion-ehci f1050000.usb: new USB bus registered, assigned bus number 3
> | orion-ehci f1050000.usb: irq 27, io mem 0xf1050000
> | orion-ehci f1050000.usb: USB 2.0 started, EHCI 1.00
> | hub 3-0:1.0: USB hub found
> | hub 3-0:1.0: 1 port detected
> 
> OTOH I'm not sure how far this configuration is device specific in the
> first place. What puzzles me is that I couldn't find a reference to this
> USB mode register at 0x501A8 in Marvell's MV78230 specs, still it seems
> to be crucial. Does anyone of you have this register referenced in some
> Marvell datasheet somewhere?

It's the USBMODE register, see for example [1] . It's part of EHCI cores
which are OTG capable.

[1] http://lxr.free-electrons.com/source/drivers/usb/host/ehci-hcd.c#L179

> Maybe there's also a more generic way to do this, 'usb start' (which
> solves the problem without any changes to the SoC init code) seems to
> not address this register.

Probably add a fixup into ehci-orion.c in Linux or something along those
lines. It should configure the code according to the "dr_mode" DT prop.

  reply	other threads:[~2016-01-03 23:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-02 21:19 [U-Boot] [PATCH] mvebu: usb: Add missing controller reset after initialization Phil Sutter
2016-01-03  8:59 ` Wolfgang Denk
2016-01-03  9:35   ` Marek Vasut
2016-01-03 23:38   ` Phil Sutter
2016-01-03 23:47     ` Marek Vasut [this message]
2016-01-04  3:02       ` Phil Sutter
2016-01-04 11:25         ` Marek Vasut
2016-03-24  9:13           ` Stefan Roese
2016-03-24  9:47             ` Phil Sutter

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=201601040047.37162.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.