linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wei Yang <weiyang@linux.vnet.ibm.com>
To: linux-pci@vger.kernel.org, Ram Pai <linuxram@us.ibm.com>
Cc: bhelgaas@google.com
Subject: One question about the pci_assign_unassign_resources()
Date: Fri, 31 May 2013 09:52:27 +0800	[thread overview]
Message-ID: <20130531015226.GA5900@weiyang.vnet.ibm.com> (raw)

All experts,

Sorry for disturbing all of you. I met a confusion in the 
pci_assign_unassign_resources(). 

Below is the code snippet in pci_assign_unassign_resources():

	/* restore size and flags */
	list_for_each_entry(fail_res, &fail_head, list) {
		struct resource *res = fail_res->res;

		res->start = fail_res->start;
		res->end = fail_res->end;
		res->flags = fail_res->flags;
		if (fail_res->dev->subordinate)
			res->flags = 0;      <---- here
	}

This happens when there is some fail resources and try to restore them, and
prepare for the next round assignment.
My confusion is at the last line. When this resource is from a bridge, set the
flags to 0.

When a resource comes from a bridge, it has two possibilities:
1. the BAR of itself, dev->resource[0-1]
2. the io window for children, 
   dev->resource[PCI_BRIDGE_RESOURCES, PCI_BRIDGE_RESOURCES+PCI_BRIDGE_RESOURCE_NUM]

For case 1, this will disable the bridge's BAR.
    So in next round, the resource form this bridge will not be assigned.
For case 2, this will disable the io window for its children.
    In this case, sounds the children of this bridge can't get resource from
    this window.

Let's take a look at the effect in another aspect. There two phase in the
function pci_assign_unassign_resources(), 1. sizing 2. assigning.

1. In the sizing stage:
   For an individual resource, when its flags is 0, the bridge window will not
   count in its contribution.

   For a bridge resource, if its flags is set to 0, its children can't find a
   proper parent resource. For example, if the bridge's IOMEM window's flags
   is set to 0, sounds all the children's IOMEM resource wouldn't count in.

2. In the assigning stage:
   For an individual resource, ok, the pci core won't try to request resource
   for it. Then this means the resource will not be enabled.

   For a bridge resource, if its flags is set to 0, its children can't find
   available resource from it.

If my understanding is correct, let's take a look at one scenario.

                            +---------+
                            |P2P      |
                            +----+----+
                                 |
                                 |
        -----+-------------------+------------------------+-----
             |                   |                        |
        +----+-------+     +-----+-----+           +------+-----+
        |DEV0        |     |DEV1       |           |DEV2        |
        +------------+     +-----------+           +------------+

There are three devices under one P2P bridge. All of them want IOMEM resource. 
But in the first round, DEV0 and DEV1 get enough resource but DEV2 failed to
get its IOMEM resource. 

>From the code point of view, then it will try to disable the IOMEM window on
the P2P bridge? Then in the next round non of them will be given IOMEM
resource?

Or I missed something? 

Thanks for your comments in advance.

-- 
Richard Yang
Help you, Help me


                 reply	other threads:[~2013-05-31  1:52 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20130531015226.GA5900@weiyang.vnet.ibm.com \
    --to=weiyang@linux.vnet.ibm.com \
    --cc=bhelgaas@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxram@us.ibm.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).