From: Roberto Fichera <kernel@tekno-soft.it>
To: Tim Harvey <tharvey@gateworks.com>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
"Lucas Stach" <l.stach@pengutronix.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"Richard Zhu" <Richard.Zhu@freescale.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
"Krzysztof Hałasa" <khalasa@piap.pl>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Petr Štetiar" <ynezz@true.cz>,
"Fabio Estevam" <festevam@gmail.com>
Subject: Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity
Date: Tue, 29 Mar 2016 18:44:11 +0200 [thread overview]
Message-ID: <56FAB0DB.3070303@tekno-soft.it> (raw)
In-Reply-To: <CAJ+vNU0bQVd0qyLg+09CUHx4WsrEqwZ4hLVuuvazR8DWpiHE_g@mail.gmail.com>
On 03/29/2016 06:40 PM, Tim Harvey wrote:
> On Tue, Mar 29, 2016 at 9:13 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>> On 03/29/2016 05:10 PM, Tim Harvey wrote:
>>> Arnd,
>>>
>>> Right, on the IMX the MSI interrupt is GIC-120 which is also the
>>> legacy INTD and I do see that if I happen to put a radio in a slot
>>> where due to swizzling its pin1 becomes INTD (GIC-120) the interrupt
>>> does fire and the device works. Any other slot using GIC-123 (INTA),
>>> GIC-122 (INTB), or GIC-121 (INTC) never fires so its very possible
>>> that something in the designware core is masking out the legacy irqs.
>>> I would also think this was something IMX specific, but I really don't
>>> see any codepaths in pci-imx6.c that would cause that: a driver
>>> requesting a legacy PCI would get a GIC interrupt which is handled by
>>> the IMX6 gpc interrupt controller.
>>>
>>> Any dra7xxx, exynos, spear13xx, keystone, layerscape, hisi, qcom SoC
>>> users of designware PCIe core out there that can verify PCI MSI and
>>> legacy are both working at the same time?
>>>
>>> Lucas is the expert here and I believe he has the documentation for
>>> the designware core that Freescale doens't provide with the IMX6
>>> documentation so hopefully he can provide some insight. He's the one
>>> that has authored all the MSI support and has been using it.
>>>
>>> I typically advise our users to 'not' enable MSI because
>>> architecturally you can spread 4 distinct legacy irq's across CPU's
>>> better than a single shared irq.
>> Don't know if I'm facing similar problem, however devices connected in miniPCI slot behind
>> a PCIe-to-PCI bridge (MSI is disabled) using INTA all is working ok, including shared IRQ.
>> In case of INTB will not work, and the GIC irq quite often get stuck.
>>
> Roberto,
>
> What board/platform is this and what does /proc/interrupts look like?
It's a custom board
root@voneus-janas-imx6q:~# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
16: 936 637 2057 938 GIC 29 Edge twd
17: 0 0 0 0 GPC 55 Level i.MX Timer Tick
22: 247 0 0 0 GPC 26 Level 2020000.serial
34: 0 0 0 0 gpio-mxc 6 Edge Factory Reset Button
267: 0 0 0 0 GPC 49 Level imx_thermal
272: 0 0 0 0 GPC 19 Level rtc alarm
278: 0 0 0 0 GPC 2 Level sdma
281: 361 0 0 0 GIC 150 Level 2188000.ethernet
282: 0 0 0 0 GIC 151 Level 2188000.ethernet
283: 2882 0 0 0 GPC 25 Level mmc0
284: 95 0 0 0 GPC 37 Level 21a4000.i2c
290: 36546 0 0 0 GPC 123 Level PCIe PME, b4xxp
291: 2 0 0 0 GIC 137 Level 2101000.jr0
292: 0 0 0 0 GIC 138 Level 2102000.jr1
IPI0: 0 0 0 0 CPU wakeup interrupts
IPI1: 0 0 0 0 Timer broadcast interrupts
IPI2: 1642 1038 1626 1781 Rescheduling interrupts
IPI3: 95 95 122 119 Function call interrupts
IPI4: 3 0 2 0 Single function call interrupts
IPI5: 0 0 0 0 CPU stop interrupts
IPI6: 0 0 0 0 IRQ work interrupts
IPI7: 0 0 0 0 completion interrupts
Err: 0
>
> This sounds like what would happen if the downstream interrupts on the
> PCIe-to-PCI bridge are not mapped properly as was the case with a
> board I support (in which case I had to work out a bootloader fixup
> that placed a non-standard interrupt-map in the device-tree for the
> bridge). What bridge are you using?
PCIe-to-PCI bridge is a Ti XIO2001 where we are using INTA/B only wired 1:1
>
> Tim
>
WARNING: multiple messages have this Message-ID (diff)
From: kernel@tekno-soft.it (Roberto Fichera)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity
Date: Tue, 29 Mar 2016 18:44:11 +0200 [thread overview]
Message-ID: <56FAB0DB.3070303@tekno-soft.it> (raw)
In-Reply-To: <CAJ+vNU0bQVd0qyLg+09CUHx4WsrEqwZ4hLVuuvazR8DWpiHE_g@mail.gmail.com>
On 03/29/2016 06:40 PM, Tim Harvey wrote:
> On Tue, Mar 29, 2016 at 9:13 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>> On 03/29/2016 05:10 PM, Tim Harvey wrote:
>>> Arnd,
>>>
>>> Right, on the IMX the MSI interrupt is GIC-120 which is also the
>>> legacy INTD and I do see that if I happen to put a radio in a slot
>>> where due to swizzling its pin1 becomes INTD (GIC-120) the interrupt
>>> does fire and the device works. Any other slot using GIC-123 (INTA),
>>> GIC-122 (INTB), or GIC-121 (INTC) never fires so its very possible
>>> that something in the designware core is masking out the legacy irqs.
>>> I would also think this was something IMX specific, but I really don't
>>> see any codepaths in pci-imx6.c that would cause that: a driver
>>> requesting a legacy PCI would get a GIC interrupt which is handled by
>>> the IMX6 gpc interrupt controller.
>>>
>>> Any dra7xxx, exynos, spear13xx, keystone, layerscape, hisi, qcom SoC
>>> users of designware PCIe core out there that can verify PCI MSI and
>>> legacy are both working at the same time?
>>>
>>> Lucas is the expert here and I believe he has the documentation for
>>> the designware core that Freescale doens't provide with the IMX6
>>> documentation so hopefully he can provide some insight. He's the one
>>> that has authored all the MSI support and has been using it.
>>>
>>> I typically advise our users to 'not' enable MSI because
>>> architecturally you can spread 4 distinct legacy irq's across CPU's
>>> better than a single shared irq.
>> Don't know if I'm facing similar problem, however devices connected in miniPCI slot behind
>> a PCIe-to-PCI bridge (MSI is disabled) using INTA all is working ok, including shared IRQ.
>> In case of INTB will not work, and the GIC irq quite often get stuck.
>>
> Roberto,
>
> What board/platform is this and what does /proc/interrupts look like?
It's a custom board
root at voneus-janas-imx6q:~# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
16: 936 637 2057 938 GIC 29 Edge twd
17: 0 0 0 0 GPC 55 Level i.MX Timer Tick
22: 247 0 0 0 GPC 26 Level 2020000.serial
34: 0 0 0 0 gpio-mxc 6 Edge Factory Reset Button
267: 0 0 0 0 GPC 49 Level imx_thermal
272: 0 0 0 0 GPC 19 Level rtc alarm
278: 0 0 0 0 GPC 2 Level sdma
281: 361 0 0 0 GIC 150 Level 2188000.ethernet
282: 0 0 0 0 GIC 151 Level 2188000.ethernet
283: 2882 0 0 0 GPC 25 Level mmc0
284: 95 0 0 0 GPC 37 Level 21a4000.i2c
290: 36546 0 0 0 GPC 123 Level PCIe PME, b4xxp
291: 2 0 0 0 GIC 137 Level 2101000.jr0
292: 0 0 0 0 GIC 138 Level 2102000.jr1
IPI0: 0 0 0 0 CPU wakeup interrupts
IPI1: 0 0 0 0 Timer broadcast interrupts
IPI2: 1642 1038 1626 1781 Rescheduling interrupts
IPI3: 95 95 122 119 Function call interrupts
IPI4: 3 0 2 0 Single function call interrupts
IPI5: 0 0 0 0 CPU stop interrupts
IPI6: 0 0 0 0 IRQ work interrupts
IPI7: 0 0 0 0 completion interrupts
Err: 0
>
> This sounds like what would happen if the downstream interrupts on the
> PCIe-to-PCI bridge are not mapped properly as was the case with a
> board I support (in which case I had to work out a bootloader fixup
> that placed a non-standard interrupt-map in the device-tree for the
> bridge). What bridge are you using?
PCIe-to-PCI bridge is a Ti XIO2001 where we are using INTA/B only wired 1:1
>
> Tim
>
next prev parent reply other threads:[~2016-03-29 16:44 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-25 13:32 [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity Krzysztof Hałasa
2016-03-25 13:32 ` Krzysztof Hałasa
2016-03-27 14:44 ` Fabio Estevam
2016-03-27 14:44 ` Fabio Estevam
2016-03-28 0:26 ` Fabio Estevam
2016-03-28 0:26 ` Fabio Estevam
2016-03-28 19:59 ` Tim Harvey
2016-03-28 19:59 ` Tim Harvey
2016-03-28 20:13 ` Fabio Estevam
2016-03-28 20:13 ` Fabio Estevam
2016-03-28 20:42 ` Tim Harvey
2016-03-28 20:42 ` Tim Harvey
2016-03-28 21:30 ` Fabio Estevam
2016-03-28 21:30 ` Fabio Estevam
2016-03-28 22:06 ` Tim Harvey
2016-03-28 22:06 ` Tim Harvey
2016-03-28 22:13 ` Fabio Estevam
2016-03-28 22:13 ` Fabio Estevam
2016-03-29 5:40 ` Krzysztof Hałasa
2016-03-29 5:40 ` Krzysztof Hałasa
2016-03-29 5:43 ` Krzysztof Hałasa
2016-03-29 5:43 ` Krzysztof Hałasa
2016-03-29 5:29 ` Krzysztof Hałasa
2016-03-29 5:29 ` Krzysztof Hałasa
2016-03-29 8:55 ` Lucas Stach
2016-03-29 8:55 ` Lucas Stach
2016-03-29 10:39 ` Krzysztof Hałasa
2016-03-29 10:39 ` Krzysztof Hałasa
2016-03-29 10:55 ` Lucas Stach
2016-03-29 10:55 ` Lucas Stach
2016-03-29 13:12 ` Arnd Bergmann
2016-03-29 13:12 ` Arnd Bergmann
2016-03-29 13:32 ` Tim Harvey
2016-03-29 13:32 ` Tim Harvey
2016-03-29 13:52 ` Arnd Bergmann
2016-03-29 13:52 ` Arnd Bergmann
2016-03-29 14:29 ` Tim Harvey
2016-03-29 14:29 ` Tim Harvey
2016-03-29 14:50 ` Arnd Bergmann
2016-03-29 14:50 ` Arnd Bergmann
2016-03-29 15:10 ` Tim Harvey
2016-03-29 15:10 ` Tim Harvey
2016-03-29 15:24 ` Arnd Bergmann
2016-03-29 15:24 ` Arnd Bergmann
2016-03-29 17:38 ` Tim Harvey
2016-03-29 17:38 ` Tim Harvey
2016-03-29 19:39 ` Arnd Bergmann
2016-03-29 19:39 ` Arnd Bergmann
2016-03-29 17:56 ` Marc Zyngier
2016-03-29 17:56 ` Marc Zyngier
2016-03-29 16:13 ` Roberto Fichera
2016-03-29 16:13 ` Roberto Fichera
2016-03-29 16:40 ` Tim Harvey
2016-03-29 16:40 ` Tim Harvey
2016-03-29 16:44 ` Roberto Fichera [this message]
2016-03-29 16:44 ` Roberto Fichera
2016-03-29 17:31 ` Tim Harvey
2016-03-29 17:31 ` Tim Harvey
2016-03-30 8:00 ` Roberto Fichera
2016-03-30 8:00 ` Roberto Fichera
2016-03-30 10:10 ` Arnd Bergmann
2016-03-30 10:10 ` Arnd Bergmann
2016-03-30 12:50 ` Roberto Fichera
2016-03-30 12:50 ` Roberto Fichera
2016-03-30 13:38 ` Tim Harvey
2016-03-30 13:38 ` Tim Harvey
2016-03-30 15:20 ` Roberto Fichera
2016-03-30 15:20 ` Roberto Fichera
2016-03-30 8:10 ` Krzysztof Hałasa
2016-03-30 8:10 ` Krzysztof Hałasa
2016-03-31 16:19 ` Tim Harvey
2016-03-31 16:19 ` Tim Harvey
2016-04-04 10:37 ` Krzysztof Hałasa
2016-04-04 10:37 ` Krzysztof Hałasa
2016-03-29 14:14 ` Fabio Estevam
2016-03-29 14:14 ` Fabio Estevam
2016-03-29 5:21 ` Krzysztof Hałasa
2016-03-29 5:21 ` Krzysztof Hałasa
2016-03-30 12:06 ` Petr Štetiar
2016-03-30 12:06 ` Petr Štetiar
2016-03-30 12:45 ` Fabio Estevam
2016-03-30 12:45 ` Fabio Estevam
2016-03-30 14:38 ` Marcel Ziswiler
2016-03-30 14:38 ` Marcel Ziswiler
2016-03-30 14:38 ` Marcel Ziswiler
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=56FAB0DB.3070303@tekno-soft.it \
--to=kernel@tekno-soft.it \
--cc=Richard.Zhu@freescale.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=festevam@gmail.com \
--cc=khalasa@piap.pl \
--cc=l.stach@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=tharvey@gateworks.com \
--cc=ynezz@true.cz \
/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.