From: Eric Nelson <eric.nelson@boundarydevices.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] pci: mx6: Implement reset callback
Date: Mon, 03 Feb 2014 12:57:30 -0700 [thread overview]
Message-ID: <52EFF4AA.1030804@boundarydevices.com> (raw)
In-Reply-To: <201402032033.32072.marex@denx.de>
Hi Marek,
On 02/03/2014 12:33 PM, Marek Vasut wrote:
> On Monday, February 03, 2014 at 07:40:09 PM, Eric Nelson wrote:
>
> [...]
>
>>> Well ... SL and N6X both. For all I care, we can have #define
>>> MX6_PCIE_RESET_GPIO and if that's not defined, puke out this warning. And
>>> ultimatelly let this function be overriden anyway in case people used
>>> some GPIO expander or whatnot. So the change to this would be:
>>>
>>> __weak int imx6_pcie_toggle_reset(void)
>>> {
>>> #ifdef CONFIG_MX6_PCIE_RESET_GPIO
>>>
>>> gpio_set...
>>> mdelay();
>>> gpio_set...
>>> mdelay();
>>>
>>> #else
>>>
>>> puts("Oh yeah, broken design :-(\n");
>>
>> That's pretty harsh!
>
> Yes, I know that won't please you :-(
>
Ouch!
>> We have lots of stuff working without a GPIO...
>
> Actually, see PCI Express Base Specification, Rev. 3.0 : Section 6.6.1 :
> Paragraph 2 . Quote:
>
> "
> 6.6.1. Conventional Reset
>
> Conventional Reset includes all reset mechanisms other than Function Level
> Reset. There are two categories of Conventional Resets: Fundamental Reset and
> resets that are not Fundamental Reset. This section applies to all types of
> Conventional Reset.
>
> In all form factors and system hardware configurations, there must, at some
> level, be a hardware mechanism for setting or returning all Port states to the
> initial conditions specified in this document ? this mechanism is called
> ?Fundamental Reset.? This mechanism can take the form of an auxiliary
> signal provided by the system to a component or adapter card, in which case the
> signal must be called PERST#, and must conform to the rules specified in Section
> 4.2.4.8.1. When PERST# is provided to a component or adapter, this signal must
> be used by the component or adapter as Fundamental Reset.
>
> When PERST# is not provided to a component or adapter, Fundamental Reset is
> generated autonomously by the component or adapter, and the details of how this
> is done are outside the scope of this document. If a Fundamental Reset is
> generated autonomously by the component or adapter, and if power is supplied by
> the platform to the component/adapter, the component/adapter must generate a
> Fundamental Reset to itself if the supplied power goes outside of the limits
> specified for the form factor or system.
> "
>
> This means, your platform _MUST_ have a FR implementation. If you have PERST
> connected (that's the reset pin) to for example GPIO, then so be it and that's
> your FR.
>
> The third paragraph states that if you do NOT have PERST connected, you need
> some other way of doing FR. Another way of generating FR is to depend on POR, so
> when power is applied to the component, it will generate FR internally. Thus to
> produce an "alternative" FR without PERST connected, you toggle the power GPIO
> of the particular slot.
>
> I think the SL can do neither, right ? :-(
>
Right again.
PCIe was very much an afterthought (and late addition) on SABRE Lite,
and unfortunately only slightly improved on Nitrogen6x.
We have had success in using/testing PCIe devices without either, but
that doesn't mean we match the spec, and I suppose we'll have to live
with the "broken design" message...
Regards,
Eric
next prev parent reply other threads:[~2014-02-03 19:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-24 15:25 [U-Boot] [PATCH] pci: mx6: Implement reset callback Marek Vasut
2014-01-28 15:06 ` Stefano Babic
2014-01-28 19:32 ` Marek Vasut
2014-02-03 11:56 ` Stefano Babic
2014-02-03 18:17 ` Marek Vasut
2014-02-03 18:40 ` Eric Nelson
2014-02-03 19:33 ` Marek Vasut
2014-02-03 19:57 ` Eric Nelson [this message]
2014-02-03 20:16 ` Marek Vasut
2014-02-03 20:54 ` Eric Nelson
2014-02-03 23:34 ` Marek Vasut
2014-02-04 0:57 ` Eric Nelson
2014-02-04 11:25 ` Marek Vasut
2014-02-03 20:12 ` Stefano Babic
2014-01-31 5:33 ` Tim Harvey
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=52EFF4AA.1030804@boundarydevices.com \
--to=eric.nelson@boundarydevices.com \
--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.