From: Murali Karicheri <m-karicheri2@ti.com>
To: Andrew Murray <amurray@embedded-bits.co.uk>
Cc: Thierry Reding <thierry.reding@gmail.com>,
Arnd Bergmann <arnd@arndb.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Richard Zhu <r65037@freescale.com>,
"linux-samsung-soc@vger.kernel.org"
<linux-samsung-soc@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Jingoo Han <jg1.han@samsung.com>,
LKML <linux-kernel@vger.kernel.org>,
"Shilimkar, Santosh" <santosh.shilimkar@ti.com>,
Mohit Kumar <mohit.kumar@st.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Kukjin Kim <kgene.kim@samsung.com>,
Shawn Guo <shawn.guo@linaro.org>
Subject: Re: [RESEND: RFC PATCH 3/3] pcie: keystone: add pcie driver based on designware core driver
Date: Wed, 2 Apr 2014 13:23:33 -0400 [thread overview]
Message-ID: <533C4795.9080209@ti.com> (raw)
In-Reply-To: <CAPcvp5FEFbP_Fwc47V=LppiZnfbTgPqaAAm-A9K17dVEZWwHQQ@mail.gmail.com>
On 4/2/2014 12:47 PM, Andrew Murray wrote:
> On 2 April 2014 16:43, Murali Karicheri <m-karicheri2@ti.com> wrote:
>
>> Keystone pcie driver is developed based on other dw based pcie drivers
>>
>> such as pci-exynos that uses subsys_initcall(). I am new to this list,
>>
>> probably Jingoo (copied) has some history on why we can't use module.
>> For now I will keep it as is and can be re-visited in the next revisions.
>> Also I will experiment with PCIE port driver as well.
>>
>>
>> BTW, PCIE driver currently uses Legacy or MSI IRQ. Keystone PCI has
>> a platform IRQ. Is DT based irq configuration is the appropriate way
>> to add this capability?
> As far as I am aware - the PCI standards define a particular way for
> devices to describe which interrupt will be used for things like
> hotplug, AER and PME. These interrupts are always PCI interrupts (i.e.
> MSI/MSI-X/legacy). Thus the port services code in the kernel uses
> standard configuration space accesses to determine the interrupt to
> use. Also note that it's not just the host bridge that can provide
> these services but any PCIE device, I guess in this sense a host
> bridge is treated like any other device.
>
> If my understanding is correct I don't believe the current port
> services code allows exceptions to this, i.e. to say this host bridge
> actually uses a platform IRQ for AER rather than an MSI. Though this
> may be quite useful as I suspect many host bridges provide interrupts
> for things like PME through platform IRQs rather that PCI interrupts.
>
> Does the Keystone have platform IRQs for things like AER? Is that
> because the IP makes these events available through platform IRQs in
> addition to the standard PCI means?
>
> Andrew Murray
Andrew,
Yes. Keystone PCIe hw is based on designware hw version v3.65 that
implements
Error interrupt as a platform IRQ only (not in addition) and
unfortunately standard
PCI means are not supported. The latter versions do support standard PCI
means.
Murali
WARNING: multiple messages have this Message-ID (diff)
From: m-karicheri2@ti.com (Murali Karicheri)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND: RFC PATCH 3/3] pcie: keystone: add pcie driver based on designware core driver
Date: Wed, 2 Apr 2014 13:23:33 -0400 [thread overview]
Message-ID: <533C4795.9080209@ti.com> (raw)
In-Reply-To: <CAPcvp5FEFbP_Fwc47V=LppiZnfbTgPqaAAm-A9K17dVEZWwHQQ@mail.gmail.com>
On 4/2/2014 12:47 PM, Andrew Murray wrote:
> On 2 April 2014 16:43, Murali Karicheri <m-karicheri2@ti.com> wrote:
>
>> Keystone pcie driver is developed based on other dw based pcie drivers
>>
>> such as pci-exynos that uses subsys_initcall(). I am new to this list,
>>
>> probably Jingoo (copied) has some history on why we can't use module.
>> For now I will keep it as is and can be re-visited in the next revisions.
>> Also I will experiment with PCIE port driver as well.
>>
>>
>> BTW, PCIE driver currently uses Legacy or MSI IRQ. Keystone PCI has
>> a platform IRQ. Is DT based irq configuration is the appropriate way
>> to add this capability?
> As far as I am aware - the PCI standards define a particular way for
> devices to describe which interrupt will be used for things like
> hotplug, AER and PME. These interrupts are always PCI interrupts (i.e.
> MSI/MSI-X/legacy). Thus the port services code in the kernel uses
> standard configuration space accesses to determine the interrupt to
> use. Also note that it's not just the host bridge that can provide
> these services but any PCIE device, I guess in this sense a host
> bridge is treated like any other device.
>
> If my understanding is correct I don't believe the current port
> services code allows exceptions to this, i.e. to say this host bridge
> actually uses a platform IRQ for AER rather than an MSI. Though this
> may be quite useful as I suspect many host bridges provide interrupts
> for things like PME through platform IRQs rather that PCI interrupts.
>
> Does the Keystone have platform IRQs for things like AER? Is that
> because the IP makes these events available through platform IRQs in
> addition to the standard PCI means?
>
> Andrew Murray
Andrew,
Yes. Keystone PCIe hw is based on designware hw version v3.65 that
implements
Error interrupt as a platform IRQ only (not in addition) and
unfortunately standard
PCI means are not supported. The latter versions do support standard PCI
means.
Murali
next prev parent reply other threads:[~2014-04-02 17:24 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-25 0:35 [RESEND: RFC PATCH 0/3] Add Keystone pcie driver Murali Karicheri
2014-03-25 0:35 ` Murali Karicheri
2014-03-25 0:35 ` Murali Karicheri
2014-03-25 0:35 ` [RESEND: RFC PATCH 2/3] pci: designware: enhancements to support keystone pcie Murali Karicheri
2014-03-25 0:35 ` Murali Karicheri
2014-03-25 0:35 ` Murali Karicheri
2014-03-25 0:35 ` [RESEND: RFC PATCH 1/3] ARM: keystone: add pcie related options Murali Karicheri
2014-03-25 0:35 ` Murali Karicheri
2014-03-25 0:35 ` Murali Karicheri
2014-03-25 0:35 ` [RESEND: RFC PATCH 3/3] pcie: keystone: add pcie driver based on designware core driver Murali Karicheri
2014-03-25 0:35 ` Murali Karicheri
2014-03-25 0:35 ` Murali Karicheri
2014-03-25 7:44 ` Arnd Bergmann
2014-03-25 7:44 ` Arnd Bergmann
2014-03-25 7:44 ` Arnd Bergmann
2014-03-25 10:35 ` Thierry Reding
2014-03-25 10:35 ` Thierry Reding
2014-03-25 11:46 ` Andrew Murray
2014-03-25 11:46 ` Andrew Murray
[not found] ` <533C300E.7070109@ti.com>
2014-04-02 16:47 ` Andrew Murray
2014-04-02 16:47 ` Andrew Murray
2014-04-02 17:23 ` Murali Karicheri [this message]
2014-04-02 17:23 ` Murali Karicheri
2014-03-25 16:54 ` Jason Gunthorpe
2014-03-25 16:54 ` Jason Gunthorpe
2014-04-07 16:38 ` Murali Karicheri
2014-04-07 16:38 ` Murali Karicheri
2014-04-07 16:38 ` Murali Karicheri
2014-04-07 16:46 ` Jason Gunthorpe
2014-04-07 16:46 ` Jason Gunthorpe
2014-03-27 14:01 ` Karicheri, Muralidharan
2014-03-27 14:01 ` Karicheri, Muralidharan
2014-03-27 14:01 ` Karicheri, Muralidharan
2014-04-02 17:17 ` Murali Karicheri
2014-04-02 17:17 ` Murali Karicheri
2014-04-02 17:17 ` Murali Karicheri
2014-04-03 8:32 ` Lucas Stach
2014-04-03 8:32 ` Lucas Stach
2014-04-04 16:15 ` Murali Karicheri
2014-04-04 16:15 ` Murali Karicheri
2014-04-04 16:15 ` Murali Karicheri
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=533C4795.9080209@ti.com \
--to=m-karicheri2@ti.com \
--cc=amurray@embedded-bits.co.uk \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=jg1.han@samsung.com \
--cc=kgene.kim@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mohit.kumar@st.com \
--cc=r65037@freescale.com \
--cc=santosh.shilimkar@ti.com \
--cc=shawn.guo@linaro.org \
--cc=thierry.reding@gmail.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 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.