linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3.11-rc] pci: mvebu: disable prefetchable memory support in PCI-to-PCI bridge
Date: Thu, 1 Aug 2013 19:59:48 +0200	[thread overview]
Message-ID: <20130801195948.7ecb4ac8@skate> (raw)
In-Reply-To: <CAErSpo7Y+OE8_NT3npC1DCQz3PrOT9Nz=6MavY+zS63pGN3x9g@mail.gmail.com>

Dear Bjorn Helgaas,

On Thu, 1 Aug 2013 10:53:07 -0600, Bjorn Helgaas wrote:
> On Thu, Aug 1, 2013 at 7:44 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > The Marvell PCIe driver uses an emulated PCI-to-PCI bridge to be able
> > to dynamically set up MBus address decoding windows for PCI I/O and
> > memory regions depending on the PCI devices enumerated by Linux.
> >
> > However, this emulated PCI-to-PCI bridge logic makes the Linux PCI
> > core believe that prefetchable memory regions are supported (because
> > the registers are read/write), while in fact no adress decoding window
> > is ever created for such regions. Since the Marvell MBus address
> > decoding windows do not distinguish memory regions and prefetchable
> > memory regions, this patch takes a simple approach: change the
> > PCI-to-PCI bridge emulation to let the Linux PCI core know that we
> > don't support prefetchable memory regions.
> >
> > To achieve this, we simply make the prefetchable memory base a
> > read-only register that always returns 0. Reading/writing all the
> > other prefetchable memory related registers has no effect.
> >
> > This problem was originally reported by Finn Hoffmann
> > <finn@uni-bremen.de>, who couldn't get a RTL8111/8168B PCI NIC working
> > on the NSA310 Kirkwood platform after updating to 3.11-rc. The problem
> > was that the PCI-to-PCI bridge emulation was making the Linux PCI core
> > believe that we support prefetchable memory, so the Linux PCI core was
> > only filling the prefetchable memory base and limit registers, which
> > does not lead to a MBus window being created. The below patch has been
> > confirmed by Finn Hoffmann to fix his problem on Kirkwood, and has
> > otherwise been successfully tested on the Armada XP GP platform with a
> > e1000e PCIe NIC and a Marvell SATA PCIe card.
> >
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > Reported-by: Finn Hoffmann <finn@uni-bremen.de>
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> 
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> 
> Please merge along with your other pci-mvebu.c changes.

I don't think we have other pci-mvebu.c lined up for 3.11. All the MSI
stuff, mvebu-mbus DT stuff and so on is for 3.12.

So I guess you could take that one through your pci tree. Jason, can
you confirm?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2013-08-01 17:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-01 13:44 [PATCH 3.11-rc] pci: mvebu: disable prefetchable memory support in PCI-to-PCI bridge Thomas Petazzoni
2013-08-01 16:53 ` Bjorn Helgaas
2013-08-01 17:59   ` Thomas Petazzoni [this message]
2013-08-01 20:51     ` Bjorn Helgaas
2013-08-02 17:43 ` Jason Gunthorpe
2013-08-06 10:36   ` Thomas Petazzoni

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=20130801195948.7ecb4ac8@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).