>-----Original Message----- >From: Bjorn Helgaas [mailto:bhelgaas@xxxxxxxxxx] >Sent: Thursday, December 19, 2013 5:58 PM >To: Karicheri, Muralidharan >Cc: linux-pci@xxxxxxxxxxxxxxx; Mohit Kumar; Jingoo Han >Subject: Re: pcie designware question > >[+cc Mohit, Jingoo] > Bjorn, Thanks for forwarding this to experts. Murali >On Thu, Dec 19, 2013 at 3:01 PM, Karicheri, Muralidharan <m-karicheri2@xxxxxx> 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@xxxxxxxxxxxxxxx More majordomo >> info at http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n�����{���"�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
