linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Yang <weiyang@linux.vnet.ibm.com>
To: linux-pci@vger.kernel.org
Subject: How acpi_walk_resources() find specific _CRS for one device
Date: Wed, 28 Mar 2012 17:30:04 +0800	[thread overview]
Message-ID: <20120328093004.GA31647@richard> (raw)

Experts

I am reading the PCI enumeration code on x86. One thing on ACPI
namespace puzzles me.

In the initialize process, the call flow is like this
acpi_pci_root_add()
	try_get_root_bridge_busnr()
		acpi_walk_resources(handle, METHOD_NAME__CRS,
		         get_root_bridge_busnr_callback, res)

By reading the ACPI spec, this is trying to go through the namespace and
find  the _CRS method/object.

1. Hmm... I want to know this function is trying to go through the whole
   namespace or just the device related namespace? 
2. If it is searching the whole namespace, how could this function find the
   device specific resource just by given the "_CRS" as a parameter?
3. Also, if it just go through the device specific namespace, which
   parameter identify this.

Here is an example in the ACPI specification in 9.11.1:
Device (PCI0) { // PCI Root Bridge
	Name (_HID, EISAID("PNP0A03"))
	Name (_UID, 0)
	Name (_BBN, 0x00)
	Name (_SEG, 0x00) // assign segment 0 of module device to PCI0
	Name (_CRS, ResourceTemplate () {
		WordBusNumber (
			ResourceProducer,
			MinFixed, // _MIF
			MaxFixed,, // _MAF
			0x00, // _GRA
			0x00, // _MIN
			0xFF, // _MAX
			0x0, // _TRA
			0x80) // _LEN
		WordIO (
			ResourceProducer,
			MinFixed, // _MIF
			MaxFixed,,, // _MAF
			0x0000, // _GRA
			0x0000, // _MIN
			0x0CF7, // _MAX
			0x0, // _TRA
			0x0CF8) // _LEN
		DWordMemory (
			ResourceProducer,,
			MinNotFixed, // _MIF
			MaxNotFixed, // _MAF
			NonCacheable, // _MEM
			ReadWrite, // _RW
			0x0FFFFFFF, // _GRA
			0x40000000, // _MIN
			0x5FFFFFFF, // _MAX
			0x0, // _TRA
			0x00000000) // _LEN
	})
	}
}

Device (PCI1) { // PCI Root Bridge
	Name (_HID, EISAID("PNP0A03"))
	Name (_UID, 0)
	Name (_BBN, 0x00)
	Name (_SEG, 0x01) // assign segment 1 of module device to PCI1
	Name (_CRS, ResourceTemplate () {
		WordBusNumber (
			ResourceProducer,
			MinFixed, //
			MaxFixed,, //
			0x00, //
			0x00, //
			0x7F, //
			0x0, //
			0x80) //
		WordIO (
			ResourceProducer,
			MinFixed, //
			MaxFixed, //
			0x0000, //
			0x0D00, //
			0x7FFF, //
			0x0, //
			0x7300) //
		DWordMemory (
			ResourceProducer,
			MinNotFixed,
			MaxNotFixed,
			NonCacheable,
			ReadWrite,
			0x0FFFFFFF,
			0x60000000,
			0x7FFFFFFF,
			0x0,
			0x00000000)
	})
	}
}

We can see there are two PCI Root Bridge, and each has its own _CRS
field. And each field has its own busnumber/iores/memios.

So, in the acpi_walk_resources() function, how to find the proper _CRS
infomation for a root device?

-- 
Richard Yang
Help you, Help me


             reply	other threads:[~2012-03-28  9:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-28  9:30 Richard Yang [this message]
2012-03-28 13:20 ` How acpi_walk_resources() find specific _CRS for one device Jiang Liu
2012-03-29  6:12   ` Richard Yang

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=20120328093004.GA31647@richard \
    --to=weiyang@linux.vnet.ibm.com \
    --cc=linux-pci@vger.kernel.org \
    /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).