From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
Date: Mon, 6 Apr 2015 17:11:37 +0200 [thread overview]
Message-ID: <201504061711.37768.marex@denx.de> (raw)
In-Reply-To: <BL2PR03MB1615980712967D7B7916FD4E0FE0@BL2PR03MB161.namprd03.prod.outlook.com>
On Monday, April 06, 2015 at 10:58:30 AM, Ramneek Mehresh wrote:
[...]
> > > > The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must
> > > > shut down the controller, which I don't see happening. Why?
> > >
> > > I could not locate any such requirement in IP documentation. Have
> > > contacted local IP/PHY team for the same. Waiting for response from
> > > them
> >
> > This is needed, so you don't start Linux with a running USB controller.
>
> xhci controller is already stopped in
> usb_stop->usb_lowlevel_stop->xhci_reset(). I could see CMD_RUN bit getting
> reset in this function before the controller is reset. So, from your
> previously stated requirement, controller is halted when Linux is started.
>
> Other people are shutting down PHY as part of xhci_core_exit(), not the
> controller!! We would not like to re-start and re-configure PHY inside
> Linux, and take phy initialization inside bootloader. I got word from hw
> team that they do not support phy shutting down from sw. hence, we do not
> have any sequence for current socs to shut down phy from sw. if required,
> I'll put forward a request to provide this control in future socs.
Hi,
Is this similar hardware bug to the one which MX6 PCIe is suffering ? On MX6,
the bug is that you cannot reset the PCIe and PCIe PHY from software, which
means that if you start PCIe in U-Boot, you cannot reliably use it in Linux.
Furthermore, if you reset the MX6 via WDT, you cannot start PCIe reliably in
Linux even if PCIe is not used in U-Boot at all.
Is this the same type of hardware screwup where the design team didn't think
reset was necessary?
Best regards,
Marek Vasut
next prev parent reply other threads:[~2015-04-06 15:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <BL2PR03MB161DE5448D4F4B4C8635AB6E06A0@BL2PR03MB161.namprd03.prod.outlook.com>
2014-12-18 11:16 ` [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/ Marek Vasut
2015-01-12 5:26 ` Ramneek Mehresh
2015-01-12 14:29 ` Marek Vasut
2015-04-06 8:58 ` Ramneek Mehresh
2015-04-06 15:11 ` Marek Vasut [this message]
2015-04-07 6:18 ` Ramneek Mehresh
2015-04-07 13:51 ` Marek Vasut
2015-04-07 14:05 ` Ramneek Mehresh
2015-04-07 14:13 ` Marek Vasut
2015-04-07 14:42 ` Ramneek Mehresh
2015-04-07 18:55 ` Marek Vasut
2015-04-07 14:52 ` Ramneek Mehresh
2015-04-07 18:55 ` Marek Vasut
2015-04-07 6:39 ` Paul Kocialkowski
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=201504061711.37768.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.