Vojtech Pavlik wrote:
> On Sat, Jun 01, 2002 at 01:02:23PM +0300, Johann Deneux wrote:
>
>>Vojtech Pavlik wrote:
>>
>>>On Mon, May 27, 2002 at 01:17:58PM +0200, Johann Deneux wrote:
>>>
>>>
Johannes Erdfelt wrote:
>I can only see 2 reasons for putting it into the HCD: OHCI
On Sat, Jun 01, 2002 at 01:03:55PM +0200, Vojtech Pavlik wrote:
> On Sat, Jun 01, 2002 at 01:02:23PM +0300, Johann Deneux wrote:
> > Vojtech Pavlik wrote:
> > > On Mon, May 27, 2002 at 01:17:58PM +0200, Johann Deneux wrote:
> > >
> > >>Johannes Erdfelt wrote:
> > >>
> > >>
> > >>>
> > >>>I can on
On Sat, Jun 01, 2002 at 01:02:23PM +0300, Johann Deneux wrote:
> Vojtech Pavlik wrote:
> > On Mon, May 27, 2002 at 01:17:58PM +0200, Johann Deneux wrote:
> >
> >>Johannes Erdfelt wrote:
> >>
> >>
> >>>
> >>>I can only see 2 reasons for putting it into the HCD: OHCI and EHCI
> >>>handle it implici
Vojtech Pavlik wrote:
> On Mon, May 27, 2002 at 01:17:58PM +0200, Johann Deneux wrote:
>
>>Johannes Erdfelt wrote:
>>
>>
>>>
>>>I can only see 2 reasons for putting it into the HCD: OHCI and EHCI
>>>handle it implicitily and for speed.
>>>
>>>There is a strong desire to keep bulk fast, but I can'
On Mon, May 27, 2002 at 01:17:58PM +0200, Johann Deneux wrote:
> Johannes Erdfelt wrote:
>
> >
> >
> > I can only see 2 reasons for putting it into the HCD: OHCI and EHCI
> > handle it implicitily and for speed.
> >
> > There is a strong desire to keep bulk fast, but I can't come up with a
> >
On Wed, May 29, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > I think queueing in the USB core is the best thing, not in the HCD or
> > the hcd.c code (this after staring at the Cypress HCD that was released
> > last week...)
>
> That was another lurking argument: "what about the drivers
> I think queueing in the USB core is the best thing, not in the HCD or
> the hcd.c code (this after staring at the Cypress HCD that was released
> last week...)
That was another lurking argument: "what about the drivers other
than {E,O,U}HCI?"
I still strongly believe that for drivers that do
Really, the 'cat /proc/bus/usb/devices' issue is two-fold. It's both a
locking issue and a queueing issue.
Any solution we implement really should address both aspects.
Matt
On Tue, May 28, 2002 at 10:40:36AM -0700, Greg KH wrote:
> On Sat, May 25, 2002 at 05:53:21PM -0400, Johannes Erdfelt wr
On Sat, May 25, 2002 at 05:53:21PM -0400, Johannes Erdfelt wrote:
> On Sat, May 25, 2002, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > There's the much discussed USB storage bulk/control problem
> > > which is a slightly different, but still related locking issue.
> >
> > Can you tell me al
> How about we require driver level locking for interface level control
> requests?
How would that be enforced?
> Like if you want to disable a port, you are required to do it through
> the hub driver (in some other way we haven't defined yet). That we way
> ensure coherency with any loaded dri
On Mon, May 27, 2002 at 01:17:58PM +0200, Johann Deneux wrote:
> Johannes Erdfelt wrote:
> >I can only see 2 reasons for putting it into the HCD: OHCI and EHCI
> >handle it implicitily and for speed.
> >
> >There is a strong desire to keep bulk fast, but I can't come up with a
> >reason for contro
Johannes Erdfelt wrote:
>
>
> I can only see 2 reasons for putting it into the HCD: OHCI and EHCI
> handle it implicitily and for speed.
>
> There is a strong desire to keep bulk fast, but I can't come up with a
> reason for control to be faster.
>
It depends on what you mean by fast. I am t
Will do. Right now I'm fighting with BK to do what I want. I have to say,
this thing (BK) could use some more documentation.
For example, do a 'bk edit ', then remove the file, then try to do a
'bk get '. You get a wonderfully cryptic error, with no indication
of how the hell you should fix th
> Some devices are even more delicate than that,
> hence the customized clear_halt code in usb-storage.
Yes. Could you perhaps add a comment in transport.c?
Right now it says something like
"some devices crash their internal firmware
when the status is requested after a halt"
but "some devices"
No, it's not in the specs. But it's in the field. Some devices are even
more delicate than that, hence the customized clear_halt code in
usb-storage.
Matt
On Sat, May 25, 2002 at 05:53:21PM -0400, Johannes Erdfelt wrote:
> On Sat, May 25, 2002, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
On Sat, May 25, 2002, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > There's the much discussed USB storage bulk/control problem
> > which is a slightly different, but still related locking issue.
>
> Can you tell me all about it? Or give pointers?
>
> [2.5.18 hangs, 2.5.18 with 2.5.15 usr/sto
> There's the much discussed USB storage bulk/control problem
> which is a slightly different, but still related locking issue.
Can you tell me all about it? Or give pointers?
[2.5.18 hangs, 2.5.18 with 2.5.15 usr/storage fails with uhci
but works with alternate uhci; it smells a bit like a lock
On Sat, May 25, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> >>>usb_control_msg() is probably what he wants. It waits.
> >>
> >>Yes. But still we should probably have control queueing for
> >>the uhci's (possibly at the HCD level?)
>
> Queuing in the HCD seems most natural to me, in part bec
Thomas Sailer wrote:
> Yes. But still we should probably have control queueing for
> the uhci's (possibly at the HCD level?)
Yes!
You will also need it if you have to send control requests from interrupt
context.
best regards
Wolfgang
_
>>>usb_control_msg() is probably what he wants. It waits.
>>
>>Yes. But still we should probably have control queueing for
>>the uhci's (possibly at the HCD level?)
Queuing in the HCD seems most natural to me, in part because
all HCDs do it already for bulk and iso transfers ... and since
control
On Fri, May 24, 2002, Thomas Sailer <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt wrote:
>
> > usb_control_msg() is probably what he wants. It waits.
>
> Yes. But still we should probably have control queueing for
> the uhci's (possibly at the HCD level?)
>
> Think about multi-interface devices
Johannes Erdfelt wrote:
> usb_control_msg() is probably what he wants. It waits.
Yes. But still we should probably have control queueing for
the uhci's (possibly at the HCD level?)
Think about multi-interface devices, where all interfaces have
different drivers that do not know about each other
On Fri, May 24, 2002, Martin Diehl <[EMAIL PROTECTED]> wrote:
> On Fri, 24 May 2002, Thomas Wahrenbruch wrote:
>
> > some Control URBs to the converter. Sending one Control URB works fine.
> > But if I want to send more than one Control URB, I have to wait for the
> > completion hanlder to finish
On Fri, 24 May 2002, Thomas Wahrenbruch wrote:
> some Control URBs to the converter. Sending one Control URB works fine.
> But if I want to send more than one Control URB, I have to wait for the
> completion hanlder to finish, before I can send the next URB. (Please
> correct me, if I'm wrong) I
Thomas Wahrenbruch wrote:
> Hi all,
>
> I'm writing a driver for our (custom-made) USB-serial converter using
> the usb_serial module. In order to setup the converter I have to send
> some Control URBs to the converter. Sending one Control URB works fine.
> But if I want to send more than one Con
Hi all,
I'm writing a driver for our (custom-made) USB-serial converter using
the usb_serial module. In order to setup the converter I have to send
some Control URBs to the converter. Sending one Control URB works fine.
But if I want to send more than one Control URB, I have to wait for the
compl
26 matches
Mail list logo
