From owner-acpi-jp@jp.FreeBSD.org Sat Jan  3 06:45:24 2004
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) id i02LjOn04428;
	Sat, 3 Jan 2004 06:45:24 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from root.org (root.org [67.118.192.226])
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) with SMTP/inet id i02LjMC04422
	for <acpi-jp@jp.freebsd.org>; Sat, 3 Jan 2004 06:45:22 +0900 (JST)
	(envelope-from nate@root.org)
Received: (qmail 9934 invoked by uid 1000); 2 Jan 2004 21:45:18 -0000
From: Nate Lawson <nate@root.org>
To: Lukas Ertl <l.ertl@univie.ac.at>
cc: current@freebsd.org, acpi-jp@jp.FreeBSD.org
In-Reply-To: <20031230211930.K64407@leelou.in.tern>
Message-ID: <20040102134132.W9534@root.org>
References: <20031230115806.M98869@root.org> <20031230211930.K64407@leelou.in.tern>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Fri, 2 Jan 2004 13:45:18 -0800
X-Sequence: acpi-jp 2967
Subject: [acpi-jp 2967] Re: rc.suspend/rc.resume acpi support added
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: nate@root.org
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+031216

On Tue, 30 Dec 2003, Lukas Ertl wrote:
> On Tue, 30 Dec 2003, Nate Lawson wrote:
> > This helps for uhci where we have to unload and reload usb.ko across
> > suspends since it doesn't re-initialize correctly.  See the usb comments
> > in the files for an example.
>
> If I understand correctly, usb.ko can't be unloaded, because it has no
> detach method connected. (At least I wasn't able to unload it.)
>
> Anyway, this bandaid wouldn't work on this machine, since I tried to load
> the usb module after a suspend and UHCI still wouldn't work (see
> kern/59747) - it seems like all controller register bits are set, and I
> couldn't find a way to clear them.

Oops, you're right.  It may help for sound drivers though.

> The UHCI controller works fine with APM suspend, though.

That's because the BIOS does all the reinitialization in the APM case.
The biggest issue with ACPI suspend/resume is that suddenly all of our
device drivers are responsible for detecting the state of various hardware
(from uninitialized to various partially-initialized states) and restoring
the rest.  Like the kid's game "Operation", poking a register that already
has been initialized or neglecting to restore something the BIOS no longer
handles makes the driver inoperable (i.e. uhci) or worse, breaks resume
(i.e. many video drivers).

It would be great if each driver author would go back to the datasheet and
make sure they're doing things correctly and not relying on the BIOS.

-Nate
