[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140220174503.GB19893@obsidianresearch.com>
Date: Thu, 20 Feb 2014 10:45:03 -0700
From: Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To: Srikanth Thokala <sthokal@...inx.com>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>, Arnd Bergmann <arnd@...db.de>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
Michal Simek <michal.simek@...inx.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Rob Herring <robh+dt@...nel.org>,
Grant Likely <grant.likely@...aro.org>,
linux-arm <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] pcie: Add Xilinx PCIe Host Bridge IP driver
On Thu, Feb 20, 2014 at 12:39:48PM +0530, Srikanth Thokala wrote:
> > These should use the standard ranges mechanism for translations and
> > apertures.
>
> This AXI PCIe bridge IP do have two kind of BARs AXI-to-PCIe BAR and
> PCIe-to-AXI BAR. The former specifies the AXI Base address and are the
> memory windows, these are listed in the 'ranges' DT property. The latter
> BAR specifies the addresses that PCI Express should respond to/is
The PCIe-to-AXI window should be setup by the driver automatically to
span all system memory, it doesn't need to be in DT.
The AXI-to-PCIe is the host bridge aperture and it should be in the DT
ranges.
> tallowed to write to and these addresses written to configuration space
> during the initialization.
Hopefully this was done in a conformant way, please provide a lspci
-vv next round please..
> > Also, IMHO, only root ports should be supported in a host bridge
> > driver. A PCI end point is something entirely different.
>
> We are not supporting end point in this driver. This is a soft IP
> and can be configurable as a Root Port/End point while creating a HW
> design in the FPGA. So, the driver use this DT property to first
> check if it is configured for Root Port and bail out if it is not.
This is something that should be handled via the compatible string, not
special properties. Root port and End port will have different
drivers, so they must have different compatible strings.
There is nothing wrong with dumping core generator configuration
properties into the DT (as a form of documentation), but you must
still use the standard techniques and properties whenever possible.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists