On Wed, Feb 13, 2002 at 06:44:40PM -0800, Jacek Pliszka wrote:
> Hi!
>
> As Linus included ALSA in 2.5.5, will it impact USB audio?
I don't know. If only I had a USB audio device to test with... :)
greg k-h
___
[EMAIL PROTECTED]
To unsubscribe, use
On Thu, Feb 14, 2002 at 02:18:54AM +0100, Martin Diehl wrote:
>
> the attached patch below addresses both problems:
>
> * usb_hub_port_debounce() provides the required debounce delay including
> the "restart delay when spurious disconnect detected" behaviour
> described in 7.1.7.1. However,
On Thu, 14 Feb 2002, Greg KH wrote:
> On Wed, Feb 13, 2002 at 06:44:40PM -0800, Jacek Pliszka wrote:
> > As Linus included ALSA in 2.5.5, will it impact USB audio?
>
> I don't know. If only I had a USB audio device to test with... :)
OK. Looks like I am going to install 2.5.5. Though this may
> > You are right. Unfortunately they _have_ accepted it.
> > Can we now be confident that no other printers will implement it
> > and put a workaround into printer.c ?
>
> While I can't comment on non-HP printers or future HP products, I can say
> that it's not safe to assume that none of them w
On Thu, 14 Feb 2002, Greg KH wrote:
> > * usb_hub_port_debounce() provides the required debounce delay including
> > the "restart delay when spurious disconnect detected" behaviour
>
> Looks good. But why aren't you restarting the timeout when you detect a
> disconnect?
> Right now it looks
On Thu, 14 Feb 2002, Martin Diehl wrote:
> However, I think there is something which could be done better: currently
> the portstatus is sampled every 10 ms and the connect _status_ is what we
> look at. Hence we might miss short transient disconnect/reconnect changes
> between the sample. I'm go
> > As Linus included ALSA in 2.5.5, will it impact USB audio?
>
> I don't know. If only I had a USB audio device to test with... :)
Shorter term - no. It'll continue as a happy co-existing OSS driver. Longer
term it may well gain from being redone to use the ALSA layers, which should
both shri
On Thu, 14 Feb 2002, Georg Acher wrote:
> On Wed, Feb 13, 2002 at 05:33:13PM -0600, Matthew Fredrickson wrote:
>
> > More data: IIRC, on the vanilla uhci.c driver, ISOC sucks. Sucks really
> > badly. Kind of funny though, 'cause I was helping somebody with writing a
> > driver for something t
On Wed, 13 Feb 2002, Johannes Erdfelt wrote:
> Yes, you *must* double buffer if you want Isochronous to be seamless.
> Isochronous transfers occur at the beginning of the frame and if you're
> scheduling for the next frame at the end of the previous, you'be already
> lost.
> Have you tried more
I just did some testing with the kernel I upgraded to a little bit ago
(2.4.17), and have some improved results. I now get basically the same
ISOC performance from both UHCI drivers (not bad, but not
perfect). However, on the usb-uhci driver, I get a little bit more debug
info. Whenever there'
On Thu, 14 Feb 2002, Matthew Fredrickson wrote:
| On Thu, 14 Feb 2002, Georg Acher wrote:
|
| > On Wed, Feb 13, 2002 at 05:33:13PM -0600, Matthew Fredrickson wrote:
| >
| > > More data: IIRC, on the vanilla uhci.c driver, ISOC sucks. Sucks really
| > > badly. Kind of funny though, 'cause I was
On Thu, 14 Feb 2002, Randy.Dunlap wrote:
> The only places that I have ever seen UHCI controllers are from
> VIA (standalone or integrated chipsets) or Intel chipsets.
>
> Did you mean that you'll try a system with an Intel chipset?
> The other option is to find one of manh OHCI controllers avail
On Thu, Feb 14, 2002 at 09:54:58AM -0600, Matthew Fredrickson wrote:
>
> I just did some testing with the kernel I upgraded to a little bit ago
> (2.4.17), and have some improved results. I now get basically the same
> ISOC performance from both UHCI drivers (not bad, but not
> perfect). Howeve
On Thu, 14 Feb 2002, Georg Acher wrote:
> On Thu, Feb 14, 2002 at 09:54:58AM -0600, Matthew Fredrickson wrote:
> >
> > I just did some testing with the kernel I upgraded to a little bit ago
> > (2.4.17), and have some improved results. I now get basically the same
> > ISOC performance from both
On Wed, 13 Feb 2002, Roland King wrote:
>The device has interrupt endpoints. I see special transfer ioctls
>for bulk, but not interrupt. I've been assuming that I need to
>submit a usbdevfs_urb and then go and reap it. Does that sound
>about right? Is there any sample code or a good example whic
> I have not as yet tested the new hcd stuff in 2.5, so that is still
> unknown for me ...
So far there's no "uhci-hcd" driver; someone has to create one
from "uhci" or "usb-uhci". That should help resolve the "which
UHCI driver" dilemma ... dropping the other two! :)
What I'd expect is that c
I'm pleased I asked now. I had no idea that you could even submit a bulk URB to an
interrupt endpoint. I would have submitted an INT one and then probably fallen foul of
the very code you mention.
Perhaps that needs patching, so that the devfs code ensures that the urb is cancelled
before ret
I'm pleased I asked now. I had no idea that you could even submit a bulk URB to an
interrupt endpoint. I would have submitted an INT one and then probably fallen foul of
the very code you mention.
Perhaps that needs patching, so that the devfs code ensures that the urb is cancelled
before ret
> It's odd that the two types of hardware treat the interrupt case where
> interval == 0 differently. Is either of them wrong by the specification
> or are they both right?
My take is that the interval==0 behavior is a UHCI driver behavior
that should not be relied on. Magic values like that ar
On Thu, Feb 14, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > It's odd that the two types of hardware treat the interrupt case where
> > interval == 0 differently. Is either of them wrong by the specification
> > or are they both right?
>
> My take is that the interval==0 behavior is a UHC
Right - that sounds like a good plan for a real driver. Using the usbdevfs code
however, if you call proc_reapurb() the completed request is freed before the call
returns to you, so there is still a chance the
urb will interrupt again before you get to cancel it.
since usbdevfs always frees th
Oliver Neukum wrote:
> > > You are right. Unfortunately they _have_ accepted it.
> > > Can we now be confident that no other printers will implement it
> > > and put a workaround into printer.c ?
> >
> > While I can't comment on non-HP printers or future HP products, I can say
> > that it's not sa
The usb(dev)fs code should "do the right thing" and act
just like any other driver ... right now its interrupt handling
code is UHCI-specific.
- Dave
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 14, 2002 11:43 AM
Subject: Re: [linux-usb
> > And what do we do if somebody makes a printer that accepts only 1284.4 ?
>
> If the peripheral only advertises 7/1/3, then printer.c has no choice
> but to bind to it, which is the behaviour with the existing version as
> well as my modified version. This is the case today with the HP Office
On Thu, Feb 14, 2002 at 11:18:57AM +0100, Martin Diehl wrote:
>
> +static int usb_hub_port_status(struct usb_device *hub, int port,
> +unsigned short *status, unsigned short *change)
status and change should both be u16 types, right?
> +{
> + struct usb_port_sta
> > The portable way to get a one-shot interrupt transfer should be
> > to submit the transfer as usual (real period) then unlink it in the
> > completion handler for that transfer.
>
> That won't work with uhci.o or usb-uhci.o. You can't unlink a
> resubmitting interrupt urb in the completion ha
> > +/* return: -1 on error, 0 on success, 1 on disconnect. */
>
> As no one is checking for the return value of 1, and a disconnect is
> still an error, shouldn't the code be the following:
Not an error, and it's tested. That's a patch that was inappropriately
dropped sometime after 2.4.12 ...
Hmm, I'm a bit concerned that this code is going to interact
with handing off devices from EHCI to a companion controller.
Somewhere between 2.4.12 and 2.4.17 an important pair of
lines got removed from hub.c usb_hub_port_wait_reset(),
returning disconnect status when the root hub port reset ends
On Thu, Feb 14, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > The portable way to get a one-shot interrupt transfer should be
> > > to submit the transfer as usual (real period) then unlink it in the
> > > completion handler for that transfer.
> >
> > That won't work with uhci.o or usb-uh
29 matches
Mail list logo
