From owner-freebsd-current@FreeBSD.ORG Wed Jun 11 21:59:40 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90CD737B401; Wed, 11 Jun 2003 21:59:40 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 997C343F75; Wed, 11 Jun 2003 21:59:39 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h5C4xckA026546; Wed, 11 Jun 2003 22:59:38 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 11 Jun 2003 22:59:24 -0600 (MDT) Message-Id: <20030611.225924.52165341.imp@bsdimp.com> To: marks@ripe.net From: "M. Warner Losh" In-Reply-To: <20030610194132.GA4287@laptop.6bone.nl> References: <200306101644.h5AGiawR066527@puma.icir.org> <20030610191504.GA8927@laptop.6bone.nl> <20030610194132.GA4287@laptop.6bone.nl> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: orion@freebsd.org Subject: Re: Correct PCI suspend and resume operations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 04:59:40 -0000 In message: <20030610194132.GA4287@laptop.6bone.nl> Mark Santcroos writes: : On Tue, Jun 10, 2003 at 09:15:05PM +0200, Mark Santcroos wrote: : > > AFAICT, we don't common code for handling this and maybe there should : > > be some rather than have each driver replicate this behaviour. : > : > In general, that would of course be better. However, I don't know if the : > PCI layer (in this case) always knows enough. : > On the other side, if the device itself has to do some special things, the : > PCI layer could at least do the generic stuff. : : To be more precise, the suspend function should know the powerstate it is : transitioning to. If it keeps context (D0-D2) it doesn't need to do much : special, if it will loose context (D3) it should save the state at : suspend, and restore the state at resume. Sadly, in the current scheme, the device driver has no way of knowing what the new power state is going to be. Warner