public inbox for linux-next@vger.kernel.org 
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation•org>
To: Yinghai Lu <yhlu.kernel@gmail•com>
Cc: Andrew Morton <akpm@linux-foundation•org>,
	Stephen Rothwell <sfr@canb•auug.org.au>,
	linux-next@vger•kernel.org, LKML <linux-kernel@vger•kernel.org>
Subject: Re: linux-next: Tree for September 3
Date: Thu, 4 Sep 2008 01:23:09 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0809040102260.3378@nehalem.linux-foundation.org> (raw)
In-Reply-To: <86802c440809040014w5a6d2921k8c99b3978772e1fb@mail.gmail.com>



On Thu, 4 Sep 2008, Yinghai Lu wrote:
> >
> > --- x   2008-09-03 21:38:24.000000000 -0700
> > +++ y   2008-09-03 22:29:04.000000000 -0700
> > ...
> > @@ -503,15 +503,15 @@
> >  calling  init_acpi_pm_clocksource+0x0/0x14a
> >  initcall init_acpi_pm_clocksource+0x0/0x14a returned 0 after 32 msecs
> >  calling  pcibios_assign_resources+0x0/0x70
> > -pci 0000:06:05.0: BAR 9 too large: 0x00000000000000-0x00000003ffffff
> >  pci 0000:06:05.0: CardBus bridge, secondary bus 0000:07
> >  pci 0000:06:05.0:   IO window: 0x002400-0x0024ff
> >  pci 0000:06:05.0:   IO window: 0x002800-0x0028ff
> > -pci 0000:06:05.0:   MEM window: 0x54000000-0x57ffffff
> > +pci 0000:06:05.0:   PREFETCH window: 0x50000000-0x53ffffff
> > +pci 0000:06:05.0:   MEM window: 0x58000000-0x5bffffff
> >  pci 0000:00:1e.0: PCI bridge, secondary bus 0000:06
> >  pci 0000:00:1e.0:   IO window: 0x2000-0x2fff
> >  pci 0000:00:1e.0:   MEM window: 0xb0100000-0xb01fffff
> > -pci 0000:00:1e.0:   PREFETCH window: disabled
> > +pci 0000:00:1e.0:   PREFETCH window: 0x00000050000000-0x00000053ffffff
> >  pci 0000:00:1e.0: setting latency timer to 64
> >  pci 0000:06:05.0: power state changed by ACPI to D0
> 
> 06:05.0 is under 00:1e.0

Right. This is the depth-first bus assignment, so what happens is that 
pci_assign_unassigned_resources() does:

        /* Depth first, calculate sizes and alignments of all
           subordinate buses. */
        list_for_each_entry(bus, &pci_root_buses, node) {
                pci_bus_size_bridges(bus);
        }

where pci_bus_size_bridges() does depth-first (and _has_ to, of course, 
since it needs to look at the inner bridges in order to be able to size 
the outer ones!)

And there it will now successfully see that BAR 9 that used to get 
ignored, so now it sizes the PCI bridge that leads _to_ the Cardbus bridge 
with that in mind. So that is why the "BAR 9 too large" message has gone 
away, but that is all that got printed out at the resource _sizing_ stage.

And then, after all the sizing has been done, the odd ordering of the 
printout is because we next do:

        /* Depth last, allocate resources and update the hardware. */
        list_for_each_entry(bus, &pci_root_buses, node) {
                pci_bus_assign_resources(bus); 
                pci_enable_bridges(bus);
        }

and that "Depth last" comment is a bit mis-leading.

It is true that "pci_bus_assign_resources()" will make the actual call to 
"pbus_assign_resources_sorted()" depth-last, but if you look at how it 
then actually writes those assigned resources to the actual bridge 
devices, it will do those "pci_setup_bridge/cardbus()" calls depth-first: 
if you look at pci_bus_assign_resources(), you'll see that it does the 
recursive call for the subordinate bus _before_ it sets up the upper 
bridge.

And since the _printout_ comes when the final setup is done, that means 
that the Cardbus bridge (that is deeper in the resource chain) will print 
out first. So even though the resource was _allocated_ depth-last, it is 
written out depth-first!

> wonder if some pci code change cause that.... doesn't get pref mem assigned.
> 
> can you apply attached patches to get more dump?

It all works fine, and makes sense (well, except for the printout order, 
which is a bit non-obvious, but it all boils down to us wanting to have 
all the inner bridges set up correctly before we "enable" them through the 
outer bridge mapping, so that depth-first makes sense, I think).

			Linus

  parent reply	other threads:[~2008-09-04  8:23 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-03  9:16 linux-next: Tree for September 3 Stephen Rothwell
2008-09-04  2:32 ` [PATCH] hid: fix gyration build error Randy Dunlap
2008-09-04  6:52   ` Jiri Slaby
2008-09-04  8:06     ` Jiri Kosina
2008-09-04  4:42 ` linux-next: Tree for September 3 Andrew Morton
2008-09-04  4:46 ` Andrew Morton
2008-09-04  4:54   ` Andrew Morton
2008-09-04  4:57     ` Stephen Rothwell
2008-09-04  5:05       ` Andrew Morton
2008-09-04  5:20         ` Stephen Rothwell
2008-09-04  6:01           ` Andrew Morton
2008-09-04  7:15             ` Andrew Morton
2008-09-04  7:48               ` Stephen Rothwell
2008-09-04  9:19               ` Alan Cox
2008-09-04  9:21               ` Alan Cox
2008-09-04 11:01               ` Alan Cox
2008-09-04 14:35               ` Alan Cox
2008-09-04  5:26         ` Linus Torvalds
2008-09-04  5:42           ` Andrew Morton
2008-09-04  5:00     ` Stephen Rothwell
2008-09-04  5:21   ` Linus Torvalds
2008-09-04  5:33     ` Andrew Morton
2008-09-04  7:14       ` Yinghai Lu
2008-09-04  8:00         ` Andrew Morton
2008-09-04  8:23         ` Linus Torvalds [this message]
2008-09-04  8:02       ` Linus Torvalds
2008-09-04  8:25         ` Andrew Morton
2008-09-04  8:37           ` Andrew Morton
2008-09-04  9:03             ` Linus Torvalds
2008-09-04  8:50           ` Linus Torvalds
2008-09-04  8:57             ` Andrew Morton
2008-09-04  9:07               ` Linus Torvalds
2008-09-04 17:45                 ` Andrew Morton
2008-09-04 18:05                   ` Linus Torvalds
2008-09-04 18:34                     ` Andrew Morton
2008-09-04 20:31                       ` Eric W. Biederman
2008-09-04 20:41                         ` Andrew Morton
2008-09-04 21:03                           ` Eric W. Biederman
2008-09-04 22:22                             ` Andrew Morton
2008-09-04 22:45                       ` Thomas Gleixner
2008-09-04 23:17                         ` Linus Torvalds
2008-09-05  5:39                           ` Arjan van de Ven
2008-09-04 23:17                         ` Andrew Morton
2008-09-04 23:25                           ` Linus Torvalds
2008-09-04 23:27                           ` Thomas Gleixner
2008-09-05 11:04                             ` Ingo Molnar
2008-09-05 17:49                               ` Andrew Morton
2008-09-09  4:39             ` Jesse Barnes
  -- strict thread matches above, loose matches on Subject: below --
2009-09-03 11:59 Stephen Rothwell
2010-09-03  3:52 Stephen Rothwell

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=alpine.LFD.1.10.0809040102260.3378@nehalem.linux-foundation.org \
    --to=torvalds@linux-foundation$(echo .)org \
    --cc=akpm@linux-foundation$(echo .)org \
    --cc=linux-kernel@vger$(echo .)kernel.org \
    --cc=linux-next@vger$(echo .)kernel.org \
    --cc=sfr@canb$(echo .)auug.org.au \
    --cc=yhlu.kernel@gmail$(echo .)com \
    /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