linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Gregory CLEMENT <gregory.clement@free-electrons.com>,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] PCI: mvebu: Take control of mbus windows setup by the firmware
Date: Thu, 10 Nov 2016 09:45:48 -0700	[thread overview]
Message-ID: <20161110164548.GC22004@obsidianresearch.com> (raw)
In-Reply-To: <20161110093037.376ae79d@free-electrons.com>

On Thu, Nov 10, 2016 at 09:30:37AM +0100, Thomas Petazzoni wrote:
> Hello,
> 
> On Wed, 26 Oct 2016 11:44:40 -0600, Jason Gunthorpe wrote:
> > The firmware may setup the mbus to access PCI-E and indicate this
> > has happened with a ranges mapping for the PCI-E ID. If this happens
> > then the mbus setup and the pci dynamic setup conflict, creating
> > problems.
> > 
> > Have PCI-E assume control of the firmware specified default mapping by
> > setting the value of the bridge window to match the firmware mapping.
> > 
> > Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> 
> Sorry for the late feedback. I am not sure to fully understand what you
> are trying to do here.

> However, one thing that confuses me specifically is how can the kernel
> get any MBus mapping set up by the firmware? Indeed, when the
> mvebu-mbus driver initializes, it destroys all existing MBus windows
> that might have been left by the firmware/bootloader:

Sort of, yes, it wipes out the hardware, but then it parses the DT
and puts back the ranges via mbus_dt_setup.

The issue is what happens if mbus_dt_setup adds a mapping for PCI
aperature from the firmware's DT - in this case the PCI driver does not
know that the mbus driver created the mapping and becomes unable to
manipulate the mbus windows due to the conflict detection logic.

The solution is to have the PCI driver read the current state of the
mbus window - out of the mbus registers that were programmed from the
DT ranges by mbus_dt_setup. Then it knows to delete the DT described
window before setting a new window and the conflicts are avoided.

> Why does Linux needs to rely on what the firmware has setup in terms of
> MBus windows? Why can't Linux just find out the right BAR base/size
> like it is doing for all other devices?

Unfortunately that is sort of how DT is expected to work, in my case I
have DT sub nodes off the PCI device in DT and I need DT address
translation to work for those nodes.

In DT land the PCI stuff expects the firmware to provide a complete
address map, and my firmware does, but in doing so I hit this bug :)

Jason

      reply	other threads:[~2016-11-10 16:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-26 17:44 [PATCH] PCI: mvebu: Take control of mbus windows setup by the firmware Jason Gunthorpe
2016-11-09 23:01 ` Jason Gunthorpe
2016-11-10  8:30 ` Thomas Petazzoni
2016-11-10 16:45   ` Jason Gunthorpe [this message]

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=20161110164548.GC22004@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --cc=bhelgaas@google.com \
    --cc=gregory.clement@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=thomas.petazzoni@free-electrons.com \
    /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).