Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 May 2004 21:57:36 -0600 (MDT)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        nate@root.org
Cc:        cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/dev/pci pci.c
Message-ID:  <20040523.215736.44518029.imp@bsdimp.com>
In-Reply-To: <20040523204728.U66525@root.org>
References:  <20040522103658.P58631@root.org> <20040522.204941.88514900.imp@bsdimp.com> <20040523204728.U66525@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040523204728.U66525@root.org>
            Nate Lawson <nate@root.org> writes:
: On Sat, 22 May 2004, M. Warner Losh wrote:
: > In message: <20040522103658.P58631@root.org>
: >             Nate Lawson <nate@root.org> writes:
: > : On Fri, 21 May 2004, M. Warner Losh wrote:
: > : > In message: <40ADAF07.2070909@freebsd.org>
: > : >             Scott Long <scottl@freebsd.org> writes:
: > : > : Warner Losh wrote:
: > : > : >   MFp4: o save/restore subvendor, subdevice, vendor, device, baseclass,
: > : > : >           subclass, progif and revid.  While these are typically read
: > : > : >           only fields, they aren't always read-only.  progif is writable
: > : > : >           for ata devices, for example.  It does no harm when they are
: > : > : >           read only, and helps when they aren't.
: > : > : >
: > : > : >   Revision  Changes    Path
: > : > : >   1.252     +16 -0     src/sys/dev/pci/pci.c
: > : > :
: > : > : Shouldn't it be left up to the device drivers to decide if a buggy piece
: > : > : of silicon needs to be touched like this?  I really don't like the bus
: > : > : unilaterally enforcing this on everything.
: > : >
: > : > This just preserves the values across a D3 -> D0 state transition.
: > : > This seems to be required by the 1.1 version of the pci power spec:
: > : >
: > : > 	Section 5.4: "When a function is brought back to D0...,
: > : > 	software will need to perform a full initialization of the
: > : > 	function, including its PCI Configuration space."
: > : >
: > : > 	Section 8.3.3: For example, reinitialization includes, but is
: > : > 	not necessarily limited to, restoring the Base Address
: > : > 	registers, re-enabling the I/O and memory spaces, re-enabling
: > : > 	bus master capabilities, and unmasking any IRQs or PCI
: > : > 	Interrupts as well as restoring the INT Line
: > : > 	register. Furthermore, if the function has the DSI bit set,
: > : > 	the operating system is required to execute whatever
: > : > 	initialization code is necessary, either via the device
: > : > 	driver's initialization code or by executing POST.
: > : >
: > : > My reading of these two sections lead me to save this information.
: > :
: > : I didn't know the code didn't do this fully before.  Yes, it is important
: > : to save/restore all the headers across a D3 transition.  I don't know of
: > : any devices this breaks.
: >
: > Well, we're talking exclusively about the vendor, device, subvendor,
: > subdevice, class, subclass and progif fields, which are obstensively
: > read-only.  However, the pci standards are self-contradictory.  The
: > main 2.2 one says they are read-only (without defining what that means
: > that I could find), yet the pciide spec says that progif had writable
: > bits...
: 
: I think the progif is the only one of that list that you need to restore,
: as per your reading of the specs.  Since the others are identifiers, they
: probably don't need to be restored.

Things are vague enough in the spec that this is totally
unsatisfying.  We're just guessing based on hunches, which I really
don't like, which is why I saved/restored everything.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040523.215736.44518029.imp>