linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thinh Nguyen <thinh.nguyen@synopsys.com>
To: Lukas Hartmann <lukas@mntmn.com>,
	Thinh Nguyen <thinh.nguyen@synopsys.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Lucas Stach <l.stach@pengutronix.de>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	John Youn <john.youn@synopsys.com>
Subject: Re: Linux Kernel Regression: HAPS quirk breaks PCIe on i.MX6QP
Date: Fri, 1 Feb 2019 20:22:33 +0000	[thread overview]
Message-ID: <30102591E157244384E984126FC3CB4F639BF33C@us01wembx1.internal.synopsys.com> (raw)
In-Reply-To: 16AAD0CF-D411-4880-BEE5-11A30F9B4886@mntmn.com

Hi Lukas,

Lukas Hartmann wrote:
> Hi Thinh,
>
> this is in a taped out i.MX6QP 1.2GHz SoC, I also confirmed it with the 1.0GHz version, it has the same 0xabcd device id integrated.

I see.

> I will try your patch ASAP.

Thank you.
Thinh


>
>> On 1. Feb 2019, at 00:46, Thinh Nguyen <thinh.nguyen@synopsys.com> wrote:
>>
>> Hi Lukas,
>>
>> Thinh Nguyen wrote:
>>> Bjorn Helgaas wrote:
>>>> [+cc linux-pci, linux-kernel]
>>>>
>>>>> On Thu, Jan 31, 2019 at 11:21 AM Lukas F. Hartmann <lukas@mntmn.com> wrote:
>>>>> Hi Thinh,
>>>>>
>>>>> I'm writing you because you're the author in this commit:
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_torvalds_linux_commit_03e6742584af8866ba014874669d0440bed3a623&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=VKipRJmm95P2RbIxyKKYrcUCOGNlQtjlV-5zhrVhIik&m=2sOrowYXlsC3rl0LfHQhIZzImag0jFZXGvR6NIQDsh8&s=oJoBWRE8_LGAYbX2alh6QnjYZTTmzcgLw4MtOMToNyo&e=
>>>>>
>>>>> This quirk workaround breaks the PCIe on i.MX6QP, at least on my test
>>>>> devices. The reason is because the Synposys PCIe IP in i.MX6QP has the
>>>>> same device ID as the HAPS USB3 controller you are targeting in the
>>>>> commit: 0xabcd.
>>>>>
>>>>> Definition:
>>>>>
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_torvalds_linux_blob_master_include_linux_pci-5Fids.h-23L2364&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=VKipRJmm95P2RbIxyKKYrcUCOGNlQtjlV-5zhrVhIik&m=2sOrowYXlsC3rl0LfHQhIZzImag0jFZXGvR6NIQDsh8&s=-FVCwe81XNjJsYHYk1w-kdAzSOLunTGeNc73azO2QYw&e=
>>>>>
>>>>> Here is a bit of lspci output on my i.MX6QP machine (without the problem):
>>>>>
>>>>> mntmn@reform:~/code/linux$ lspci -v
>>>>> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00
>>>>>                                          ^^^^
>>>>> [Normal decode])
>>>>>        Flags: bus master, fast devsel, latency 0, IRQ 307
>>>>>        Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
>>>>>        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
>>>>> ...
>>>>>
>>>>> The failure mode is that the PCIe controller shows up as a USB
>>>>> controller and my ath9k wireless PCIe card cannot be assigned the
>>>>> proper resources anymore (-ENOMEM even for very small BARs).
>>>>>
>>>>> Reverting this commit fixes the problem for me. I suggest to make the
>>>>> check more specific to the platform/chipset you are targeting.
>>>> So Synopsys apparently re-used Device ID 0xabcd?  That's a pretty bad problem.
>>>>
>>>> It looks like we merged 03e6742584af ("PCI: Override Synopsys USB 3.x
>>>> HAPS device class") for v5.0, and v5.0-final hasn't been released yet,
>>>> so if we don't hear from Thinh with a resolution, we can still revert
>>>> it.
>>>>
>>>> I set myself a reminder to revert this on Feb 11, but hopefully we'll
>>>> have a better resolution before then.
>>>>
>>>> Bjorn
>>>>
>>> This is really odd that the PID for the PCIe controller in i.MX6QP is
>>> the same as PID Synopsys use for USB controller. We use a different set
>>> of PIDs for PCIe controllers and track VID and PID in our releases.
>>>
>>> Is the Root Complex (00:00.0) part of the SoC? Or is this a Synopsys
>>> prototype connected to your board? If it is the latter, then the FPGA
>>> configuration needs to be updated to other PID.
>>>

  reply	other threads:[~2019-02-01 20:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87o97wrbef.fsf@mntmn.com>
2019-01-31 21:49 ` Linux Kernel Regression: HAPS quirk breaks PCIe on i.MX6QP Bjorn Helgaas
2019-01-31 22:50   ` Thinh Nguyen
2019-01-31 23:46     ` Thinh Nguyen
2019-02-01  8:05       ` Lukas Hartmann
2019-02-01 20:22         ` Thinh Nguyen [this message]
2019-02-01  8:59       ` Lukas Wunner
2019-02-01 20:27         ` Thinh Nguyen
2019-02-05 20:09           ` Bjorn Helgaas
2019-02-05 20:38             ` Thinh Nguyen
2019-02-05 20:59               ` Bjorn Helgaas
2019-02-05 21:02                 ` Thinh Nguyen
2019-02-05 21:33                   ` Thinh Nguyen

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=30102591E157244384E984126FC3CB4F639BF33C@us01wembx1.internal.synopsys.com \
    --to=thinh.nguyen@synopsys.com \
    --cc=bhelgaas@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.youn@synopsys.com \
    --cc=l.stach@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@mntmn.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).