[haiku-development] Re: Usage change proposal for queue_isochronous( ..., startingFrameNumber, .... )

  • From: Paul Davey <plmdvy@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 16 Jul 2013 22:13:17 +1200

Hi Siarzhuk,

I am not really well versed with the USB kit or the kernel, but I
would suggest that from your description the parameter be named more
like nextFrameNumber or something.

Paul

On Tue, Jul 16, 2013 at 7:28 PM, Siarzhuk Zharski <zharik@xxxxxx> wrote:
> Hi, it's me again...
>
> Siarzhuk Zharski писал 03.07.2013 12:35:
>
>> But all becomes
>> much easier if we agree to return the frame number that is just after
>> the end of ones scheduled for the transfer.
>
> [...]
>
>> The startingFrameNumber plays in this case as really opaque,
>> cookie-like variable.
>>
>> In pseudo-code:
>>
>> uint32 frame = 0;
>> queue_isochronous(..., &frame, USB_IO_ASAP, ....);
>>
>> while (...) {
>>   queue_isochronous(..., &frame, 0, ....);
>> }
>>
>> The first call allocates at next available frame with enough bandwidth
>> and the following ones will schedule data without overlaps and gaps.
>>
>> So, what do you think about proposed USB bus modules design modification?
>
>
> Well, silence gives consent. Neither drivers nor USBkit are using this
> startFrameNumber value anyway so I feel free to optimize this logic in
> proposed way.
>
> --
> Kind Regards,
>    S.Zharski
>

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 07-2013