Date: Thu, 14 Sep 1995 23:05:18 -0700
From: jordan@pongo.West.Sun.COM (Jordan Brown)
Subject: Item #286: PCI Supp: Order of reg tuples for non-FCode PCI devices

P1275 Openboot Working Group Proposal -- Proposal #:286 Ver 1.0

Title:          Order of reg tuples for non-FCode PCI devices

Author:         Jordan Brown

Date:           14 September 1995

Ed/Tech:        Technical

Synopsis:       Specifies the order of reg tuples for non-FCode PCI devices

Doc & Version:  PCI binding 1.5

Problem:

	It is my understanding that on other bus types the order of
	entries in "reg" tuples is meaningful.  That is, the
	documentation for a device might say "the first reg tuple
	describes the ABC set of registers, and the second reg tuple
	describes the XYZ set of registers", and the client program
	is expected to make use of this information, eg examining the
	second tuple to find the XYZ registers.

	While these assumptions probably hold true for devices with
	FCode support since the reg property is generated by the
	FCode for the device, it is not clear that they hold true
	for non-FCode devices where the reg property is generated
	by the platform firmware.

Proposal:       

Under the "probe-pci" method, under the section beginning "If the function
does not have an FCode Program", replace

"reg"   Create entries for all active configuration base registers,
	including the Expansion ROM base register, with size components
	describing the total size of the region mapped by each register.

with

"reg"	Create the following entries, in the order shown:
	. An entry describing the Configuration Space for the
	  function.
	. For each active base register, in Configuration Space
	  order, an entry describing the entire space mapped by that
	  base register.  The phys_mid and phys_lo components of
	  these entries are to be zero, and the "size" components are
	  to be derived by probing the base register.
	. If the device supports an expansion ROM, an entry describing
	  the expansion ROM, constructed as for the base registers.
	. If applicable, "legacy" entries described in the
	  "Legacy Devices" section below, in the order shown.

	Note:  Without FCode, is is not necessarily possible to
	determine whether or not there are multiple base address
	registers mapping the same resource, so it is not possible to
	create an "alternate-reg" property.

In addition, in the "Open Firmware-defined Properties for Child Nodes",
add to the end of the definition of "reg":

	Note:  The device FCode is free to construct the second and
	later pairs in any order, including or omitting references to
	base registers, hard-decoded registers, and so on.  However,
	for compatibility between FCode and earlier non-FCode versions
	of a device and between Open Firmware and non-Open Firmware
	systems, it is recommended that the device FCode construct the
	"reg" property *exactly* as the platform firmware would have in
	the absence of device FCode, as described under "probe-pci".

[ P1275 Item #286 -- Received: Thu Sep 14 23:08:35 PDT 1995 ]