pcie designware question

pcie designware question

[Karicheri, Muralidharan]

Hi,

I am working to port my pcie driver to pcie-designware core driver. The pcie sub system
 on our platform  has 32 OUTBOUND regions and 2 INBOUND regions. In my current driver,
I use internal memory map of CPU to access the RC's config/application space as well EP's
config space. a 4K range is available to access the EP's config space. To allow write/read to
the EP's config space, the driver basically write the bus, device and function number to the
 application CFG_SETUP register and then access the corresponding EP's config register.

I have reviewed the designware.c code and the glue logic driver pci-exynos.c and couldn't
understand few things.

1. Our pcie ss is based on designware core and following addresses are not listed in our IP's
 data manual. Where is defined? It does show the rest of the offsets defined in
 drivers/pci/host/designware.c and 

#define PCIE_ATU_VIEWPORT               0x900
#define PCIE_ATU_REGION_INBOUND         (0x1 << 31)
#define PCIE_ATU_REGION_OUTBOUND        (0x0 << 31)
#define PCIE_ATU_REGION_INDEX1          (0x1 << 0)
#define PCIE_ATU_REGION_INDEX0          (0x0 << 0)
#define PCIE_ATU_CR1                    0x904
#define PCIE_ATU_TYPE_MEM               (0x0 << 0)
#define PCIE_ATU_TYPE_IO                (0x2 << 0)
#define PCIE_ATU_TYPE_CFG0              (0x4 << 0)
#define PCIE_ATU_TYPE_CFG1              (0x5 << 0)
#define PCIE_ATU_CR2                    0x908
#define PCIE_ATU_ENABLE                 (0x1 << 31)
#define PCIE_ATU_BAR_MODE_ENABLE        (0x1 << 30)
#define PCIE_ATU_LOWER_BASE             0x90C
#define PCIE_ATU_UPPER_BASE             0x910
#define PCIE_ATU_LIMIT                  0x914
#define PCIE_ATU_LOWER_TARGET           0x918
#define PCIE_ATU_BUS(x)                 (((x) & 0xff) << 24)
#define PCIE_ATU_DEV(x)                 (((x) & 0x1f) << 19)
#define PCIE_ATU_FUNC(x)                (((x) & 0x7) << 16)
#define PCIE_ATU_UPPER_TARGET           0x91C

2. My understanding is that the designware core currently support 2 OUTBOUND regions
and 2 INBOUND regions. Is this true? Is there a plan to support more than 2?
3. Is there a documentation explaining how the ATU handling code is designed? Basically
as I can't find ATU specific registers defined in the ss spec, I am not able to understand
this code. I do see the application space in our ss spec defining OUTBOUND INDEX/OFFSET
register to configure OUTBOUND regions and IB registers to define the INBOUND region.

4. What is the base address variable used to access RC's application register space? dbi_base
in struct pcie_port ? Also I am assuming this is used for accessing this space from internal
CPU bus and cfg0_base and cfg1_base for accessing it from pci bus. Is this right?

I am trying to figure this out myself, but if someone could explain these, that will be great!

Thanks.

Murali Karicheri
Linux Kernel, Software Development

Re: pcie designware question

[Bjorn Helgaas]

[+cc Mohit, Jingoo]

On Thu, Dec 19, 2013 at 3:01 PM, Karicheri, Muralidharan
<m-karicheri2@ti.com> wrote:
> Hi,
>
> I am working to port my pcie driver to pcie-designware core driver. The pcie sub system
>  on our platform  has 32 OUTBOUND regions and 2 INBOUND regions. In my current driver,
> I use internal memory map of CPU to access the RC's config/application space as well EP's
> config space. a 4K range is available to access the EP's config space. To allow write/read to
> the EP's config space, the driver basically write the bus, device and function number to the
>  application CFG_SETUP register and then access the corresponding EP's config register.
>
> I have reviewed the designware.c code and the glue logic driver pci-exynos.c and couldn't
> understand few things.
>
> 1. Our pcie ss is based on designware core and following addresses are not listed in our IP's
>  data manual. Where is defined? It does show the rest of the offsets defined in
>  drivers/pci/host/designware.c and
>
> #define PCIE_ATU_VIEWPORT               0x900
> #define PCIE_ATU_REGION_INBOUND         (0x1 << 31)
> #define PCIE_ATU_REGION_OUTBOUND        (0x0 << 31)
> #define PCIE_ATU_REGION_INDEX1          (0x1 << 0)
> #define PCIE_ATU_REGION_INDEX0          (0x0 << 0)
> #define PCIE_ATU_CR1                    0x904
> #define PCIE_ATU_TYPE_MEM               (0x0 << 0)
> #define PCIE_ATU_TYPE_IO                (0x2 << 0)
> #define PCIE_ATU_TYPE_CFG0              (0x4 << 0)
> #define PCIE_ATU_TYPE_CFG1              (0x5 << 0)
> #define PCIE_ATU_CR2                    0x908
> #define PCIE_ATU_ENABLE                 (0x1 << 31)
> #define PCIE_ATU_BAR_MODE_ENABLE        (0x1 << 30)
> #define PCIE_ATU_LOWER_BASE             0x90C
> #define PCIE_ATU_UPPER_BASE             0x910
> #define PCIE_ATU_LIMIT                  0x914
> #define PCIE_ATU_LOWER_TARGET           0x918
> #define PCIE_ATU_BUS(x)                 (((x) & 0xff) << 24)
> #define PCIE_ATU_DEV(x)                 (((x) & 0x1f) << 19)
> #define PCIE_ATU_FUNC(x)                (((x) & 0x7) << 16)
> #define PCIE_ATU_UPPER_TARGET           0x91C
>
> 2. My understanding is that the designware core currently support 2 OUTBOUND regions
> and 2 INBOUND regions. Is this true? Is there a plan to support more than 2?
> 3. Is there a documentation explaining how the ATU handling code is designed? Basically
> as I can't find ATU specific registers defined in the ss spec, I am not able to understand
> this code. I do see the application space in our ss spec defining OUTBOUND INDEX/OFFSET
> register to configure OUTBOUND regions and IB registers to define the INBOUND region.
>
> 4. What is the base address variable used to access RC's application register space? dbi_base
> in struct pcie_port ? Also I am assuming this is used for accessing this space from internal
> CPU bus and cfg0_base and cfg1_base for accessing it from pci bus. Is this right?
>
> I am trying to figure this out myself, but if someone could explain these, that will be great!
>
> Thanks.
>
> Murali Karicheri
> Linux Kernel, Software Development
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: pcie designware question

[Karicheri, Muralidharan]

Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQmpvcm4gSGVsZ2FhcyBbbWFpbHRv
OmJoZWxnYWFzQGdvb2dsZS5jb21dDQo+U2VudDogVGh1cnNkYXksIERlY2VtYmVyIDE5LCAyMDEz
IDU6NTggUE0NCj5UbzogS2FyaWNoZXJpLCBNdXJhbGlkaGFyYW4NCj5DYzogbGludXgtcGNpQHZn
ZXIua2VybmVsLm9yZzsgTW9oaXQgS3VtYXI7IEppbmdvbyBIYW4NCj5TdWJqZWN0OiBSZTogcGNp
ZSBkZXNpZ253YXJlIHF1ZXN0aW9uDQo+DQo+WytjYyBNb2hpdCwgSmluZ29vXQ0KPg0KQmpvcm4s
DQoNClRoYW5rcyBmb3IgZm9yd2FyZGluZyB0aGlzIHRvIGV4cGVydHMuDQoNCk11cmFsaQ0KPk9u
IFRodSwgRGVjIDE5LCAyMDEzIGF0IDM6MDEgUE0sIEthcmljaGVyaSwgTXVyYWxpZGhhcmFuIDxt
LWthcmljaGVyaTJAdGkuY29tPiB3cm90ZToNCj4+IEhpLA0KPj4NCj4+IEkgYW0gd29ya2luZyB0
byBwb3J0IG15IHBjaWUgZHJpdmVyIHRvIHBjaWUtZGVzaWdud2FyZSBjb3JlIGRyaXZlci4NCj4+
IFRoZSBwY2llIHN1YiBzeXN0ZW0gIG9uIG91ciBwbGF0Zm9ybSAgaGFzIDMyIE9VVEJPVU5EIHJl
Z2lvbnMgYW5kIDINCj4+IElOQk9VTkQgcmVnaW9ucy4gSW4gbXkgY3VycmVudCBkcml2ZXIsIEkg
dXNlIGludGVybmFsIG1lbW9yeSBtYXAgb2YNCj4+IENQVSB0byBhY2Nlc3MgdGhlIFJDJ3MgY29u
ZmlnL2FwcGxpY2F0aW9uIHNwYWNlIGFzIHdlbGwgRVAncyBjb25maWcNCj4+IHNwYWNlLiBhIDRL
IHJhbmdlIGlzIGF2YWlsYWJsZSB0byBhY2Nlc3MgdGhlIEVQJ3MgY29uZmlnIHNwYWNlLiBUbw0K
Pj4gYWxsb3cgd3JpdGUvcmVhZCB0byB0aGUgRVAncyBjb25maWcgc3BhY2UsIHRoZSBkcml2ZXIg
YmFzaWNhbGx5IHdyaXRlIHRoZSBidXMsIGRldmljZSBhbmQNCj5mdW5jdGlvbiBudW1iZXIgdG8g
dGhlICBhcHBsaWNhdGlvbiBDRkdfU0VUVVAgcmVnaXN0ZXIgYW5kIHRoZW4gYWNjZXNzIHRoZSBj
b3JyZXNwb25kaW5nDQo+RVAncyBjb25maWcgcmVnaXN0ZXIuDQo+Pg0KPj4gSSBoYXZlIHJldmll
d2VkIHRoZSBkZXNpZ253YXJlLmMgY29kZSBhbmQgdGhlIGdsdWUgbG9naWMgZHJpdmVyDQo+PiBw
Y2ktZXh5bm9zLmMgYW5kIGNvdWxkbid0IHVuZGVyc3RhbmQgZmV3IHRoaW5ncy4NCj4+DQo+PiAx
LiBPdXIgcGNpZSBzcyBpcyBiYXNlZCBvbiBkZXNpZ253YXJlIGNvcmUgYW5kIGZvbGxvd2luZyBh
ZGRyZXNzZXMgYXJlDQo+PiBub3QgbGlzdGVkIGluIG91ciBJUCdzICBkYXRhIG1hbnVhbC4gV2hl
cmUgaXMgZGVmaW5lZD8gSXQgZG9lcyBzaG93DQo+PiB0aGUgcmVzdCBvZiB0aGUgb2Zmc2V0cyBk
ZWZpbmVkIGluICBkcml2ZXJzL3BjaS9ob3N0L2Rlc2lnbndhcmUuYyBhbmQNCj4+DQo+PiAjZGVm
aW5lIFBDSUVfQVRVX1ZJRVdQT1JUICAgICAgICAgICAgICAgMHg5MDANCj4+ICNkZWZpbmUgUENJ
RV9BVFVfUkVHSU9OX0lOQk9VTkQgICAgICAgICAoMHgxIDw8IDMxKQ0KPj4gI2RlZmluZSBQQ0lF
X0FUVV9SRUdJT05fT1VUQk9VTkQgICAgICAgICgweDAgPDwgMzEpDQo+PiAjZGVmaW5lIFBDSUVf
QVRVX1JFR0lPTl9JTkRFWDEgICAgICAgICAgKDB4MSA8PCAwKQ0KPj4gI2RlZmluZSBQQ0lFX0FU
VV9SRUdJT05fSU5ERVgwICAgICAgICAgICgweDAgPDwgMCkNCj4+ICNkZWZpbmUgUENJRV9BVFVf
Q1IxICAgICAgICAgICAgICAgICAgICAweDkwNA0KPj4gI2RlZmluZSBQQ0lFX0FUVV9UWVBFX01F
TSAgICAgICAgICAgICAgICgweDAgPDwgMCkNCj4+ICNkZWZpbmUgUENJRV9BVFVfVFlQRV9JTyAg
ICAgICAgICAgICAgICAoMHgyIDw8IDApDQo+PiAjZGVmaW5lIFBDSUVfQVRVX1RZUEVfQ0ZHMCAg
ICAgICAgICAgICAgKDB4NCA8PCAwKQ0KPj4gI2RlZmluZSBQQ0lFX0FUVV9UWVBFX0NGRzEgICAg
ICAgICAgICAgICgweDUgPDwgMCkNCj4+ICNkZWZpbmUgUENJRV9BVFVfQ1IyICAgICAgICAgICAg
ICAgICAgICAweDkwOA0KPj4gI2RlZmluZSBQQ0lFX0FUVV9FTkFCTEUgICAgICAgICAgICAgICAg
ICgweDEgPDwgMzEpDQo+PiAjZGVmaW5lIFBDSUVfQVRVX0JBUl9NT0RFX0VOQUJMRSAgICAgICAg
KDB4MSA8PCAzMCkNCj4+ICNkZWZpbmUgUENJRV9BVFVfTE9XRVJfQkFTRSAgICAgICAgICAgICAw
eDkwQw0KPj4gI2RlZmluZSBQQ0lFX0FUVV9VUFBFUl9CQVNFICAgICAgICAgICAgIDB4OTEwDQo+
PiAjZGVmaW5lIFBDSUVfQVRVX0xJTUlUICAgICAgICAgICAgICAgICAgMHg5MTQNCj4+ICNkZWZp
bmUgUENJRV9BVFVfTE9XRVJfVEFSR0VUICAgICAgICAgICAweDkxOA0KPj4gI2RlZmluZSBQQ0lF
X0FUVV9CVVMoeCkgICAgICAgICAgICAgICAgICgoKHgpICYgMHhmZikgPDwgMjQpDQo+PiAjZGVm
aW5lIFBDSUVfQVRVX0RFVih4KSAgICAgICAgICAgICAgICAgKCgoeCkgJiAweDFmKSA8PCAxOSkN
Cj4+ICNkZWZpbmUgUENJRV9BVFVfRlVOQyh4KSAgICAgICAgICAgICAgICAoKCh4KSAmIDB4Nykg
PDwgMTYpDQo+PiAjZGVmaW5lIFBDSUVfQVRVX1VQUEVSX1RBUkdFVCAgICAgICAgICAgMHg5MUMN
Cj4+DQo+PiAyLiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIGRlc2lnbndhcmUgY29yZSBj
dXJyZW50bHkgc3VwcG9ydCAyDQo+PiBPVVRCT1VORCByZWdpb25zIGFuZCAyIElOQk9VTkQgcmVn
aW9ucy4gSXMgdGhpcyB0cnVlPyBJcyB0aGVyZSBhIHBsYW4gdG8gc3VwcG9ydCBtb3JlDQo+dGhh
biAyPw0KPj4gMy4gSXMgdGhlcmUgYSBkb2N1bWVudGF0aW9uIGV4cGxhaW5pbmcgaG93IHRoZSBB
VFUgaGFuZGxpbmcgY29kZSBpcw0KPj4gZGVzaWduZWQ/IEJhc2ljYWxseSBhcyBJIGNhbid0IGZp
bmQgQVRVIHNwZWNpZmljIHJlZ2lzdGVycyBkZWZpbmVkIGluDQo+PiB0aGUgc3Mgc3BlYywgSSBh
bSBub3QgYWJsZSB0byB1bmRlcnN0YW5kIHRoaXMgY29kZS4gSSBkbyBzZWUgdGhlDQo+PiBhcHBs
aWNhdGlvbiBzcGFjZSBpbiBvdXIgc3Mgc3BlYyBkZWZpbmluZyBPVVRCT1VORCBJTkRFWC9PRkZT
RVQgcmVnaXN0ZXIgdG8gY29uZmlndXJlDQo+T1VUQk9VTkQgcmVnaW9ucyBhbmQgSUIgcmVnaXN0
ZXJzIHRvIGRlZmluZSB0aGUgSU5CT1VORCByZWdpb24uDQo+Pg0KPj4gNC4gV2hhdCBpcyB0aGUg
YmFzZSBhZGRyZXNzIHZhcmlhYmxlIHVzZWQgdG8gYWNjZXNzIFJDJ3MgYXBwbGljYXRpb24NCj4+
IHJlZ2lzdGVyIHNwYWNlPyBkYmlfYmFzZSBpbiBzdHJ1Y3QgcGNpZV9wb3J0ID8gQWxzbyBJIGFt
IGFzc3VtaW5nIHRoaXMNCj4+IGlzIHVzZWQgZm9yIGFjY2Vzc2luZyB0aGlzIHNwYWNlIGZyb20g
aW50ZXJuYWwgQ1BVIGJ1cyBhbmQgY2ZnMF9iYXNlIGFuZCBjZmcxX2Jhc2UgZm9yDQo+YWNjZXNz
aW5nIGl0IGZyb20gcGNpIGJ1cy4gSXMgdGhpcyByaWdodD8NCj4+DQo+PiBJIGFtIHRyeWluZyB0
byBmaWd1cmUgdGhpcyBvdXQgbXlzZWxmLCBidXQgaWYgc29tZW9uZSBjb3VsZCBleHBsYWluIHRo
ZXNlLCB0aGF0IHdpbGwgYmUNCj5ncmVhdCENCj4+DQo+PiBUaGFua3MuDQo+Pg0KPj4gTXVyYWxp
IEthcmljaGVyaQ0KPj4gTGludXggS2VybmVsLCBTb2Z0d2FyZSBEZXZlbG9wbWVudA0KPj4NCj4+
DQo+PiAtLQ0KPj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUg
InVuc3Vic2NyaWJlIGxpbnV4LXBjaSINCj4+IGluIHRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBt
YWpvcmRvbW9Admdlci5rZXJuZWwub3JnIE1vcmUgbWFqb3Jkb21vDQo+PiBpbmZvIGF0ICBodHRw
Oi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0bWwNCg==

RE: pcie designware question

[Mohit KUMAR DCG]

SGVsbG8gTXVyYWxpLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJq
b3JuIEhlbGdhYXMgW21haWx0bzpiaGVsZ2Fhc0Bnb29nbGUuY29tXQ0KPiBTZW50OiBGcmlkYXks
IERlY2VtYmVyIDIwLCAyMDEzIDQ6MjggQU0NCj4gVG86IEthcmljaGVyaSwgTXVyYWxpZGhhcmFu
DQo+IENjOiBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnOyBNb2hpdCBLVU1BUiBEQ0c7IEppbmdv
byBIYW4NCj4gU3ViamVjdDogUmU6IHBjaWUgZGVzaWdud2FyZSBxdWVzdGlvbg0KPiANCj4gWytj
YyBNb2hpdCwgSmluZ29vXQ0KPiANCj4gT24gVGh1LCBEZWMgMTksIDIwMTMgYXQgMzowMSBQTSwg
S2FyaWNoZXJpLCBNdXJhbGlkaGFyYW4gPG0tDQo+IGthcmljaGVyaTJAdGkuY29tPiB3cm90ZToN
Cj4gPiBIaSwNCj4gPg0KPiA+IEkgYW0gd29ya2luZyB0byBwb3J0IG15IHBjaWUgZHJpdmVyIHRv
IHBjaWUtZGVzaWdud2FyZSBjb3JlIGRyaXZlci4NCj4gPiBUaGUgcGNpZSBzdWIgc3lzdGVtICBv
biBvdXIgcGxhdGZvcm0gIGhhcyAzMiBPVVRCT1VORCByZWdpb25zIGFuZCAyDQo+ID4gSU5CT1VO
RCByZWdpb25zLiBJbiBteSBjdXJyZW50IGRyaXZlciwgSSB1c2UgaW50ZXJuYWwgbWVtb3J5IG1h
cCBvZg0KPiA+IENQVSB0byBhY2Nlc3MgdGhlIFJDJ3MgY29uZmlnL2FwcGxpY2F0aW9uIHNwYWNl
IGFzIHdlbGwgRVAncyBjb25maWcNCj4gPiBzcGFjZS4gYSA0SyByYW5nZSBpcyBhdmFpbGFibGUg
dG8gYWNjZXNzIHRoZSBFUCdzIGNvbmZpZyBzcGFjZS4gVG8NCj4gPiBhbGxvdyB3cml0ZS9yZWFk
IHRvIHRoZSBFUCdzIGNvbmZpZyBzcGFjZSwgdGhlIGRyaXZlciBiYXNpY2FsbHkgd3JpdGUgdGhl
IGJ1cywNCj4gZGV2aWNlIGFuZCBmdW5jdGlvbiBudW1iZXIgdG8gdGhlICBhcHBsaWNhdGlvbiBD
RkdfU0VUVVAgcmVnaXN0ZXIgYW5kIHRoZW4NCj4gYWNjZXNzIHRoZSBjb3JyZXNwb25kaW5nIEVQ
J3MgY29uZmlnIHJlZ2lzdGVyLg0KPiA+DQo+ID4gSSBoYXZlIHJldmlld2VkIHRoZSBkZXNpZ253
YXJlLmMgY29kZSBhbmQgdGhlIGdsdWUgbG9naWMgZHJpdmVyDQo+ID4gcGNpLWV4eW5vcy5jIGFu
ZCBjb3VsZG4ndCB1bmRlcnN0YW5kIGZldyB0aGluZ3MuDQo+ID4NCj4gPiAxLiBPdXIgcGNpZSBz
cyBpcyBiYXNlZCBvbiBkZXNpZ253YXJlIGNvcmUgYW5kIGZvbGxvd2luZyBhZGRyZXNzZXMgYXJl
DQo+ID4gbm90IGxpc3RlZCBpbiBvdXIgSVAncyAgZGF0YSBtYW51YWwuIFdoZXJlIGlzIGRlZmlu
ZWQ/IEl0IGRvZXMgc2hvdw0KPiA+IHRoZSByZXN0IG9mIHRoZSBvZmZzZXRzIGRlZmluZWQgaW4g
IGRyaXZlcnMvcGNpL2hvc3QvZGVzaWdud2FyZS5jIGFuZA0KPiA+DQo+ID4gI2RlZmluZSBQQ0lF
X0FUVV9WSUVXUE9SVCAgICAgICAgICAgICAgIDB4OTAwDQo+ID4gI2RlZmluZSBQQ0lFX0FUVV9S
RUdJT05fSU5CT1VORCAgICAgICAgICgweDEgPDwgMzEpDQo+ID4gI2RlZmluZSBQQ0lFX0FUVV9S
RUdJT05fT1VUQk9VTkQgICAgICAgICgweDAgPDwgMzEpDQo+ID4gI2RlZmluZSBQQ0lFX0FUVV9S
RUdJT05fSU5ERVgxICAgICAgICAgICgweDEgPDwgMCkNCj4gPiAjZGVmaW5lIFBDSUVfQVRVX1JF
R0lPTl9JTkRFWDAgICAgICAgICAgKDB4MCA8PCAwKQ0KPiA+ICNkZWZpbmUgUENJRV9BVFVfQ1Ix
ICAgICAgICAgICAgICAgICAgICAweDkwNA0KPiA+ICNkZWZpbmUgUENJRV9BVFVfVFlQRV9NRU0g
ICAgICAgICAgICAgICAoMHgwIDw8IDApDQo+ID4gI2RlZmluZSBQQ0lFX0FUVV9UWVBFX0lPICAg
ICAgICAgICAgICAgICgweDIgPDwgMCkNCj4gPiAjZGVmaW5lIFBDSUVfQVRVX1RZUEVfQ0ZHMCAg
ICAgICAgICAgICAgKDB4NCA8PCAwKQ0KPiA+ICNkZWZpbmUgUENJRV9BVFVfVFlQRV9DRkcxICAg
ICAgICAgICAgICAoMHg1IDw8IDApDQo+ID4gI2RlZmluZSBQQ0lFX0FUVV9DUjIgICAgICAgICAg
ICAgICAgICAgIDB4OTA4DQo+ID4gI2RlZmluZSBQQ0lFX0FUVV9FTkFCTEUgICAgICAgICAgICAg
ICAgICgweDEgPDwgMzEpDQo+ID4gI2RlZmluZSBQQ0lFX0FUVV9CQVJfTU9ERV9FTkFCTEUgICAg
ICAgICgweDEgPDwgMzApDQo+ID4gI2RlZmluZSBQQ0lFX0FUVV9MT1dFUl9CQVNFICAgICAgICAg
ICAgIDB4OTBDDQo+ID4gI2RlZmluZSBQQ0lFX0FUVV9VUFBFUl9CQVNFICAgICAgICAgICAgIDB4
OTEwDQo+ID4gI2RlZmluZSBQQ0lFX0FUVV9MSU1JVCAgICAgICAgICAgICAgICAgIDB4OTE0DQo+
ID4gI2RlZmluZSBQQ0lFX0FUVV9MT1dFUl9UQVJHRVQgICAgICAgICAgIDB4OTE4DQo+ID4gI2Rl
ZmluZSBQQ0lFX0FUVV9CVVMoeCkgICAgICAgICAgICAgICAgICgoKHgpICYgMHhmZikgPDwgMjQp
DQo+ID4gI2RlZmluZSBQQ0lFX0FUVV9ERVYoeCkgICAgICAgICAgICAgICAgICgoKHgpICYgMHgx
ZikgPDwgMTkpDQo+ID4gI2RlZmluZSBQQ0lFX0FUVV9GVU5DKHgpICAgICAgICAgICAgICAgICgo
KHgpICYgMHg3KSA8PCAxNikNCj4gPiAjZGVmaW5lIFBDSUVfQVRVX1VQUEVSX1RBUkdFVCAgICAg
ICAgICAgMHg5MUMNCg0KLSBUaGVzZSBhcmUgU3lub3BzeXMgc3BlY2lmaWMgcG9ydCBsb2dpYyBy
ZWdpc3RlcnMuIFlvdSBjYW4gZmluZCB0aGVzZSByZWdpc3RlcnMgYXQgb2Zmc2V0IDB4MjAwDQog
dW5kZXIgcG9ydCBsb2dpYyByZWdpc3RlcnMgc2VjdGlvbiBpbiBTeW5wc3lzIFBDSWUgRE0uICBU
aGVyZSBjYW4gYmUgbWlub3IgZGlmZmVyZW5jZSBpbiB0aGUgbmFtZQ0KY29udmVudGlvbiBhcyBp
dCBpcyBjYWxsZWQgJ2lBVFUgVmlld3BvcnQgUmVnaXN0ZXInIGluIGNvbnRyb2xsZXIgdmVyc2lv
bjMuNzAgYW5kICdpQVRVIEluZGV4IFJlZ2lzdGVyJw0KIGluIHZlcnNpb24gNC4xMS4NCkJ5IHRo
ZSB3YXkgd2hpY2ggdmVyc2lvbiBvZiBJUCBtYW51YWwgeW91IGFyZSByZWZlcnJpbmc/DQoNCj4g
Pg0KPiA+IDIuIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgZGVzaWdud2FyZSBjb3JlIGN1
cnJlbnRseSBzdXBwb3J0IDINCj4gPiBPVVRCT1VORCByZWdpb25zIGFuZCAyIElOQk9VTkQgcmVn
aW9ucy4gSXMgdGhpcyB0cnVlPyBJcyB0aGVyZSBhIHBsYW4gdG8NCj4gc3VwcG9ydCBtb3JlIHRo
YW4gMj8NCg0KLSB5ZXMgY3VycmVudGx5IHN1cHBvcnRpbmcgb25seSAyIHZpZXdwb3J0cyBhcyB0
aGVyZSBhcmUgc29tZSBjb250cm9sbGVyIGhhdmluZyBvbmx5IHR3by4NCkFzIG9mIG5vdyBubyBw
bGFuIHRvIGVuaGFuY2UgaXQuIEJ1dCBpZiB5b3Ugc2VuZCBhIHBhdGNoIGZvciB0aGlzIG1vZGlm
aWNhdGlvbiwgd2UgY2FuIHJldmlldy4NCg0KPiA+IDMuIElzIHRoZXJlIGEgZG9jdW1lbnRhdGlv
biBleHBsYWluaW5nIGhvdyB0aGUgQVRVIGhhbmRsaW5nIGNvZGUgaXMNCj4gPiBkZXNpZ25lZD8g
QmFzaWNhbGx5IGFzIEkgY2FuJ3QgZmluZCBBVFUgc3BlY2lmaWMgcmVnaXN0ZXJzIGRlZmluZWQg
aW4NCj4gPiB0aGUgc3Mgc3BlYywgSSBhbSBub3QgYWJsZSB0byB1bmRlcnN0YW5kIHRoaXMgY29k
ZS4gSSBkbyBzZWUgdGhlDQo+ID4gYXBwbGljYXRpb24gc3BhY2UgaW4gb3VyIHNzIHNwZWMgZGVm
aW5pbmcgT1VUQk9VTkQgSU5ERVgvT0ZGU0VUDQo+IHJlZ2lzdGVyIHRvIGNvbmZpZ3VyZSBPVVRC
T1VORCByZWdpb25zIGFuZCBJQiByZWdpc3RlcnMgdG8gZGVmaW5lIHRoZQ0KPiBJTkJPVU5EIHJl
Z2lvbi4NCg0KLSBBcyBtZW50aW9uZWQgcGxlYXNlIHJlZmVyIFN5bm9wc3lzIFBDSWUgRE0gYW5k
IGZpbmQgdGhlc2UgcmVnaXN0ZXJzIHVuZGVyIHBvcnQgbG9naWMgc2VjdGlvbg0KIGF0IG9mZnNl
dCAweDIwMC4NCg0KPiA+DQo+ID4gNC4gV2hhdCBpcyB0aGUgYmFzZSBhZGRyZXNzIHZhcmlhYmxl
IHVzZWQgdG8gYWNjZXNzIFJDJ3MgYXBwbGljYXRpb24NCj4gPiByZWdpc3RlciBzcGFjZT8gZGJp
X2Jhc2UgaW4gc3RydWN0IHBjaWVfcG9ydCA/IEFsc28gSSBhbSBhc3N1bWluZyB0aGlzDQo+ID4g
aXMgdXNlZCBmb3IgYWNjZXNzaW5nIHRoaXMgc3BhY2UgZnJvbSBpbnRlcm5hbCBDUFUgYnVzIGFu
ZCBjZmcwX2Jhc2UgYW5kDQo+IGNmZzFfYmFzZSBmb3IgYWNjZXNzaW5nIGl0IGZyb20gcGNpIGJ1
cy4gSXMgdGhpcyByaWdodD8NCg0KLSBEQkkgU3BhY2U6IFRoaXMgc3BhY2UgaXMgdXNlZCB0byBy
ZWFkL3dyaXRlIG93biBQQ0kgQ29uZmlndXJhdGlvbiBIZWFkZXIsDQogQ2FwYWJpbGl0eSBhbmQg
UG9ydCBMb2dpYyAoUEwpIFJlZ2lzdGVycw0KIEVMQkkgc3BhY2U6IFRoZXNlIGFyZSBjb21wbGV0
ZWx5IHBsYXRmb3JtIChTcGVhci9FeHlub3N5cyAuLi4pIHNwZWNpZmljIGFwcGxpY2F0aW9uIHJl
Z2lzdGVycy4NCkNvbmZpZ3VyYXRpb24vSU8vTWVtb3J5IHNwYWNlOiBUaGVzZSBhZGRyZXNzZXMg
Y2FuIGJlIHVzZWQgaW4gdmlld3BvcnQgcHJvZ3JhbW1pbmcgdG8NCiBnZW5lcmF0ZSBkaWZmZXJl
bnQgdHlwZSBvZiBvdXRib3VuZCB0cmFuc2FjdGlvbi4NCg0KUmVnYXJkcw0KTW9oaXQNCg0KPiA+
DQo+ID4gSSBhbSB0cnlpbmcgdG8gZmlndXJlIHRoaXMgb3V0IG15c2VsZiwgYnV0IGlmIHNvbWVv
bmUgY291bGQgZXhwbGFpbiB0aGVzZSwNCj4gdGhhdCB3aWxsIGJlIGdyZWF0IQ0KPiA+DQo+ID4g
VGhhbmtzLg0KPiA+DQo+ID4gTXVyYWxpIEthcmljaGVyaQ0KPiA+IExpbnV4IEtlcm5lbCwgU29m
dHdhcmUgRGV2ZWxvcG1lbnQNCj4gPg0KPiA+DQo+ID4gLS0NCj4gPiBUbyB1bnN1YnNjcmliZSBm
cm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGludXgtcGNpIg0KPiA+
IGluIHRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3JnIE1v
cmUNCj4gbWFqb3Jkb21vDQo+ID4gaW5mbyBhdCAgaHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpv
cmRvbW8taW5mby5odG1sDQo=

Re: pcie designware question

[Murali Karicheri]

On 12/19/2013 11:21 PM, Mohit KUMAR DCG wrote:
> Hello Murali,
>
>> ---> Cut <-----
>>> I have reviewed the designware.c code and the glue logic driver
>>> pci-exynos.c and couldn't understand few things.
>>>
>>> 1. Our pcie ss is based on designware core and following addresses are
>>> not listed in our IP's  data manual. Where is defined? It does show
>>> the rest of the offsets defined in  drivers/pci/host/designware.c and
>>>
>>> #define PCIE_ATU_VIEWPORT               0x900
>>> #define PCIE_ATU_REGION_INBOUND         (0x1 << 31)
>>> #define PCIE_ATU_REGION_OUTBOUND        (0x0 << 31)
>>> #define PCIE_ATU_REGION_INDEX1          (0x1 << 0)
>>> #define PCIE_ATU_REGION_INDEX0          (0x0 << 0)
>>> #define PCIE_ATU_CR1                    0x904
>>> #define PCIE_ATU_TYPE_MEM               (0x0 << 0)
>>> #define PCIE_ATU_TYPE_IO                (0x2 << 0)
>>> #define PCIE_ATU_TYPE_CFG0              (0x4 << 0)
>>> #define PCIE_ATU_TYPE_CFG1              (0x5 << 0)
>>> #define PCIE_ATU_CR2                    0x908
>>> #define PCIE_ATU_ENABLE                 (0x1 << 31)
>>> #define PCIE_ATU_BAR_MODE_ENABLE        (0x1 << 30)
>>> #define PCIE_ATU_LOWER_BASE             0x90C
>>> #define PCIE_ATU_UPPER_BASE             0x910
>>> #define PCIE_ATU_LIMIT                  0x914
>>> #define PCIE_ATU_LOWER_TARGET           0x918
>>> #define PCIE_ATU_BUS(x)                 (((x) & 0xff) << 24)
>>> #define PCIE_ATU_DEV(x)                 (((x) & 0x1f) << 19)
>>> #define PCIE_ATU_FUNC(x)                (((x) & 0x7) << 16)
>>> #define PCIE_ATU_UPPER_TARGET           0x91C
> - These are Synopsys specific port logic registers. You can find these registers at offset 0x200
>   under port logic registers section in Synpsys PCIe DM.  There can be minor difference in the name
> convention as it is called 'iATU Viewport Register' in controller version3.70 and 'iATU Index Register'
>   in version 4.11.
> By the way which version of IP manual you are referring?
Mohit,

Thanks for the reply. I will check with my hardware team. The device 
spec seem to miss this info or this is
not applicable for our PCIE SS.

> -----> Cut <-----
>>> 4. What is the base address variable used to access RC's application
>>> register space? dbi_base in struct pcie_port ? Also I am assuming this
>>> is used for accessing this space from internal CPU bus and cfg0_base and
>> cfg1_base for accessing it from pci bus. Is this right?
> - DBI Space: This space is used to read/write own PCI Configuration Header,
>   Capability and Port Logic (PL) Registers
>   ELBI space: These are completely platform (Spear/Exynosys ...) specific application registers.
> Configuration/IO/Memory space: These addresses can be used in viewport programming to
>   generate different type of outbound transaction.
>
> Regards
> Mohit
Does the core driver use 1 to 1 mapping or  use real address translation?
In the description below by glue driver, I mean the driver for platform
specific wrapper around the designware PCIE core and core driver is the
designware driver.

The PCIE ss in our documentation has application registers at
offset 0x0 of the PCIE cfg memory map of the CPU, 0x1000 is the RC's
config space and 0x2000 is the EP's config space and 0x3000 is the
Downstream IO space. The CPU base address of config space is
0x21800000.The PCIE data space of the DBI is at address 0x50000000
(256M). Each config space is having a size of 4K (0x1000). How do I
setup the DT bindings for this? If there is a mail thread that already
discussed this, please send me a link.

 From your response, I gather dbi_base should be pointing to the RC's
io mapped config space base address (0x21801000). The code in
core driver is assigning cfg0_base to the io mapped address of DT's
configuration space CPU address and cfg1_base to cfg0_base + size/2.

So I need to pass the base of RC's CPU address to CPU address of
the configuration space in DT binding. So EP's CPU address will be mapped
to 0x21802000 assuming a size of 0x2000. Also I need to handle the
application register base internal to my glue driver. Does the following
make sense?


/* Configuration space */
ranges = <0x00000800 0 0x21801000 0x50000000 0 0x0002000
/* downstream I/O */
0x81000000 0 00x50002000 0 0x0010000
/* non-prefetchable memory */
0x82000000 0 0x50012000 0x50012000 0 0xffef000>;

Also For interrupt handling (MSI and Legacy), there is part of the code
to be implemented in the glue driver and part is already in designware
core driver. Is this correct assumption? In our implementation, there
are 4 Host IRQ lines for A,B,C and D interrupt lines and 8 MSI IRQ lines
each multiplexing 4 of the MSI vectors. This code seems to be specific
to the glue driver.

Is there an example DT binding to do this mapping?

Thanks

Murali

Re: pcie designware question

[Murali Karicheri]

On 12/19/2013 11:21 PM, Mohit KUMAR DCG wrote:
>>> I have reviewed the designware.c code and the glue logic driver
>>> pci-exynos.c and couldn't understand few things.
>>>
>>> 1. Our pcie ss is based on designware core and following addresses are
>>> not listed in our IP's  data manual. Where is defined? It does show
>>> the rest of the offsets defined in  drivers/pci/host/designware.c and
>>>
>>> #define PCIE_ATU_VIEWPORT               0x900
>>> #define PCIE_ATU_REGION_INBOUND         (0x1 << 31)
>>> #define PCIE_ATU_REGION_OUTBOUND        (0x0 << 31)
>>> #define PCIE_ATU_REGION_INDEX1          (0x1 << 0)
>>> #define PCIE_ATU_REGION_INDEX0          (0x0 << 0)
>>> #define PCIE_ATU_CR1                    0x904
>>> #define PCIE_ATU_TYPE_MEM               (0x0 << 0)
>>> #define PCIE_ATU_TYPE_IO                (0x2 << 0)
>>> #define PCIE_ATU_TYPE_CFG0              (0x4 << 0)
>>> #define PCIE_ATU_TYPE_CFG1              (0x5 << 0)
>>> #define PCIE_ATU_CR2                    0x908
>>> #define PCIE_ATU_ENABLE                 (0x1 << 31)
>>> #define PCIE_ATU_BAR_MODE_ENABLE        (0x1 << 30)
>>> #define PCIE_ATU_LOWER_BASE             0x90C
>>> #define PCIE_ATU_UPPER_BASE             0x910
>>> #define PCIE_ATU_LIMIT                  0x914
>>> #define PCIE_ATU_LOWER_TARGET           0x918
>>> #define PCIE_ATU_BUS(x)                 (((x) & 0xff) << 24)
>>> #define PCIE_ATU_DEV(x)                 (((x) & 0x1f) << 19)
>>> #define PCIE_ATU_FUNC(x)                (((x) & 0x7) << 16)
>>> #define PCIE_ATU_UPPER_TARGET           0x91C
> - These are Synopsys specific port logic registers. You can find these registers at offset 0x200
>   under port logic registers section in Synpsys PCIe DM.  There can be minor difference in the name
> convention as it is called 'iATU Viewport Register' in controller version3.70 and 'iATU Index Register'
>   in version 4.11.
> By the way which version of IP manual you are referring?
>
>
Mohit,

I have checked with our hardware team and they confirmed that ATU 
registers are not implemented in our PCIE
SS. So we need to have  a way to disable this in the core driver so 
that  we can handle it in our glue layer driver.
But this will be a regression on the existing driver. How do we handle this?

Murali

Re: pcie designware question

[Pratyush Anand]

On Sat, Dec 21, 2013 at 12:20:29AM +0800, Murali Karicheri wrote:
> On 12/19/2013 11:21 PM, Mohit KUMAR DCG wrote:
> >>> I have reviewed the designware.c code and the glue logic driver
> >>> pci-exynos.c and couldn't understand few things.
> >>>
> >>> 1. Our pcie ss is based on designware core and following addresses are
> >>> not listed in our IP's  data manual. Where is defined? It does show
> >>> the rest of the offsets defined in  drivers/pci/host/designware.c and
> >>>
> >>> #define PCIE_ATU_VIEWPORT               0x900
> >>> #define PCIE_ATU_REGION_INBOUND         (0x1 << 31)
> >>> #define PCIE_ATU_REGION_OUTBOUND        (0x0 << 31)
> >>> #define PCIE_ATU_REGION_INDEX1          (0x1 << 0)
> >>> #define PCIE_ATU_REGION_INDEX0          (0x0 << 0)
> >>> #define PCIE_ATU_CR1                    0x904
> >>> #define PCIE_ATU_TYPE_MEM               (0x0 << 0)
> >>> #define PCIE_ATU_TYPE_IO                (0x2 << 0)
> >>> #define PCIE_ATU_TYPE_CFG0              (0x4 << 0)
> >>> #define PCIE_ATU_TYPE_CFG1              (0x5 << 0)
> >>> #define PCIE_ATU_CR2                    0x908
> >>> #define PCIE_ATU_ENABLE                 (0x1 << 31)
> >>> #define PCIE_ATU_BAR_MODE_ENABLE        (0x1 << 30)
> >>> #define PCIE_ATU_LOWER_BASE             0x90C
> >>> #define PCIE_ATU_UPPER_BASE             0x910
> >>> #define PCIE_ATU_LIMIT                  0x914
> >>> #define PCIE_ATU_LOWER_TARGET           0x918
> >>> #define PCIE_ATU_BUS(x)                 (((x) & 0xff) << 24)
> >>> #define PCIE_ATU_DEV(x)                 (((x) & 0x1f) << 19)
> >>> #define PCIE_ATU_FUNC(x)                (((x) & 0x7) << 16)
> >>> #define PCIE_ATU_UPPER_TARGET           0x91C
> > - These are Synopsys specific port logic registers. You can find these registers at offset 0x200
> >   under port logic registers section in Synpsys PCIe DM.  There can be minor difference in the name
> > convention as it is called 'iATU Viewport Register' in controller version3.70 and 'iATU Index Register'
> >   in version 4.11.
> > By the way which version of IP manual you are referring?
> >
> >
> Mohit,
> 
> I have checked with our hardware team and they confirmed that ATU 
> registers are not implemented in our PCIE

Which PCIe designware IP version you are using? At least since version 3.71
support of viewport is available in IP. Older version was handling
address translation using side band signals implemented through
vendor specific application registers. May be your case is also
similar.

> SS. So we need to have  a way to disable this in the core driver so 
> that  we can handle it in our glue layer driver.
> But this will be a regression on the existing driver. How do we handle this?

May be you can add rd/wr_other_conf in struct pcie_host_ops. 
Change designware driver to handle vendor specific rd/wr_other_conf,
if it exists, else use generic rd/wr_other_conf.

In your vendor specific rd/wr_other_conf handler you can implement
translation using your application registers.

Regards
Pratyush
> 
> Murali
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: pcie designware question

[Karicheri, Muralidharan]

>> Mohit,
>>
>> I have checked with our hardware team and they confirmed that ATU
>> registers are not implemented in our PCIE
>
>Which PCIe designware IP version you are using? At least since version 3.71 support of
>viewport is available in IP. Older version was handling address translation using side band
>signals implemented through vendor specific application registers. May be your case is also
>similar.
>
Pratyush,

Thanks for responding.

Is there a register that I can poke to know the IP version. I have asked this to our
hardware folks to know the version. I guess it is older than 3.71.

>> SS. So we need to have  a way to disable this in the core driver so
>> that  we can handle it in our glue layer driver.
>> But this will be a regression on the existing driver. How do we handle this?
>
>May be you can add rd/wr_other_conf in struct pcie_host_ops.
>Change designware driver to handle vendor specific rd/wr_other_conf, if it exists, else use
>generic rd/wr_other_conf.
>
Yes, that is indeed what I did to solve this. I will be sending a patch for this once
my driver is tested.

Murali
>In your vendor specific rd/wr_other_conf handler you can implement translation using your
>application registers.
>
>Regards
>Pratyush
>>
>> Murali
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci"
>> in the body of a message to majordomo@vger.kernel.org More majordomo
>> info at  http://vger.kernel.org/majordomo-info.html