AsiaBSDCon DEVSUMMIT patch
John Baldwin
jhb at freebsd.org
Thu Mar 27 14:37:34 PDT 2008
On Thursday 27 March 2008 04:20:52 pm M. Warner Losh wrote:
> In message: <200803271105.18401.jhb at freebsd.org>
> John Baldwin <jhb at freebsd.org> writes:
> : On Thursday 27 March 2008 03:32:29 am M. Warner Losh wrote:
> : > Greetings,
> : >
> : > We've been talking about the situation with suspend/resume in the
> : > tree. Here's a quick hack to allow one to suspend/resume an
> : > individual device. This may or may not work too well, but it is
> : > offered up for testing and criticism.
> : >
> : > http://people.freebsd.org/~imp/devctl.diff
> : >
> : > devctl -s ath 0 suspend ath0
> : > devctl -r ath 0 resume ath0
>
> Wow, you have a lot of comments for a simple test program :-)
>
> : Unfortunately, what you really need is to power down the device to D3 for
> : suspend and then bring it up. Otherwise you might not lose enough state
to
> : notice that resume isn't restoring all of it. bge(4) doesn't survive
resume
> : on my laptop I think because brgphy doesn't re-patch the firmware on
resume,
> : and you'd need a full power down to run into that sort of thing.
>
> True. I was going to implement this next as a bus method to have the
> bus to the right thing.
>
> : What I would actually prefer would be this:
> :
> : devctl ath0 power off (maps to D3 on PCI/ACPI)
> : devctl ath0 power D1 (PCI/ACPI-specific)
> : devctl ath0 power on (maps to D0 on PCI/APCI)
>
> I'm not sure I like this at all. This is about completely suspending
> a device, or completely resuming the device for testing purposes.
> Randomly putting the device into D1 state is a bad idea. The device
> driver itself should do that level of detail.
It is useful for doing some of what phk suggested earlier though. For
example, putting devices in D1 and seeing if you really get an interrupt on
link state events or USB device insertion, etc. That is, for debugging some
of the power management stuff. I imagine that on/off will be used the vast
majority of the time, but I can see D[12] being useful for debugging. I
wouldn't mind being able to manually turn devices off when I'm on an airplane
to conserve battery until such time as we get smarter drivers that
automatically manage the power. For example, I'd like to turn off my sound
card sometimes, or power down bge0 when iwi0 associates (since I only ever
use 1 of them).
> : If you want to do named commands (like 'power') rather than getopt args
for
> : everything you can use a linker set to build a table of commands (I've
done
> : this for RAID management utils at work) that let you do something like:
> :
> : struct devctl_power_request {
> : const char device[MAXDEVNAME];
> : const char state[32];
> : }
> :
> : #define DEVIOC_POWER _IOW('d', 1, struct devctl_power_request)
> :
> : /* av[0] will be 'power' */
> : static void
> : power_command(int ac, char **av)
> : {
> : struct devctl_power_request req;
> :
> : if (ac != 3)
> : errx(1, "Usage: devctl power <device> <state>");
> : strlcpy(req.device, av[1], sizeof(req.device));
> : strlcpy(req.state, av[2], sizeof(req.state));
> : if (ioctl(fd, DEVIOC_POWER, &req) < 0)
> : err(1, "Set power state failed");
> : }
> : DEVCTL_COMMAND(power);
> :
> : (Using a linker set makes it easier to add new commands later and have
them
> : all be self-contained.)
>
> Wow! that's a lot more complicated than I had in mind :-)
But is more extensible so you can have 'devctl eject foo0' (think ACPI _EJx
methods) or other commands that are a bit more user friendly in syntax than a
plethora of getopt options. It's also not that hard esp. since I've
basically sent you the implementation via private e-mail. :)
--
John Baldwin
More information about the freebsd-arch
mailing list