Am Montag, 4. Mai 2009 19:29:02 schrieb Marcel Holtmann:
> Hi Peter,
>
> > What is the current status of btusb auto suspend? btusb not having this
> > feature basically renders BT useless on mobile devices.
> >
> > I found some rfc patches and discussion over on linux-pm/-usb but
> > couldn't find a clear consensus.
>
> I think none of the patches apply anymore. So they have to be redone
> against the latest -rc4 kernel or bluetooth-testing.git.
I am porting forward to Linus' tree. I thought they'd safely wait for
the next merge window.
> We had some battles with broken Bluetooth hardware that requires to keep
> the interrupt and bulk URBs in fly, because otherwise the firmware
> inside the controller can't sync them up and times out. These are all
> fixed now, but nobody has looked at the auto suspend stuff. Feel free to
It will have to be changed to work with those buggy devices.
Do you have a pointer to a page describing the problem in detail?
> pick Oliver's patches up and send them for review. If you do so, please
> use [email protected] since I do miss posting on LKML from
> time to time.
Peter, are you willing to test?
Regards
Oliver
Hi Oliver,
> > > It will have to be changed to work with those buggy devices.
> > > Do you have a pointer to a page describing the problem in detail?
> >
> > The problem is that the interrupt URBs and bulk URBs for RX have to be
> > always scheduled. Not matter if we have an ACL link or. Once the device
> > is up they have to there. Some devices just don't like it if we only
> > have interrupt URBs.
>
> OK, I see. Does the order they are submitted in matter?
I really don't think so, but you never know.
Regards
Marcel
Am Samstag, 9. Mai 2009 00:09:41 schrieb Marcel Holtmann:
> > It will have to be changed to work with those buggy devices.
> > Do you have a pointer to a page describing the problem in detail?
>
> The problem is that the interrupt URBs and bulk URBs for RX have to be
> always scheduled. Not matter if we have an ACL link or. Once the device
> is up they have to there. Some devices just don't like it if we only
> have interrupt URBs.
OK, I see. Does the order they are submitted in matter?
Regards
Oliver
Hi Oliver,
> > > What is the current status of btusb auto suspend? btusb not having this
> > > feature basically renders BT useless on mobile devices.
> > >
> > > I found some rfc patches and discussion over on linux-pm/-usb but
> > > couldn't find a clear consensus.
> >
> > I think none of the patches apply anymore. So they have to be redone
> > against the latest -rc4 kernel or bluetooth-testing.git.
>
> I am porting forward to Linus' tree. I thought they'd safely wait for
> the next merge window.
I can push them into bluetooth-testing.git tree.
> > We had some battles with broken Bluetooth hardware that requires to keep
> > the interrupt and bulk URBs in fly, because otherwise the firmware
> > inside the controller can't sync them up and times out. These are all
> > fixed now, but nobody has looked at the auto suspend stuff. Feel free to
>
> It will have to be changed to work with those buggy devices.
> Do you have a pointer to a page describing the problem in detail?
The problem is that the interrupt URBs and bulk URBs for RX have to be
always scheduled. Not matter if we have an ACL link or. Once the device
is up they have to there. Some devices just don't like it if we only
have interrupt URBs.
Regards
Marcel
On Fri, 2009-05-08 at 22:30 +0200, Oliver Neukum wrote:
> Am Freitag, 8. Mai 2009 22:26:12 schrieb Peter Zijlstra:
> > > Peter, are you willing to test?
> >
> > Sure, I have two laptops with integrated bluetooth to test on.
>
> This will probably crash.
Well then we'll have to like debug it ;-)
Am Freitag, 8. Mai 2009 22:26:12 schrieb Peter Zijlstra:
> > Peter, are you willing to test?
>
> Sure, I have two laptops with integrated bluetooth to test on.
This will probably crash.
Regards
Oliver
On Fri, 2009-05-08 at 22:23 +0200, Oliver Neukum wrote:
> Am Montag, 4. Mai 2009 19:29:02 schrieb Marcel Holtmann:
> > Hi Peter,
> >
> > > What is the current status of btusb auto suspend? btusb not having this
> > > feature basically renders BT useless on mobile devices.
> > >
> > > I found some rfc patches and discussion over on linux-pm/-usb but
> > > couldn't find a clear consensus.
> >
> > I think none of the patches apply anymore. So they have to be redone
> > against the latest -rc4 kernel or bluetooth-testing.git.
>
> I am porting forward to Linus' tree. I thought they'd safely wait for
> the next merge window.
>
> > We had some battles with broken Bluetooth hardware that requires to keep
> > the interrupt and bulk URBs in fly, because otherwise the firmware
> > inside the controller can't sync them up and times out. These are all
> > fixed now, but nobody has looked at the auto suspend stuff. Feel free to
>
> It will have to be changed to work with those buggy devices.
> Do you have a pointer to a page describing the problem in detail?
>
> > pick Oliver's patches up and send them for review. If you do so, please
> > use [email protected] since I do miss posting on LKML from
> > time to time.
>
> Peter, are you willing to test?
Sure, I have two laptops with integrated bluetooth to test on.