linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Murali Karicheri <m-karicheri2@ti.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	<xobs@kosagi.com>,
	"Strashko, Grygorii" <grygorii.strashko@ti.com>,
	Mohit Kumar <mohit.kumar@st.com>,
	Jingoo Han <jg1.han@samsung.com>,
	"Shilimkar, Santosh" <santosh.shilimkar@ti.com>,
	Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v1 5/5] pci: keystone: add pcie driver based on designware core driver
Date: Fri, 16 May 2014 18:44:44 -0400	[thread overview]
Message-ID: <537694DC.3060507@ti.com> (raw)
In-Reply-To: <4195791.GS9XG8RaXW@wuerfel>

On 5/15/2014 12:28 PM, Arnd Bergmann wrote:
> On Thursday 15 May 2014 12:01:32 Murali Karicheri wrote:
>> +Sample bindings shown below:-
>> +
>> + - Remove ti,enable-linktrain if boot loader already does Link training and do EP
>> +   configuration.
>> + - Remove ti,init-phy if boot loader already initialize the phy and sets up pcie
>> +   link
> You actually have to document all the properties. Have a look at the
> other bindings for what this means.

Actually this is dw pcie variant. So I will document if there are any 
deviations from the dw-designware
bindings. Based on comments from Jingo, I think I need to add a new DT 
property for old hw that we
use in keystone. May be a compatibility string for older dw h/w like 
"snps ,dw-pcie-v3.65" is that we
could use and do things differently in the common code.

So I will update the Documentation of dw bindings  once we agree on this.
>> +
>> +               pcie@21800000 {
>> +                       compatible = "ti,keystone-pcie";
>> +                       device_type = "pci";
>> +                       clocks = <&clkpcie>;
>> +                       clock-names = "pcie";
> The dw-pcie binding lists two clocks.
Ok. As per dw documentation, pcie and pcie_bus are the clocks. But 
pci-imx6 is currently not using pcie_bus. So the pcie_bus
clock is actually optional. In the case of keystone pcie, bus clock is 
provided by the phy hardware and if I need to provide
a clock for bus, it has to be a dummy or change documentation to make 
pcie_bus an optional clock. I prefer later, but want
to know if this is true for pci-imx6. There is also a plan to move the 
pcie clock API call to designware core. So making pcie_bus
clock optional looks correct to me.

Seen/Jingoo,  any comments?

>> +                       #address-cells = >;
>> +                       #size-cells = <2>;
>> +                       reg =  <0x21800000 0x1000>, <0x0262014c 4>;
>> +                       reg-names = "reg_rc_app", "reg_devcfg";
> There should be standard names that are documented in the binding.

Currently  Documentation says

- reg: base addresses and lengths of the pcie controller,
     the phy controller, additional register for the phy controller.

And following dw drivers defines as

samsung,exynos5440-pcie

         reg = <0x290000 0x1000
             0x270000 0x1000
             0x271000 0x40>;

fsl,imx6q-pcie"
         reg = <0x01ffc000 0x4000>; /* DBI */

There are no names used for registers. So this needs to be documented in 
the dw-designware
bindings. reg_dbi is what is common to pci controller assuming at index 
0 of the both above drivers use
reg_dbi address for config space. Shall I modify the documentation to 
include optional reg name
reg_dbi  for config space base address registers? Additional registers 
are optional and varies from
platform to platform. Phy registers are actually part of Phy driver and 
should be removed from
the dw-documentation bindings. Agree?

>
>> +                       interrupts = <GIC_SPI 30 IRQ_TYPE_EDGE_RISING>,
>> +                                       <GIC_SPI 31 IRQ_TYPE_EDGE_RISING>,
>> +                                       <GIC_SPI 32 IRQ_TYPE_EDGE_RISING>,
>> +                                       <GIC_SPI 33 IRQ_TYPE_EDGE_RISING>,
>> +                                       <GIC_SPI 34 IRQ_TYPE_EDGE_RISING>,
>> +                                       <GIC_SPI 35 IRQ_TYPE_EDGE_RISING>,
>> +                                       <GIC_SPI 36 IRQ_TYPE_EDGE_RISING>,
>> +                                       <GIC_SPI 37 IRQ_TYPE_EDGE_RISING>,
>> +                                       <GIC_SPI 38 IRQ_TYPE_EDGE_RISING>; /* Error IRQ */
> What are all these interrupts?
These are MSI interrupts tied to the GIC over which MSI interrupts are 
multiplexed.  I will document
it in the keystone PCI DT bindings.
>> +                       ranges = <0x00000800 0 0x21801000 0x21801000 0 0x0002000    /* Configuration space */
>> +                                 0x81000000 0 0          0x24000000 0 0x4000       /* downstream I/O */
>> +                                 0x82000000 0 0x50000000 0x50000000 0 0x10000000>; /* non-prefetchable memory */
> Please move the config space into 'reg' now instead of 'ranges'.
> This was a mistake earlier, and there are already other front-ends
> doing the same thing.
  This has to be coordinated with other drivers when DW core makes the 
change.

Jingoo, Sean,

What is the plan for this change? I  have to defer this currently.

>
>> +                       num-lanes = <2>;
>> +                       ti,enable-linktrain;
>> +                       ti,init-phy;
>> +
>> +                       /* PCIE phy */
>> +                       phys = <&pcie0_phy>;
>> +                       phy-names = "pcie-phy";
>> +
>> +                       #interrupt-cells = <1>;
>> +                       interrupt-map-mask = <0 0 0 0>;
>> +                       interrupt-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
> I think this is the wrong map-mask.
I think this should be changed to

interrupt-map-mask = <0 0 0 0x7> ?

>
> 	Arnd


  reply	other threads:[~2014-05-16 22:44 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-15 16:01 [PATCH v1 0/5] Add Keystone PCIe controller driver Murali Karicheri
2014-05-15 16:01 ` [PATCH v1 1/5] ARM: keystone: add pcie related options Murali Karicheri
2014-05-16  0:27   ` Jingoo Han
2014-05-16 14:36     ` Karicheri, Muralidharan
2014-05-15 16:01 ` [PATCH v1 2/5] pci: designware: enhancements to support keystone pcie Murali Karicheri
2014-05-16  2:40   ` Jingoo Han
2014-05-16 20:46   ` Karicheri, Muralidharan
2014-05-16 22:15   ` Kumar Gala
2014-05-16 22:49     ` Murali Karicheri
2014-05-15 16:01 ` [PATCH v1 3/5] phy: pci serdes phy driver for keystone Murali Karicheri
2014-05-15 16:14   ` Arnd Bergmann
2014-05-23 17:14     ` Murali Karicheri
2014-05-23 19:23       ` Arnd Bergmann
2014-05-27 16:46         ` Murali Karicheri
2014-05-27 18:36           ` Arnd Bergmann
2014-06-02  6:16   ` Kishon Vijay Abraham I
2014-06-02  6:45     ` Jingoo Han
2014-06-02 14:28     ` Murali Karicheri
2014-05-15 16:01 ` [PATCH v1 4/5] pci: dw: add common functions to support old hw based pci driver Murali Karicheri
2014-05-16 20:47   ` Karicheri, Muralidharan
2014-05-15 16:01 ` [PATCH v1 5/5] pci: keystone: add pcie driver based on designware core driver Murali Karicheri
2014-05-15 16:23   ` Arnd Bergmann
2014-05-15 17:45     ` Murali Karicheri
2014-05-15 18:20       ` Arnd Bergmann
2014-05-15 18:39         ` Jason Gunthorpe
2014-05-15 20:04           ` Murali Karicheri
2014-05-15 20:52             ` Jason Gunthorpe
2014-05-16 20:29               ` Karicheri, Muralidharan
2014-05-20 17:02                 ` Jason Gunthorpe
2014-05-20 17:22                   ` Bjorn Helgaas
2014-05-20 17:42                     ` Jason Gunthorpe
2014-05-21 23:32                   ` Murali Karicheri
2014-05-22  0:55                     ` Jason Gunthorpe
     [not found]                       ` <537E7823.5060609@ti.com>
2014-05-26 23:31                         ` Jason Gunthorpe
2014-05-16 20:26         ` Murali Karicheri
2014-05-19 12:06           ` Arnd Bergmann
2014-05-19 21:10             ` Murali Karicheri
2014-05-20  7:55               ` Arnd Bergmann
2014-05-20 17:17                 ` Bjorn Helgaas
2014-05-29 15:34     ` Murali Karicheri
2014-05-15 16:28   ` Arnd Bergmann
2014-05-16 22:44     ` Murali Karicheri [this message]
2014-05-19 12:12       ` Arnd Bergmann
2014-05-16 20:47   ` Karicheri, Muralidharan
2014-05-16  0:48 ` [PATCH v1 0/5] Add Keystone PCIe controller driver Jingoo Han
2014-05-16 20:40   ` Karicheri, Muralidharan

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=537694DC.3060507@ti.com \
    --to=m-karicheri2@ti.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=grygorii.strashko@ti.com \
    --cc=jg1.han@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mohit.kumar@st.com \
    --cc=santosh.shilimkar@ti.com \
    --cc=xobs@kosagi.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).