From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Gerlando Falauto <gerlando.falauto@keymile.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Andrew Lunn <andrew@lunn.ch>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Jason Cooper <jason@lakedaemon.net>,
"Longchamp, Valentin" <Valentin.Longchamp@keymile.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
Lior Amsalem <alior@marvell.com>
Subject: Re: pci-mvebu driver on km_kirkwood
Date: Thu, 20 Feb 2014 21:29:14 +0100 [thread overview]
Message-ID: <20140220212914.29ddc031@skate> (raw)
In-Reply-To: <20140220173518.GA19893@obsidianresearch.com>
Dear Jason Gunthorpe,
On Thu, 20 Feb 2014 10:35:18 -0700, Jason Gunthorpe wrote:
> On Thu, Feb 20, 2014 at 09:55:18AM +0100, Thomas Petazzoni wrote:
>
> > Does that make sense? Keep in mind that I'm still not completely
> > familiar with the PCI terminology, so maybe the above explanation does
> > not use the right terms.
>
> Stated another way, the Marvel PCI-E to PCI-E bridge config space has
> a quirk that requires the window BARs to be aligned on their size and
> sized to a power of 2.
Correct.
> The first requirement is already being handled by hooking through
> ARM's 'align_resource' callback.
Absolutely.
> One avenue would be to have mvebu_pcie_align_resource return a struct
> resource and manipulate the size as well. Assuming the PCI core will
> accommodate that.
That would effectively be the easiest solution from the point of view
of the PCIe driver.
In practice, the story is a little bit more subtle than that: the PCIe
driver may want to decide to either tell the PCI core to enlarge the
window BAR up to the next power of two size, or to dedicate two windows
to it.
For example:
* If the PCI core allocates a 96 KB BAR, we clearly want it to be
enlarged to 128 KB, so that we have to create a single window for it.
* However, if the PCI core allocates a 192 MB BAR, we may want to
instead create two windows: a first one of 128 MB and a second one
of 64 MB. This consumes two windows, but saves 64 MB of physical
address space.
(Note that I haven't tested myself the creation of two windows for the
same target device, but I was told by Lior that it should work).
As you can see from the two examples above, we may not necessarily want
to enforce this power-of-two constraint in all cases. We may want to
accept a non-power-of-2 size in the case of the 192 MB BAR, and let the
mvebu-mbus driver figure out that it should allocate several
consecutive windows to cover these 192 MB.
But to begin with, rounding up all window BARs up to the next power of
two size would be perfectly OK.
Jason, would you mind maybe replying to Bjorn Helgaas email (Thu, 20
Feb 2014 12:18:42 -0700) ? I believe that a lot of the misunderstanding
between Bjorn and me is due to the fact that I don't use the correct
PCI terminology to describe how the Marvell hardware works, and how the
Marvell PCIe driver copes with it. I'm sure you would explain it in a
way that would be more easily understood by someone very familiar with
the PCI terminology such as Bjorn. Thanks a lot!
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2014-02-20 20:29 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <51DD88A4.1030506@keymile.com>
[not found] ` <20130710185706.72b124a4@skate>
[not found] ` <51DD9A8C.10608@keymile.com>
[not found] ` <20130711163220.2b3adf38@skate>
[not found] ` <53039894.10905@keymile.com>
[not found] ` <20140218212751.07c2aeb5@skate>
[not found] ` <53046D98.6020801@keymile.com>
[not found] ` <20140219102658.76eec91e@skate>
[not found] ` <53047BBB.6040108@keymile.com>
2014-02-19 13:37 ` pci-mvebu driver on km_kirkwood Thomas Petazzoni
2014-02-19 21:45 ` Bjorn Helgaas
2014-02-20 8:55 ` Thomas Petazzoni
2014-02-20 17:35 ` Jason Gunthorpe
2014-02-20 20:29 ` Thomas Petazzoni [this message]
2014-02-21 0:32 ` Jason Gunthorpe
2014-02-21 8:34 ` Thomas Petazzoni
2014-02-21 8:58 ` Gerlando Falauto
2014-02-21 9:12 ` Thomas Petazzoni
2014-02-21 9:16 ` Gerlando Falauto
2014-02-21 9:39 ` Thomas Petazzoni
2014-02-21 12:24 ` Gerlando Falauto
2014-02-21 13:47 ` Thomas Petazzoni
2014-02-21 15:05 ` Arnd Bergmann
2014-02-21 15:11 ` Thomas Petazzoni
2014-02-21 15:20 ` Arnd Bergmann
2014-02-21 15:37 ` Thomas Petazzoni
2014-02-21 16:39 ` Jason Gunthorpe
2014-02-21 17:05 ` Thomas Petazzoni
2014-02-21 17:31 ` Jason Gunthorpe
2014-02-21 18:05 ` Arnd Bergmann
2014-02-21 18:29 ` Gerlando Falauto
2014-02-21 18:18 ` Gerlando Falauto
2014-02-21 18:45 ` Thomas Petazzoni
2014-02-20 19:18 ` Bjorn Helgaas
2014-02-21 0:24 ` Jason Gunthorpe
2014-02-21 19:05 ` Bjorn Helgaas
2014-02-21 19:21 ` Thomas Petazzoni
2014-02-21 19:53 ` Benjamin Herrenschmidt
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=20140220212914.29ddc031@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=Valentin.Longchamp@keymile.com \
--cc=alior@marvell.com \
--cc=andrew@lunn.ch \
--cc=bhelgaas@google.com \
--cc=ezequiel.garcia@free-electrons.com \
--cc=gerlando.falauto@keymile.com \
--cc=jason@lakedaemon.net \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=sebastian.hesselbarth@gmail.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).