From: Dale P. <DEP...@ed...> - 2010-02-06 22:21:18
|
This is more of a practical question than anything to do with code. (I think) But the practical experience to answer it is probably here. I have an ASUS M2N68-AM in an Antec Fusion case with the imon vfd. I want to "appliance-ify" the thing, and at the moment to me that means making it go into suspend instead of hibernate or power-off. I want the instant-on of an appliance. (Oh, a MythTV frontend, by the way.) But according to "/proc/acpi/wake", my board can only wake from suspend via EHCI-attached USB devices. The OHCI-attached USB devices (and several other things, too) can only wake it from hibernate. Right now my imon vfd shows up as an OHCI device. I tried moving plugs around hoping that maybe there was some division by port, though I realize that OHCI and EHCI both bind to the same port - ya gotta try. I also tried blacklisting OHCI, hoping EHCI would grab it. No go, I can't get the imon vfd to attach to EHCI. I've recently done a little more reading, and it appears that if I run it into a USB 2.0 hub, the hub will translate its signaling to USB 2.0, and then my board should grab it with EHCI - problem solved. Question 1: Will any USB 2.0 hub do, or do some cheaper hubs somehow manage to skip the translation step. Has anyone run across this, or have experience with it? Question 2: Is there really a way to do this in software, by configuration, without having to add a port? Thanks Dale Pontius |
From: Dale P. <DEP...@ed...> - 2010-02-10 01:19:13
|
Dale Pontius wrote: > This is more of a practical question than anything to do with code. (I > think) But the practical experience to answer it is probably here. > > I have an ASUS M2N68-AM in an Antec Fusion case with the imon vfd. I > want to "appliance-ify" the thing, and at the moment to me that means > making it go into suspend instead of hibernate or power-off. I want the > instant-on of an appliance. (Oh, a MythTV frontend, by the way.) > > But according to "/proc/acpi/wake", my board can only wake from suspend > via EHCI-attached USB devices. The OHCI-attached USB devices (and > several other things, too) can only wake it from hibernate. Right now > my imon vfd shows up as an OHCI device. I tried moving plugs around > hoping that maybe there was some division by port, though I realize that > OHCI and EHCI both bind to the same port - ya gotta try. I also tried > blacklisting OHCI, hoping EHCI would grab it. No go, I can't get the > imon vfd to attach to EHCI. > > I've recently done a little more reading, and it appears that if I run > it into a USB 2.0 hub, the hub will translate its signaling to USB 2.0, > and then my board should grab it with EHCI - problem solved. > > Question 1: Will any USB 2.0 hub do, or do some cheaper hubs somehow > manage to skip the translation step. Has anyone run across this, or > have experience with it? > > Question 2: Is there really a way to do this in software, by > configuration, without having to add a port? > OK, a co-worker had a USB 2.0 hub he loaned me. Plugging the hub in, I find that it's a "translating hub", so any USB 1.1 device plugged in gets handled through UHCI. Since the imon is buried in the case, my first experiment was to plug a spare mouse into the hub, enable that USB in /proc/acpi/wake, and hibernate-ram. I was able to wake the system with a mouse button. (though not a mouse-shake) So I opened the case and routed the imon through the hub. I can't wake the system - not with the power button, nor with the other half-dozen buttons I've tried, not with the volume control. By the way, this is a Vista MCE (rc6) remote control - not the imon remote. I've never had any proper function out of the power button on the remote. Any suggestions? Dale Pontius |
From: Maxim L. <max...@gm...> - 2010-02-10 14:32:36
|
On Sat, 2010-02-06 at 17:21 -0500, Dale Pontius wrote: > This is more of a practical question than anything to do with code. (I > think) But the practical experience to answer it is probably here. > > I have an ASUS M2N68-AM in an Antec Fusion case with the imon vfd. I > want to "appliance-ify" the thing, and at the moment to me that means > making it go into suspend instead of hibernate or power-off. I want the > instant-on of an appliance. (Oh, a MythTV frontend, by the way.) > > But according to "/proc/acpi/wake" You mean something like that? maxim@maxim-laptop:~$ cat /proc/acpi/wakeup Device S-state Status Sysfs node UHC1 S3 disabled pci:0000:00:1d.0 UHC2 S3 disabled pci:0000:00:1d.1 UHC3 S3 disabled pci:0000:00:1d.2 UHC4 S3 disabled pci:0000:00:1a.0 UHC5 S3 disabled pci:0000:00:1a.1 EHC1 S3 disabled pci:0000:00:1d.7 EHC2 S3 disabled pci:0000:00:1a.7 EXP3 S4 disabled pci:0000:00:1c.2 EXP5 S4 disabled EXP6 S4 disabled AZAL S4 disabled pci:0000:00:1b.0 MODM S4 disabled The S-state is the highest state from with wakeup can be done. S3 means wakeup only from suspend, S4 means both suspend and hibernate. You also do know that you need to enable each wakeup source like echo UHC1 > /proc/acpi/wakeup Best regards, Maxim Levitsky |
From: Dale P. <DEP...@ed...> - 2010-02-11 00:57:21
|
Maxim Levitsky wrote: > On Sat, 2010-02-06 at 17:21 -0500, Dale Pontius wrote: >> This is more of a practical question than anything to do with code. (I >> think) But the practical experience to answer it is probably here. >> >> I have an ASUS M2N68-AM in an Antec Fusion case with the imon vfd. I >> want to "appliance-ify" the thing, and at the moment to me that means >> making it go into suspend instead of hibernate or power-off. I want the >> instant-on of an appliance. (Oh, a MythTV frontend, by the way.) >> >> But according to "/proc/acpi/wake" > You mean something like that? > > maxim@maxim-laptop:~$ cat /proc/acpi/wakeup > Device S-state Status Sysfs node > UHC1 S3 disabled pci:0000:00:1d.0 > UHC2 S3 disabled pci:0000:00:1d.1 > UHC3 S3 disabled pci:0000:00:1d.2 > UHC4 S3 disabled pci:0000:00:1a.0 > UHC5 S3 disabled pci:0000:00:1a.1 > EHC1 S3 disabled pci:0000:00:1d.7 > EHC2 S3 disabled pci:0000:00:1a.7 > EXP3 S4 disabled pci:0000:00:1c.2 > EXP5 S4 disabled > EXP6 S4 disabled > AZAL S4 disabled pci:0000:00:1b.0 > MODM S4 disabled > > > > The S-state is the highest state from with wakeup can be done. Oops... I didn't understand the meaning of "cat /proc/acpi/wakeup". I had this silly idea that S4 meant that it could only wake from S4, and that in order to wake from S3, there had to be an S3 there. I just verified that I could wake from suspend with my regular mouse. It works. lsusb Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller Bus 001 Device 002: ID 17d0:0115 Sanford L.P. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 002: ID 046d:c018 Logitech, Inc. Optical Wheel Mouse Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub cat /proc/acpi/wakeup Device S-state Status Sysfs node PS2K S4 disabled pnp:00:09 UAR1 S4 disabled pnp:00:0b NSMB S4 disabled pci:0000:00:01.1 USB0 S4 disabled pci:0000:00:02.0 USB2 S3 disabled pci:0000:00:02.1 US15 S4 enabled pci:0000:00:04.0 US12 S3 disabled pci:0000:00:04.1 NMAC S5 disabled pci:0000:00:0a.0 P0P1 S4 disabled pci:0000:00:08.0 HDAC S4 disabled BR10 S4 disabled pci:0000:00:0b.0 BR11 S4 disabled pci:0000:00:0c.0 You can see the "residue" of my experiment here, on US15. Thanks for clearing up a basic misunderstanding on my part. I don't need an extra USB 2.0 hub at all, because I can wake on a USB 1.1 port without the hassle. That leaves me with the question of why I couldn't wake the system with my imon, when plugged in through the USB 2.0 hub, however. I did have the correct enabling done. That's going to be a different question however, since there are some other imon/rc6 questions I have to ask. Dale Pontius |
From: Maxim L. <max...@gm...> - 2010-02-11 17:47:24
|
On Wed, 2010-02-10 at 19:19 -0500, Dale Pontius wrote: > Maxim Levitsky wrote: > > On Sat, 2010-02-06 at 17:21 -0500, Dale Pontius wrote: > >> This is more of a practical question than anything to do with code. (I > >> think) But the practical experience to answer it is probably here. > >> > >> I have an ASUS M2N68-AM in an Antec Fusion case with the imon vfd. I > >> want to "appliance-ify" the thing, and at the moment to me that means > >> making it go into suspend instead of hibernate or power-off. I want the > >> instant-on of an appliance. (Oh, a MythTV frontend, by the way.) > >> > >> But according to "/proc/acpi/wake" > > You mean something like that? > > > > maxim@maxim-laptop:~$ cat /proc/acpi/wakeup > > Device S-state Status Sysfs node > > UHC1 S3 disabled pci:0000:00:1d.0 > > UHC2 S3 disabled pci:0000:00:1d.1 > > UHC3 S3 disabled pci:0000:00:1d.2 > > UHC4 S3 disabled pci:0000:00:1a.0 > > UHC5 S3 disabled pci:0000:00:1a.1 > > EHC1 S3 disabled pci:0000:00:1d.7 > > EHC2 S3 disabled pci:0000:00:1a.7 > > EXP3 S4 disabled pci:0000:00:1c.2 > > EXP5 S4 disabled > > EXP6 S4 disabled > > AZAL S4 disabled pci:0000:00:1b.0 > > MODM S4 disabled > > > > > > > > The S-state is the highest state from with wakeup can be done. > Oops... > > I didn't understand the meaning of "cat /proc/acpi/wakeup". I had this > silly idea that S4 meant that it could only wake from S4, and that in > order to wake from S3, there had to be an S3 there. What you say now IS right. S4 means it can wake from S4 only S3 means it can wake from S3 and S4 > > I just verified that I could wake from suspend with my regular mouse. > It works. > > lsusb > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 001 Device 003: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller > Bus 001 Device 002: ID 17d0:0115 Sanford L.P. > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 004 Device 002: ID 046d:c018 Logitech, Inc. Optical Wheel Mouse > Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > > cat /proc/acpi/wakeup > Device S-state Status Sysfs node > PS2K S4 disabled pnp:00:09 > UAR1 S4 disabled pnp:00:0b > NSMB S4 disabled pci:0000:00:01.1 > USB0 S4 disabled pci:0000:00:02.0 > USB2 S3 disabled pci:0000:00:02.1 > US15 S4 enabled pci:0000:00:04.0 > US12 S3 disabled pci:0000:00:04.1 > NMAC S5 disabled pci:0000:00:0a.0 > P0P1 S4 disabled pci:0000:00:08.0 > HDAC S4 disabled > BR10 S4 disabled pci:0000:00:0b.0 > BR11 S4 disabled pci:0000:00:0c.0 > > You can see the "residue" of my experiment here, on US15. Thanks for > clearing up a basic misunderstanding on my part. I don't need an extra > USB 2.0 hub at all, because I can wake on a USB 1.1 port without the hassle. > > That leaves me with the question of why I couldn't wake the system with > my imon, when plugged in through the USB 2.0 hub, however. I did have > the correct enabling done. That's going to be a different question > however, since there are some other imon/rc6 questions I have to ask. You mean without hub, wake works? In that case I would guess that hub doesn't propagate the wake command upstream (note that I don't know how that is done yet). I have zero knowlege of the imon driver however. Best regards, Maxim Levitsky |