From: gerlando.falauto@keymile•com (Gerlando Falauto)
To: linux-arm-kernel@lists•infradead.org
Subject: pci-mvebu driver on km_kirkwood
Date: Fri, 21 Feb 2014 09:58:21 +0100 [thread overview]
Message-ID: <5307152D.3020804@keymile.com> (raw)
In-Reply-To: <20140221093444.35870a73@skate>
Hi guys,
first of all thank you for your support and the explanations.
I'm slowly starting to understand something more about this kind of stuff.
On 02/21/2014 09:34 AM, Thomas Petazzoni wrote:
> Dear Jason Gunthorpe,
>
> On Thu, 20 Feb 2014 17:32:27 -0700, Jason Gunthorpe wrote:
>
>>> 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.
>>
>> That is a smart, easy solution! Maybe that is the least invasive way
>> to proceed for now?
>
> So you suggest that the mvebu-mbus driver should accept a
> non power-of-two window size, and do internally the job of cutting that
> into several power-of-two sized areas and creating the corresponding
> windows?
>
>> I have no idea how you decide when to round up and when to allocate
>> more windows, that feels like a fairly complex optimization problem!
>
> Yes, it is a fairly complex problem. I was thinking of a threshold of
> "lost space". Below this threshold, it's better to enlarge the window,
> above the threshold it's better to create two windows. But not easy.
>
>> Alternatively, I suspect you can use the PCI quirk mechanism to alter
>> the resource sizing on a bridge?
>
> Can you give more details about this mechanism, and how it could be
> used to alter the size of resources on a bridge?
I'm not sure I understand all the details... but I guess some sort of
rounding mechanism is indeed already in place somewhere:
pci 0000:00:01.0: BAR 8: assigned [mem 0xe0000000-0xebffffff]
pci 0000:01:00.0: BAR 1: assigned [mem 0xe0000000-0xe7ffffff]
pci 0000:01:00.0: BAR 3: assigned [mem 0xe8000000-0xe87fffff]
pci 0000:01:00.0: BAR 4: assigned [mem 0xe8800000-0xe8801fff]
pci 0000:01:00.0: BAR 0: assigned [mem 0xe8802000-0xe8802fff]
pci 0000:01:00.0: BAR 2: assigned [mem 0xe8803000-0xe8803fff]
pci 0000:01:00.0: BAR 5: assigned [mem 0xe8804000-0xe8804fff]
pci 0000:00:01.0: PCI bridge to [bus 01]
If you look at the numbers, the total size required by BAR0-5 is
0x8805000, so around 136MB, that is 128MB+8MB+2K+1K+1K.
This gets rounded up (on this 'virtual' BAR 8) to 192MB (I don't know
where or why), which is 1.5x a power of two (i.e. two consecutive bits
followed by all zeroes).
If that's not just a coincidence, finding a coverage subset becomes a
trivial matter (128MB+64MB).
In any case, even if we have an odd number like the above (0x8805000), I
believe we could easily find a suboptimal coverage by just taking the
most significant one and the second most significant one (possibly left
shifted by 1 if there's a third one somewhere else).
In the above case, that would be 0x8000000 + 0x1000000. That's
128MB+16MB, which is even smaller than the rounding above (192MB).
What do you think?
Thanks again!
Gerlando
next prev parent reply other threads:[~2014-02-21 8:58 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-10 16:15 pci-mvebu driver on km_kirkwood Gerlando Falauto
2013-07-10 16:57 ` Thomas Petazzoni
2013-07-10 17:31 ` Gerlando Falauto
2013-07-10 19:56 ` Gerlando Falauto
2013-07-11 7:03 ` Valentin Longchamp
2013-07-12 8:59 ` Thomas Petazzoni
2013-07-15 15:46 ` Valentin Longchamp
2013-07-15 19:51 ` Thomas Petazzoni
2013-07-11 14:32 ` Thomas Petazzoni
2014-02-18 17:29 ` Gerlando Falauto
2014-02-18 20:27 ` Thomas Petazzoni
2014-02-19 8:38 ` Gerlando Falauto
2014-02-19 9:26 ` Thomas Petazzoni
2014-02-19 9:39 ` Gerlando Falauto
2014-02-19 13:37 ` 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
2014-02-21 0:32 ` Jason Gunthorpe
2014-02-21 8:34 ` Thomas Petazzoni
2014-02-21 8:58 ` Gerlando Falauto [this message]
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
2014-02-23 3:43 ` Gavin Shan
2013-07-31 8:03 ` Thomas Petazzoni
2013-07-31 8:26 ` Gerlando Falauto
2013-07-31 9:00 ` Thomas Petazzoni
2013-07-31 20:50 ` Jason Gunthorpe
2013-08-09 14:01 ` Thierry Reding
2013-08-26 9:27 ` Gerlando Falauto
2013-08-26 12:02 ` Thierry Reding
2013-08-26 14:49 ` Gerlando Falauto
2013-08-26 19:16 ` Jason Gunthorpe
2013-11-04 14:49 ` Gerlando Falauto
2013-11-05 8:13 ` Thierry Reding
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=5307152D.3020804@keymile.com \
--to=gerlando.falauto@keymile$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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