From owner-cvs-all@FreeBSD.ORG Sun May 23 20:51:07 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E25FD16A4CE for ; Sun, 23 May 2004 20:51:07 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id ADB5B43D49 for ; Sun, 23 May 2004 20:51:07 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 66545 invoked by uid 1000); 24 May 2004 03:50:00 -0000 Date: Sun, 23 May 2004 20:50:00 -0700 (PDT) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040522.204941.88514900.imp@bsdimp.com> Message-ID: <20040523204728.U66525@root.org> References: <40ADAF07.2070909@freebsd.org> <20040521.020412.118756775.imp@bsdimp.com> <20040522.204941.88514900.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: scottl@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/pci pci.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2004 03:51:08 -0000 On Sat, 22 May 2004, M. Warner Losh wrote: > In message: <20040522103658.P58631@root.org> > Nate Lawson writes: > : On Fri, 21 May 2004, M. Warner Losh wrote: > : > In message: <40ADAF07.2070909@freebsd.org> > : > Scott Long 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. -Nate