Re: [Barry-devel] The many ways to enable/disable CONFIG_USB_SUSPEND's autosuspend mode

2007-09-29 Thread Chris Frey
On Sat, Sep 29, 2007 at 07:44:18PM -0700, troy engel wrote:
 Chris, are you aware of any problems - other than more battery usage
 on a laptop e.g. - with disabling USB suspend? A quick Google

I know of no such problems... actually the only problems I've had
are with leaving it on. :-)

Obviously if you're trying for optimum battery life, then suspend
is handy, but in relation to the Blackberry, you're better off just
unplugging it when you don't need it connected.  Can't beat 0 watts :-)


 indicates we're not the only ones in this category (xsane/sane seems
 to have lots of issues with it as well) and folks are disabling it, as
 well I found a thread on a Fedora list where the dev's discuss all the
 devices with quirks but they feel it should be enabled globally.

I took a peek at Ubuntu 7.10 Gutsy's latest kernel, and they patch
driver/usb/core/quirks.c with a whole list of devices, the Blackberry
being one of them, so it looks like this problem will go away for
those folks upgrading early.

The upcoming Barry 0.9 will hopefully fix this on Ubuntu 7.04 and
Fedora 7 as well.  I plan to do more testing, but so far CVS's bcharge
is performing admirably on my system.  (Debian stable)


 In your tests and setup, is it bcharge doing the disabling at runtime
 or are you passing the parameter to the kernel at boot/initrd and
 disabling it globally?

Bcharge uses a hint from udev to find the right device under /sys,
and then searches for the files level, autosuspend, and state
in the following order, writing on, -1 or 0, and 0
respectively.

This only disables autosuspend for the Blackberry that udev detected
was just plugged in.

Bcharge can't disable this globally.  That requires a reboot.

- Chris


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel


Re: [Barry-devel] The many ways to enable/disable CONFIG_USB_SUSPEND's autosuspend mode

2007-09-29 Thread troy engel
On 9/29/07, Chris Frey [EMAIL PROTECTED] wrote:
 It works great in my tests here.  I'm letting it sit for a while to make
 sure the kernel stays in on mode.  So far so good.

Chris, are you aware of any problems - other than more battery usage
on a laptop e.g. - with disabling USB suspend? A quick Google
indicates we're not the only ones in this category (xsane/sane seems
to have lots of issues with it as well) and folks are disabling it, as
well I found a thread on a Fedora list where the dev's discuss all the
devices with quirks but they feel it should be enabled globally.

In your tests and setup, is it bcharge doing the disabling at runtime
or are you passing the parameter to the kernel at boot/initrd and
disabling it globally?

thx,
-te

-- 
I live in my own little world, but it's ok; they know me here.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel


Re: [Barry-devel] The many ways to enable/disable CONFIG_USB_SUSPEND's autosuspend mode

2007-09-29 Thread Chris Frey
On Sat, Sep 29, 2007 at 01:35:53AM -0400, Chris Frey wrote:
 I'll update bcharge
 soon to try to handle this automatically, but I'm not sure it will
 work in every case.

Ok, CVS has been updated with a fix to bcharge.

If your system has the file level or autosuspend under
/sys/class/usb_device/*/device/power/ then you should be able to charge
your Blackberry without recompiling the kernel.

It works great in my tests here.  I'm letting it sit for a while to make
sure the kernel stays in on mode.  So far so good.

- Chris


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel


Re: [Barry-devel] The many ways to enable/disable CONFIG_USB_SUSPEND's autosuspend mode

2007-09-29 Thread troy engel
On 9/29/07, Chris Frey [EMAIL PROTECTED] wrote:
 I know of no such problems... actually the only problems I've had
 are with leaving it on. :-)

Heh. I was more thinking like with a USB mouse and so forth, but your
below comments clarified that we're only disabling it at runtime for
the single device so this is a non-issue.

 Bcharge can't disable this globally.  That requires a reboot.

Right, I gotcha - sorry I meant disabling it via the dev/sys method
you spelled out, or passing the global parameter on the kernel boot
line (or modules.conf/initrd) for the entire machine. Since your
previous email outlined how we could do that, I didn't know which
method your test setup was using. All is clear now. :)

-te

-- 
I live in my own little world, but it's ok; they know me here.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel


[Barry-devel] The many ways to enable/disable CONFIG_USB_SUSPEND's autosuspend mode

2007-09-28 Thread Chris Frey
Hi folks,

Well, I spent a chunk of tonight researching the practical ways of
controlling CONFIG_USB_SUSPEND, or as we'll call it below: autosuspend.

Here are the results:

Kernels:


Version 2.6.21 behaves with autosuspend=0 meaning off, while 2.6.22
and higher needs autosuspend=-1 to turn it off.  In 2.6.22, a value
of 0 means immediate instead of never.

Version 2.6.22 adds variables internal to the system called
autosuspend_disabled and autoresume_disabled.  These are controlled by the
/sys/class/usb_device/*/device/power/level file.  (See below)

Here's a summary of files under device/power.  These may or may not exist
on your system depending on your kernel version and configuration.


autosuspend
-1 or 0 means off, depending on kernel,
otherwise it is the number of seconds to
autosuspend

level 
with the settings:

on  - suspend is disabled, device is fully powered
auto- suspend is controlled by the kernel (default)
suspend - suspend is enabled permanently

You can write these strings to the file to control
behaviour on a per-device basis.

echo on  /sys/usb_device/.../device/power/level

state
current state of device
0 - fully powered
2 - suspended

You can write these numbers to control behaviour, but
any change you make here might change automatically
if autosuspend is on.

echo -n 0  /sys/usb_device/.../device/power/state

wakeup
unknown



Based on the feedback from Chuck Ebbert, it is possible to disable
autosuspend on a system wide basis as well.  This is either done on
the kernel boot command line if usbcore is compiled into the kernel,
or on the module command line, if not.

Here are some practical notes for various distros:


Debian / Ubuntu systems:


Comes with usbcore (CONFIG_USB) compiled as a module and CONFIG_USB_SUSPEND
enabled (at least on Ubuntu).

Therefore, to disable autosuspend you either:

- recompile kernel without CONFIG_USB_SUSPEND

- configure /etc/modprobe.d/ with a file containing
options usbcore autosuspend=-1
or set to 0 depending on your kernel

If your system needs the modprobe configuration file above, and if your
system uses initrd (probably does) then you will need to rebuild the
initrd for your kernel for this to take effect.  For example:

dpkg-reconfigure linux-image-2.6.22.1


Fedora 6 and 7 systems: 
===

Comes with usbcore (CONFIG_USB) compiled into the the kernel, and
CONFIG_USB_SUSPEND enabled on Fedora 7.

Therefore to disable autosuspend you either:

- recompile kernel without CONFIG_USB_SUSPEND

- boot with one of the following, depending
  on your kernel version (2.6.21 or 2.6.22 respectively):

usbcore.autosuspend=0

usbcore.autosuspend=-1


Summary:


It seems that bcharge could be coded to search for device/power/level,
device/power/autosuspend, and device/power/state and use some heuristics
to decide what best action to take.

Fortunately, the kernel gives an error if you write -1 to autosuspend
and the kernel doesn't support it, in which case writing 0 seems to be
the next step. :-)

Unfortunately, the files under device/power do not always exist, even
while autosuspend is enabled, from what I can tell.  I'll update bcharge
soon to try to handle this automatically, but I'm not sure it will
work in every case.

Anyway, I'm getting verbose, and it's late, so I thought I'd post this
in the meantime.  At least the info is out there and people can test. :-)

Good luck, and please send feedback if you have it.

- Chris


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel