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 10:16:32 +0100 [thread overview]
Message-ID: <53071970.1040400@keymile.com> (raw)
In-Reply-To: <20140221101218.45766e8a@skate>
Hi Thomas,
On 02/21/2014 10:12 AM, Thomas Petazzoni wrote:
> Dear Gerlando Falauto,
>
> On Fri, 21 Feb 2014 09:58:21 +0100, Gerlando Falauto wrote:
>
>>> 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).
>
> Would indeed be interesting to know who does this rounding, and why,
> and according to what rules.
>
>> 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?
>
> Sure, but whichever choice we make, the Linux PCI core must know by how
> much we've enlarge the bridge window BAR, otherwise the Linux PCI core
> may allocate for the next bridge window BAR a range of addresses that
> doesn't overlap with what it has allocate for the previous bridge
> window BAR, but that ends up overlapping due to us "extending" the
> previous bridge window BAR to match the MBus requirements.
>
> Gerlando, would you be able to test a quick hack that creates 2 windows
> to cover exactly 128 MB + 64 MB ? This would at least allow us to
> confirm that the strategy of splitting in multiple windows is usable.
Sure, though probably not until next week.
I guess it would then also be useful to restore my previous setup, where
the total PCIe aperture is 192MB, right?
Thank you guys!
Gerlando
next prev parent reply other threads:[~2014-02-21 9:16 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
2014-02-21 9:12 ` Thomas Petazzoni
2014-02-21 9:16 ` Gerlando Falauto [this message]
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=53071970.1040400@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