From: Arnd Bergmann <arnd@arndb.de>
To: monstr@monstr.eu
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Michal Simek <michal.simek@xilinx.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-arm <linux-arm-kernel@lists.infradead.org>,
Olof Johansson <olof@lixom.net>,
linux-arch@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
Grant Likely <grant.likely@secretlab.ca>,
John Linn <John.Linn@xilinx.com>,
John Williams <jwilliams@xilinx.com>,
linux-pci@vger.kernel.org
Subject: Re: Sharing PCIE driver between Microblaze and Arm zynq
Date: Fri, 7 Dec 2012 19:07:38 +0000 [thread overview]
Message-ID: <201212071907.38366.arnd@arndb.de> (raw)
In-Reply-To: <50C1BA9D.5010406@monstr.eu>
On Friday 07 December 2012, Michal Simek wrote:
> On 12/06/2012 10:27 PM, Bjorn Helgaas wrote:
> > [+cc linux-pci]
> >
> > On Thu, Dec 6, 2012 at 7:23 AM, Michal Simek <michal.simek@xilinx.com> wrote:
> >> Hi guys,
> >>
> >> I have a question regarding to sharing generic OF pcie driver between
> >> two architectures MB and ARM Zynq.
> >> Is drivers/pci/pcie location good for it?
> >> Make no sense to have the same driver in two locations.
> >
> > I think you're talking about a PCI host bridge driver. It would
> > definitely be nice to move toward a generic, shared driver. Host
> > bridge drivers are responsible for enumerating the PCI hierarchy below
> > the bridge. Enumeration is not really PCIe-specific, so I wouldn't
> > put it in drivers/pci/pcie.
>
> Not a PCI expert, just trying to find out the proper location for this shared driver.
I'd suggest creating a drivers/pci/host directory. We will have more of
these in the future. AFAIK, there is no fully generic (architecture
independent) way to interface a PCI host driver to the PCI subsystem,
but I think we are getting closer to that. You are probably fairly
free to modify the microblaze architecture specific code though if needed.
> >> Is using readl/writel IO functions in this driver the best option
> >> which we can have?
> >> Or is there any other recommendation?
> >
> > I'm not really a driver person, but if you're writing a new driver,
> > wouldn't you use the iomap interfaces (ioremap(), ioread32(), etc)
> > rather than readl()?
>
> That driver exists but it is not in mainline and it is better to directly
> add it to proper location with correct io functions.
> The question is if ioread/iowrite functions are correct one.
> PowerPC io-defs.h suggests that readl/writel should be used for PCI.
ioread32/iowrite32 are defined to behave the same way readl/writel regarding
addressing modes and barriers, but also allow operating on __iomem pointers
that were returned from ioport_map(). You probably don't need that.
Some architectures like powerpc have their own accessors for on-chip MMIO
areas, but ARM does not. The PowerPC rule is that you must use either
readl/writel or ioread32/iowrite32 to access devices connected to a PCI
bus, but you would not necessarily do that for the PCI host controller
itself on PowerPC.
Arnd
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: Sharing PCIE driver between Microblaze and Arm zynq
Date: Fri, 7 Dec 2012 19:07:38 +0000 [thread overview]
Message-ID: <201212071907.38366.arnd@arndb.de> (raw)
In-Reply-To: <50C1BA9D.5010406@monstr.eu>
On Friday 07 December 2012, Michal Simek wrote:
> On 12/06/2012 10:27 PM, Bjorn Helgaas wrote:
> > [+cc linux-pci]
> >
> > On Thu, Dec 6, 2012 at 7:23 AM, Michal Simek <michal.simek@xilinx.com> wrote:
> >> Hi guys,
> >>
> >> I have a question regarding to sharing generic OF pcie driver between
> >> two architectures MB and ARM Zynq.
> >> Is drivers/pci/pcie location good for it?
> >> Make no sense to have the same driver in two locations.
> >
> > I think you're talking about a PCI host bridge driver. It would
> > definitely be nice to move toward a generic, shared driver. Host
> > bridge drivers are responsible for enumerating the PCI hierarchy below
> > the bridge. Enumeration is not really PCIe-specific, so I wouldn't
> > put it in drivers/pci/pcie.
>
> Not a PCI expert, just trying to find out the proper location for this shared driver.
I'd suggest creating a drivers/pci/host directory. We will have more of
these in the future. AFAIK, there is no fully generic (architecture
independent) way to interface a PCI host driver to the PCI subsystem,
but I think we are getting closer to that. You are probably fairly
free to modify the microblaze architecture specific code though if needed.
> >> Is using readl/writel IO functions in this driver the best option
> >> which we can have?
> >> Or is there any other recommendation?
> >
> > I'm not really a driver person, but if you're writing a new driver,
> > wouldn't you use the iomap interfaces (ioremap(), ioread32(), etc)
> > rather than readl()?
>
> That driver exists but it is not in mainline and it is better to directly
> add it to proper location with correct io functions.
> The question is if ioread/iowrite functions are correct one.
> PowerPC io-defs.h suggests that readl/writel should be used for PCI.
ioread32/iowrite32 are defined to behave the same way readl/writel regarding
addressing modes and barriers, but also allow operating on __iomem pointers
that were returned from ioport_map(). You probably don't need that.
Some architectures like powerpc have their own accessors for on-chip MMIO
areas, but ARM does not. The PowerPC rule is that you must use either
readl/writel or ioread32/iowrite32 to access devices connected to a PCI
bus, but you would not necessarily do that for the PCI host controller
itself on PowerPC.
Arnd
Arnd
next prev parent reply other threads:[~2012-12-07 19:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-06 14:23 Sharing PCIE driver between Microblaze and Arm zynq Michal Simek
2012-12-06 14:23 ` Michal Simek
2012-12-06 21:27 ` Bjorn Helgaas
2012-12-06 21:27 ` Bjorn Helgaas
2012-12-07 9:45 ` Michal Simek
2012-12-07 9:45 ` Michal Simek
2012-12-07 14:11 ` Grant Likely
2012-12-07 14:11 ` Grant Likely
2012-12-10 7:34 ` Michal Simek
2012-12-10 7:34 ` Michal Simek
2012-12-07 19:07 ` Arnd Bergmann [this message]
2012-12-07 19:07 ` Arnd Bergmann
2012-12-10 7:36 ` Michal Simek
2012-12-10 7:36 ` Michal Simek
2012-12-07 13:17 ` Grant Likely
2012-12-07 13:17 ` Grant Likely
2012-12-07 18:52 ` Michal Simek
2012-12-07 18:52 ` Michal Simek
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=201212071907.38366.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=John.Linn@xilinx.com \
--cc=bhelgaas@google.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=jwilliams@xilinx.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=michal.simek@xilinx.com \
--cc=monstr@monstr.eu \
--cc=olof@lixom.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.