RE: pcie designware question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Murali,

> -----Original Message-----
> From: Bjorn Helgaas [mailto:bhelgaas@xxxxxxxxxx]
> Sent: Friday, December 20, 2013 4:28 AM
> To: Karicheri, Muralidharan
> Cc: linux-pci@xxxxxxxxxxxxxxx; Mohit KUMAR DCG; Jingoo Han
> Subject: Re: pcie designware question
> 
> [+cc Mohit, Jingoo]
> 
> 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

- 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?

> >
> > 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?

- yes currently supporting only 2 viewports as there are some controller having only two.
As of now no plan to enhance it. But if you send a patch for this modification, we can review.

> > 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.

- As mentioned please refer Synopsys PCIe DM and find these registers under port logic section
 at offset 0x200.

> >
> > 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

> >
> > 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�����٥





[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux