All of lore.kernel.org
 help / color / mirror / Atom feed
From: Murali Karicheri <m-karicheri2@ti.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: 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>,
	"linux-kernel@vger.kernel.org" <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: Mon, 7 Apr 2014 12:38:23 -0400	[thread overview]
Message-ID: <5342D47F.4010506@ti.com> (raw)
In-Reply-To: <20140325165421.GB30641@obsidianresearch.com>

On 3/25/2014 12:54 PM, Jason Gunthorpe wrote:
> On Tue, Mar 25, 2014 at 08:44:36AM +0100, Arnd Bergmann wrote:
>
>> I have no idea how this would work with the standard interrupt-map property,
>> since the legacy interrupt host is now the same device as the pci host.
>>
>> Maybe it's better to move the legacy irqchip handling entirely out of
>> the driver and use a separate device node for the registers so it can
>> come with its own #interrupt-cells, and then refer to this irqchip from
>> the interrupt-map.
> The other DW PCI-E drivers are being fixed to use interrupt-map, so I
> think this driver should be fixed before it goes in as well.
Jason,

Could you send me a patch reference or branch that I can review to 
better understand
changes required in my driver to use the bindings you have described below?

Murali
> Other PCI-E hosts have handled this particular problem with a
> construction like this:
>
>         pcie@21800000 {
>                 compatible = "ti,keystone2-pcie";
>                 device_type = "pci";
>                 #address-cells = <3>;
>                 #size-cells = <2>;
>                 #interrupt-cells = <1>;
> 	       reg = ..
>
>                 pcie_intc: interrupt-controller {
>                    interrupt-controller;
> 		  #address-cells = <0>;
>                    #interrupt-cells = <1>;
>                 }
>
>                 interrupts =  ... enough to decode INTx;
>
> 	       interrtup-map = <0 0 0 1 &pcie_intc 1>, // INT A
> 	                       <0 0 0 2 &pcie_intc 2>, // INT B
>                                 <0 0 0 3 &pcie_intc 3>, // INT C
>                                 <0 0 0 4 &pcie_intc 4>; // INT D
>         }
>
> When the legacy irq domain is created it should be bound to the
> pcie_intc node, not to pcie node.
>
> ks_pcie_map_irq should be removed.
The latest dw core driver still had map_irq() being provided by the driver.
So any patch reference will help me understand that you describe here.

Thanks

Murali
>
>>> +#ifdef CONFIG_PCIE_KEYSTONE
>>> +/*
>>> + * The KeyStone PCIe controller has maximum read request size of 256 bytes.
>>> + * Force this configuration for all EP including bridges.
>>> + */
>>> +static void quirk_limit_readrequest(struct pci_dev *dev)
>>> +{
>>> +	pcie_set_readrq(dev, 256);
>>> +}
>>> +DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_limit_readrequest);
>>> +#endif /* CONFIG_TI_KEYSTONE_PCIE */
>> You can't do this:
>>
>> A quirk for a specific hardware must not be enabled by compile-time options.
>> You have to find a different way to do this.
> This configuration should happen automatically by the PCI core if the
> config spaces are correct. See pcie_write_mrrs, pcie_write_mps,
> pcie_bus_configure_settings, etc.
>
> Your host will need to conform to the PCI spec and provide a root
> port bridge header for this to work.
>
> Also, even in the keystone case the MRRS should not be globally forced
> like this, there may be other bridges in the system with a 128 byte
> MPS.
>
> Jason


WARNING: multiple messages have this Message-ID (diff)
From: Murali Karicheri <m-karicheri2@ti.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Richard Zhu <r65037@freescale.com>,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Jingoo Han <jg1.han@samsung.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Kukjin Kim <kgene.kim@samsung.com>,
	"Shilimkar, Santosh" <santosh.shilimkar@ti.com>,
	Mohit Kumar <mohit.kumar@st.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Shawn Guo <shawn.guo@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RESEND: RFC PATCH 3/3] pcie: keystone: add pcie driver based on designware core driver
Date: Mon, 7 Apr 2014 12:38:23 -0400	[thread overview]
Message-ID: <5342D47F.4010506@ti.com> (raw)
In-Reply-To: <20140325165421.GB30641@obsidianresearch.com>

On 3/25/2014 12:54 PM, Jason Gunthorpe wrote:
> On Tue, Mar 25, 2014 at 08:44:36AM +0100, Arnd Bergmann wrote:
>
>> I have no idea how this would work with the standard interrupt-map property,
>> since the legacy interrupt host is now the same device as the pci host.
>>
>> Maybe it's better to move the legacy irqchip handling entirely out of
>> the driver and use a separate device node for the registers so it can
>> come with its own #interrupt-cells, and then refer to this irqchip from
>> the interrupt-map.
> The other DW PCI-E drivers are being fixed to use interrupt-map, so I
> think this driver should be fixed before it goes in as well.
Jason,

Could you send me a patch reference or branch that I can review to 
better understand
changes required in my driver to use the bindings you have described below?

Murali
> Other PCI-E hosts have handled this particular problem with a
> construction like this:
>
>         pcie@21800000 {
>                 compatible = "ti,keystone2-pcie";
>                 device_type = "pci";
>                 #address-cells = <3>;
>                 #size-cells = <2>;
>                 #interrupt-cells = <1>;
> 	       reg = ..
>
>                 pcie_intc: interrupt-controller {
>                    interrupt-controller;
> 		  #address-cells = <0>;
>                    #interrupt-cells = <1>;
>                 }
>
>                 interrupts =  ... enough to decode INTx;
>
> 	       interrtup-map = <0 0 0 1 &pcie_intc 1>, // INT A
> 	                       <0 0 0 2 &pcie_intc 2>, // INT B
>                                 <0 0 0 3 &pcie_intc 3>, // INT C
>                                 <0 0 0 4 &pcie_intc 4>; // INT D
>         }
>
> When the legacy irq domain is created it should be bound to the
> pcie_intc node, not to pcie node.
>
> ks_pcie_map_irq should be removed.
The latest dw core driver still had map_irq() being provided by the driver.
So any patch reference will help me understand that you describe here.

Thanks

Murali
>
>>> +#ifdef CONFIG_PCIE_KEYSTONE
>>> +/*
>>> + * The KeyStone PCIe controller has maximum read request size of 256 bytes.
>>> + * Force this configuration for all EP including bridges.
>>> + */
>>> +static void quirk_limit_readrequest(struct pci_dev *dev)
>>> +{
>>> +	pcie_set_readrq(dev, 256);
>>> +}
>>> +DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_limit_readrequest);
>>> +#endif /* CONFIG_TI_KEYSTONE_PCIE */
>> You can't do this:
>>
>> A quirk for a specific hardware must not be enabled by compile-time options.
>> You have to find a different way to do this.
> This configuration should happen automatically by the PCI core if the
> config spaces are correct. See pcie_write_mrrs, pcie_write_mps,
> pcie_bus_configure_settings, etc.
>
> Your host will need to conform to the PCI spec and provide a root
> port bridge header for this to work.
>
> Also, even in the keystone case the MRRS should not be globally forced
> like this, there may be other bridges in the system with a 128 byte
> MPS.
>
> Jason

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: Mon, 7 Apr 2014 12:38:23 -0400	[thread overview]
Message-ID: <5342D47F.4010506@ti.com> (raw)
In-Reply-To: <20140325165421.GB30641@obsidianresearch.com>

On 3/25/2014 12:54 PM, Jason Gunthorpe wrote:
> On Tue, Mar 25, 2014 at 08:44:36AM +0100, Arnd Bergmann wrote:
>
>> I have no idea how this would work with the standard interrupt-map property,
>> since the legacy interrupt host is now the same device as the pci host.
>>
>> Maybe it's better to move the legacy irqchip handling entirely out of
>> the driver and use a separate device node for the registers so it can
>> come with its own #interrupt-cells, and then refer to this irqchip from
>> the interrupt-map.
> The other DW PCI-E drivers are being fixed to use interrupt-map, so I
> think this driver should be fixed before it goes in as well.
Jason,

Could you send me a patch reference or branch that I can review to 
better understand
changes required in my driver to use the bindings you have described below?

Murali
> Other PCI-E hosts have handled this particular problem with a
> construction like this:
>
>         pcie at 21800000 {
>                 compatible = "ti,keystone2-pcie";
>                 device_type = "pci";
>                 #address-cells = <3>;
>                 #size-cells = <2>;
>                 #interrupt-cells = <1>;
> 	       reg = ..
>
>                 pcie_intc: interrupt-controller {
>                    interrupt-controller;
> 		  #address-cells = <0>;
>                    #interrupt-cells = <1>;
>                 }
>
>                 interrupts =  ... enough to decode INTx;
>
> 	       interrtup-map = <0 0 0 1 &pcie_intc 1>, // INT A
> 	                       <0 0 0 2 &pcie_intc 2>, // INT B
>                                 <0 0 0 3 &pcie_intc 3>, // INT C
>                                 <0 0 0 4 &pcie_intc 4>; // INT D
>         }
>
> When the legacy irq domain is created it should be bound to the
> pcie_intc node, not to pcie node.
>
> ks_pcie_map_irq should be removed.
The latest dw core driver still had map_irq() being provided by the driver.
So any patch reference will help me understand that you describe here.

Thanks

Murali
>
>>> +#ifdef CONFIG_PCIE_KEYSTONE
>>> +/*
>>> + * The KeyStone PCIe controller has maximum read request size of 256 bytes.
>>> + * Force this configuration for all EP including bridges.
>>> + */
>>> +static void quirk_limit_readrequest(struct pci_dev *dev)
>>> +{
>>> +	pcie_set_readrq(dev, 256);
>>> +}
>>> +DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_limit_readrequest);
>>> +#endif /* CONFIG_TI_KEYSTONE_PCIE */
>> You can't do this:
>>
>> A quirk for a specific hardware must not be enabled by compile-time options.
>> You have to find a different way to do this.
> This configuration should happen automatically by the PCI core if the
> config spaces are correct. See pcie_write_mrrs, pcie_write_mps,
> pcie_bus_configure_settings, etc.
>
> Your host will need to conform to the PCI spec and provide a root
> port bridge header for this to work.
>
> Also, even in the keystone case the MRRS should not be globally forced
> like this, there may be other bridges in the system with a 128 byte
> MPS.
>
> Jason

  reply	other threads:[~2014-04-07 16:38 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
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 [this message]
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=5342D47F.4010506@ti.com \
    --to=m-karicheri2@ti.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=jg1.han@samsung.com \
    --cc=jgunthorpe@obsidianresearch.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 \
    /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.