From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
Date: Tue, 7 Apr 2015 20:55:54 +0200 [thread overview]
Message-ID: <201504072055.54108.marex@denx.de> (raw)
In-Reply-To: <BL2PR03MB1614B3CEB7B70E264CFADAAE0FD0@BL2PR03MB161.namprd03.prod.outlook.com>
On Tuesday, April 07, 2015 at 04:52:09 PM, Ramneek Mehresh wrote:
> > -----Original Message-----
> > From: Mehresh Ramneek-B31383
> > Sent: Tuesday, April 07, 2015 8:12 PM
> > To: 'Marek Vasut'
> > Cc: u-boot; sr at denx.de
> > Subject: RE: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> >
> > > -----Original Message-----
> > > From: Marek Vasut [mailto:marex at denx.de]
> > > Sent: Tuesday, April 07, 2015 7:44 PM
> > > To: Mehresh Ramneek-B31383
> > > Cc: u-boot; sr at denx.de
> > > Subject: Re: Regarding patch:
> > > http://patchwork.ozlabs.org/patch/373593/
> > >
> > > On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote:
> > > > > -----Original Message-----
> > > > > From: Marek Vasut [mailto:marex at denx.de]
> > > > > Sent: Tuesday, April 07, 2015 7:22 PM
> > > > > To: Mehresh Ramneek-B31383
> > > > > Cc: u-boot; sr at denx.de
> > > > > Subject: Re: Regarding patch:
> > > > > http://patchwork.ozlabs.org/patch/373593/
> > > > >
> > > > > On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:
> > > > >
> > > > > [...]
> > > > >
> > > > > > > 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?
> > > > > >
> > > > > > I have raised request for this feature in up-coming socs, and
> > > > > > they have agreed to provide phy shut-down in future revs.
> > > > > > However, this support is not available in current revs for which
> > > > > > the
> >
> > code is sent.
> >
> > > > > > What do you suggest we should do for current socs?
> > > > >
> > > > > Hi,
> > > > >
> > > > > I don't know, but doesn't leaving the USB running cause trouble to
> >
> > Linux?
> >
> > > > > I think you should at least document the reasoning why the USB
> > > > > stop is not implemented for this broken hardware.
> > > >
> > > > Hi Marek, it's not USB controller stop, it's Phy stop which is not
> > > > supported. Controller stopping is supported.
> > >
> > > OK, does it pose a problem for Linux ? If not, then please just
> > > document it and let's stick with what there now.
> >
> > No, it won't create issue in Linux because Linux usb driver resets the
> > controller (which in turn resets the phy). Please suggest what's the best
> > place to document this.
> > Shall I document this inside some u-boot doc file?
>
> I can document this inside xhci_stop() part of fsl driver. In addition,
> this will also be documented in FSL USB driver documentation.
> Please tell if this is ok.
Yes, thanks!
next prev parent reply other threads:[~2015-04-07 18:55 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
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 [this message]
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=201504072055.54108.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox