Date: Sat, 22 May 2004 20:49:41 -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: <20040522.204941.88514900.imp@bsdimp.com> In-Reply-To: <20040522103658.P58631@root.org> References: <40ADAF07.2070909@freebsd.org> <20040521.020412.118756775.imp@bsdimp.com> <20040522103658.P58631@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: : > : > imp 2004/05/20 23:36:36 PDT : > : > : > : > FreeBSD src repository : > : > : > : > Modified files: : > : > sys/dev/pci pci.c : > : > Log: : > : > 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... The other fields have already been restored for a few weeks now on D3 -> D0 transition. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040522.204941.88514900.imp>