Catching up with an old thread to an extent but part of the row here
appears to be missing the fact that early and late binding are both
right depending on the driver itself. It depends whether failure is
meaningful on a per operation level "record 5 seconds of video" "no" or
only can be handled
On Wed, 2002-10-16 at 02:06, David Brownell wrote:
> This is basically an early-vs-late binding policy choice. MSFT is
> doing early binding, Linux is doing late. Which is fine with me;
> the rule of thumb I'm used to is that late binding is preferable
> until there's a real problem with not havi
On Mon, Oct 14, 2002 at 12:28:17PM -0700, David Brownell wrote:
> As for the feature freeze, I think that if we get the UHCI code to
> treat interrupt transfers just like bulk (which happens to sit in
> the periodic schedule), we'll be OK. That doesn't mean no changes
> after the 20th; maybe even
Greg KH wrote:
> On Mon, Oct 14, 2002 at 10:46:31AM -0700, David Brownell wrote:
>
>>The question related to architecture is whether there needs to be
>>another reservation mode, where usb's reserved bandwidth would be
>>allocated in preparation for future use (not just for current use).
>
>
>
>>So far the only real need I've seen is to ensure that bandwidth doesn't
>>get overcommitted. And that doesn't need a new API.
>
>
> How is a device driver supposed to handle an out-of-bandwidth error?
Return an error code. That's true no matter how or when such
errors get detected. More d
David Brownell wrote:
...
> Linux drivers have so far shown no need to reserve bandwidth in advance.
> They're working just fine on the "look for an interesting hotel and ask
> for a room" strategy; room shortage hasn't been a problem in practice,
> and there's only one rate after all.
The reserv
> I see that you wanted to make the USB API as simple as possible for driver
> programmers. This is a good thing. In 2.4.x, all endpoints with reservation
> (INT and ISO) have only constant sizes. For INT OUT endpoints, this was
> not acceptable because there are devices with uses variable data
On Mon, Oct 14, 2002 at 10:46:31AM -0700, David Brownell wrote:
>
> The question related to architecture is whether there needs to be
> another reservation mode, where usb's reserved bandwidth would be
> allocated in preparation for future use (not just for current use).
I really hate to ask, bu
Hello David,
On Sunday 13 October 2002 22:04, David Brownell wrote:
> When you say it does not work, do you mean you've been sitting on a
> bug report all this while? Because I don't recall *EVER* hearing about
> any problems in the bandwidth reservation code. Not one.
Bandwidth reservation is
>>Ok, no more arguing, let's see some code, and then we can discuss
>>concrete things like that.
>
>
> Implementation isn't the source of contention. It's the overall
> architecture of how bandwidth reservation will work.
There is one issue masquerading as an implementation issue, namely
wheth
When that second driver submits its urb, assuming that needs
to reserve some bandwidth, the "is it available" logic will be
accounting for the first endpoint's bandwidth consumption.
Because it would never have been released.
>>>
>>>Yes it will be released. There are no URB'
On Sun, Oct 13, 2002 at 09:41:42PM -0400, Johannes Erdfelt wrote:
> On Sun, Oct 13, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Sun, Oct 13, 2002 at 08:55:47PM -0400, Johannes Erdfelt wrote:
> > > On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Ok, I see your
On Sun, Oct 13, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 13, 2002 at 08:55:47PM -0400, Johannes Erdfelt wrote:
> > On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > >
> > > > Ok, I see your distinction between endpoint and URB.
> > > >
> > > > It unfortunately sti
On Sun, Oct 13, 2002 at 08:55:47PM -0400, Johannes Erdfelt wrote:
> On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> >
> > > Ok, I see your distinction between endpoint and URB.
> > >
> > > It unfortunately still doesn't work.
> >
> > Oh yes it does ... :)
>
> I give up.
Now
On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > Ok, I see your distinction between endpoint and URB.
> >
> > It unfortunately still doesn't work.
>
> Oh yes it does ... :)
I give up.
> >>When that second driver submits its urb, assuming that needs
> >>to reserve some ban
> Ok, I see your distinction between endpoint and URB.
>
> It unfortunately still doesn't work.
Oh yes it does ... :)
>>When that second driver submits its urb, assuming that needs
>>to reserve some bandwidth, the "is it available" logic will be
>>accounting for the first endpoint's bandwidth
On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > Once again, this is called bandwidth reservation. Reservation means to
> > hold for one's use. It doesn't directly correlate to when it is actually
> > used. You reserve a hotel room, for instance, before you use it. It's
> > mere
On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>No, the bandwidth wouldn't have been de-allocated until after the
> >>callback returned ... and since the callback submitted an urb,
> >>it was never de-allocated. (That's the "NYET".) No failure.
> >
> > You can't do that.
> Entirely correct. Now you might want to argue that failing read due to
> insufficient bandwidth is wrong. To do that you need a way to allocate
> bandwidth without submitting an URB.
One might want to. But then I'd have to start questioning
motives of the questioner ... I don't ever recall an
> Once again, this is called bandwidth reservation. Reservation means to
> hold for one's use. It doesn't directly correlate to when it is actually
> used. You reserve a hotel room, for instance, before you use it. It's
> merely a guarantee for future usage.
Linux drivers have so far shown no nee
>>No, the bandwidth wouldn't have been de-allocated until after the
>>callback returned ... and since the callback submitted an urb,
>>it was never de-allocated. (That's the "NYET".) No failure.
>
>
> You can't do that. The HCD is done with the URB before it makes the
> callback.
Sure, but t
> > For example a webcam driver would want to claim a webcam's interfaces on
> > device connection, but it shouldn't reserve ep bandwidth until a user
> > application is ready to use the device. Then, it should reserve the
> > bandwidth for the endpoints it will use.
>
> Likewise, open() doesn't
On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > For example a webcam driver would want to claim a webcam's interfaces on
> > device connection, but it shouldn't reserve ep bandwidth until a user
> > application is ready to use the device. Then, it should reserve the
> > ban
>>>Yeah, I think interrupt URB's will vary significantly regardless. Too
>>>many limitation withs UHCI.
>>
>>Could you elaborate a bit? The functionality is there, from what
>>I've seen, and there are no code comments about particular silicon
>>quirks that might be interfering.
>
>
> Not silico
On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>>With the way it is right now, with enforcing bandwidth reservation,
> >>>there's the possibility that resubmit will fail for lack of bandwidth.
> >>
> >>In the pseudocode above, where is that possibility? I don't see it.
> >
>>Effectively you have this: claiming interfaces is opening, and
>>disconnecting from them is releasing them. The rule is that only
>>the driver that claims an interface is allowed to use its endpoints.
>
>
> That's the rule for who gets to use certain endpoints, but bandwidth
> reservation s
>>>With the way it is right now, with enforcing bandwidth reservation,
>>>there's the possibility that resubmit will fail for lack of bandwidth.
>>
>>In the pseudocode above, where is that possibility? I don't see it.
>
>
> Umm, I just described it.
>
> How about this:
I added a label for wh
On Sun, 13 Oct 2002, David Brownell wrote:
>Effectively you have this: claiming interfaces is opening, and
>disconnecting from them is releasing them. The rule is that only
>the driver that claims an interface is allowed to use its endpoints.
That's the rule for who gets to use certain endpoi
On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > Yeah, I think interrupt URB's will vary significantly regardless. Too
> > many limitation withs UHCI.
>
> Could you elaborate a bit? The functionality is there, from what
> I've seen, and there are no code comments about particu
> Yeah, I think interrupt URB's will vary significantly regardless. Too
> many limitation withs UHCI.
Could you elaborate a bit? The functionality is there, from what
I've seen, and there are no code comments about particular silicon
quirks that might be interfering.
> Which reminds me, I need
On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt wrote:
> > On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> >>%s/queued/submitted/
> >>
> >>That logic works in both interesting cases:
> >>
> >> - "one urb no queueing", as it said at the top; or
On Sun, Oct 13, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
> On Sun, 13 Oct 2002, David Brownell wrote:
>
> >Dan Streetman wrote:
> > > I have to agree with JE, there should be a common API for drivers to
> > > reserve bandwidth on a per-ep basis, and then any URBs submitted are
> > > guarant
Johannes Erdfelt wrote:
> On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
What race? What re-acquiring? With one urb and no queueing:
- driver submits urb. hcd:
* allocates bandwidth
* queues that transfer to the hc
- millions of picoseconds
On Sun, 13 Oct 2002, David Brownell wrote:
>Dan Streetman wrote:
> > I have to agree with JE, there should be a common API for drivers to
> > reserve bandwidth on a per-ep basis, and then any URBs submitted are
> > guaranteed not to fail from a shortage of bandwidth.
>
>(I didn't get such a messa
> But I *do* mind if I have to
>
> - make my own lib for queueing of control messages.
> - code around usbdefvs, which is issuing control messages at probe() time.
Are these not the same problem? You probably know that some
UHCI patches for this have been posted recently. They need
some work
On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >> > However, I don't think BW can be calculated effectively by common code, it
> >> > is dependent on the HCD.
> >>
> >>That's how it behaves already, with the different HCDs putting more
> >>or less work into their scheduling p
On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>What race? What re-acquiring? With one urb and no queueing:
> >>
> >> - driver submits urb. hcd:
> >> * allocates bandwidth
> >> * queues that transfer to the hc
> >> - millions of picoseconds pass
> >> - transfer
>> > However, I don't think BW can be calculated effectively by common code, it
>> > is dependent on the HCD.
>>
>>That's how it behaves already, with the different HCDs putting more
>>or less work into their scheduling policy.
>
>
> That's how it is done now, but since the original code was th
>>What race? What re-acquiring? With one urb and no queueing:
>>
>> - driver submits urb. hcd:
>> * allocates bandwidth
>> * queues that transfer to the hc
>> - millions of picoseconds pass
>> - transfer completes. hcd:
>> * cleans up urb-specific state
>> * gives back the
>>Since some point in the 2.3 development cycle, device drivers use the
>>common usb_submit_urb() API to request bandwidth. And that bandwidth
>>is released when that URB's endpoint is no longer active. It's a
>>simple model that works ... and should continue to work.
>
>
> It does *not* work
On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> Dan Streetman wrote:
> > I have to agree with JE, there should be a common API for drivers to
> > reserve bandwidth on a per-ep basis, and then any URBs submitted are
> > guaranteed not to fail from a shortage of bandwidth.
>
>
On Sat, Oct 12, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> >>>a) It depends on queuing
> >>>b) It doesn't reserve the bandwidth
> >>>
> >>>Each in itself make it unacceptable.
> >>
> >>On the other hand, neither of those is true either. Which is
> >>part of why I don't see any problem ...
Hello Dan,
On Sunday 13 October 2002 18:30, David Brownell wrote:
> Since some point in the 2.3 development cycle, device drivers use the
> common usb_submit_urb() API to request bandwidth. And that bandwidth
> is released when that URB's endpoint is no longer active. It's a
> simple model tha
Dan Streetman wrote:
> I have to agree with JE, there should be a common API for drivers to
> reserve bandwidth on a per-ep basis, and then any URBs submitted are
> guaranteed not to fail from a shortage of bandwidth.
(I didn't get such a message from him.)
That's no change from today, unless you
I have to agree with JE, there should be a common API for drivers to
reserve bandwidth on a per-ep basis, and then any URBs submitted are
guaranteed not to fail from a shortage of bandwidth.
However, I don't think BW can be calculated effectively by common code, it
is dependent on the HCD.
So it's a Good Thing that Linux allocates bandwidth only on demand ... :)
You mean at open() time right? :)
That's the driver's business. If they post URBs on open, that
would be how it works. If they post URBs on read/write, it'd be
a bit different.
It needs to be as early as possible
a) It depends on queuing
b) It doesn't reserve the bandwidth
Each in itself make it unacceptable.
On the other hand, neither of those is true either. Which is
part of why I don't see any problem ... :)
With a move to non automagic resubmit, the HCD *MUST* release any
bandwidth when it's done
On Sat, Oct 12, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>So it's a Good Thing that Linux allocates bandwidth only on demand ... :)
> >
> > You mean at open() time right? :)
>
> That's the driver's business. If they post URBs on open, that
> would be how it works. If they post URB
On Sat, Oct 12, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > The problem with all of this is:
> >
> > a) It depends on queuing
> > b) It doesn't reserve the bandwidth
> >
> > Each in itself make it unacceptable.
>
> On the other hand, neither of those is true either. Which is
> part o
So it's a Good Thing that Linux allocates bandwidth only on demand ... :)
You mean at open() time right? :)
That's the driver's business. If they post URBs on open, that
would be how it works. If they post URBs on read/write, it'd be
a bit different.
Seriously, the way OHCI and EHCI do
The problem with all of this is:
a) It depends on queuing
b) It doesn't reserve the bandwidth
Each in itself make it unacceptable.
On the other hand, neither of those is true either. Which is
part of why I don't see any problem ... :)
Although a per frame bandwidth measurement might not b
On Sat, Oct 12, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> Dan Streetman wrote:
> > On Fri, 11 Oct 2002, David Brownell wrote:
> >
> >>All drivers using isochronous transfers _must_ set an altsetting,
> >>since it's illegal for a default config to have ISO endpoints.
> >>That's part of the
Dan Streetman wrote:
On Fri, 11 Oct 2002, David Brownell wrote:
All drivers using isochronous transfers _must_ set an altsetting,
since it's illegal for a default config to have ISO endpoints.
That's part of the USB spec.
I have a device with iso endpoints as part of the default (only) confi
On Fri, 11 Oct 2002, David Brownell wrote:
>All drivers using isochronous transfers _must_ set an altsetting,
>since it's illegal for a default config to have ISO endpoints.
>That's part of the USB spec.
I have a device with iso endpoints as part of the default (only) config.
The iso endpoint be
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>But Randy did provide usb_calc_bus_time() ... it was exactly the
> >>right primitive, once it learned something about high speed! :)
> >>
> >>Not using those other calls because they were specific to URBs (not
> >>endpoints),
>
But Randy did provide usb_calc_bus_time() ... it was exactly the
right primitive, once it learned something about high speed! :)
Not using those other calls because they were specific to URBs (not
endpoints),
I don't see how your code is different in this respect.
Think about how it works
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> >>So was I. Both "enforcing" and "not oversubscribing" are decisions.
> >
> > Uhh, looking at the OHCI code, why is it doing that stuff itself?
> >
> > Why isn't it using the code that Randy developed?
>
> But Randy did provide u
The question now is where should we do that? The current API is specific
to URB's so it won't be as easy as just moving the calls to
urb_submit_urb or something.
What OHCI does is just update the bandwidth utilization fields directly.
Those fields are exported only for viewing in "usbfs", and a
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> The tricky bit is that the usb_{claim,release}_bandwidth() calls work
> on urbs, not endpoints. So I think those calls need to vanish, and
> HCDs need to switch to more precise math.
> >>>
> >>>Exactly.
> >>>
> >>>The qu
The tricky bit is that the usb_{claim,release}_bandwidth() calls work
on urbs, not endpoints. So I think those calls need to vanish, and
HCDs need to switch to more precise math.
Exactly.
The question now is where should we do that? The current API is specific
to URB's so it won't be as easy as
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>Reservation should be on a per-endpoint basis, for both ISO and INTR
> >>transfer modes, if we try to follow the USB spec. Dan's change makes
> >>interrupt transfers work that way ... ISO should too.
> >>
> >>The tricky bit is
Reservation should be on a per-endpoint basis, for both ISO and INTR
transfer modes, if we try to follow the USB spec. Dan's change makes
interrupt transfers work that way ... ISO should too.
The tricky bit is that the usb_{claim,release}_bandwidth() calls work
on urbs, not endpoints. So I thi
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt wrote:
> >>-move bandwidth reservation into submit_interrupt and submit_isochronous.
> >>Reserve bandwidth at start of submit_iso, and release on error. Reserve
> >>at end of submit_common (for int only, not bulk).
63 matches
Mail list logo
