On Wed, Jun 12, 2019 at 03:55:59PM +0200, Alexandre Ratchov wrote:
> Currenty USB device driver code has no way to obtain how many frames
> can be scheduled on the HC. If it attempts to schedule too many
> frames, usbd_transfer() fails or silently misbehaves.
>
> For audio this is a big problem because the max frames count
> determines the block size which must be reported to upper layers
> before any transfer starts. This makes impossible to implement uaudio
> properly. Currently there's a temporary hack to workaround this, which
> limits the block size. Now that uaudio is in and works, it's time to
> start removing such hacks.
>
> Similarly, driver code needs to know the minimum number of frames per
> transfer to get an interrupt (ie the completion callback). Indeed, if
> the transfer frame count is not rounded to it, we silently miss the
> interrupt, the completion call-back is not called and playback
> stutters.
>
> The diff below adds a new usbd_bus_info() function which reports the
> maximum frames that can be scheduled and the minimum frames per
> transfer to get an interrupt.
>
> [snip]
> Index: usbdi.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
> retrieving revision 1.100
> diff -u -p -u -p -r1.100 usbdi.c
> --- usbdi.c 18 Nov 2018 16:33:26 -0000 1.100
> +++ usbdi.c 12 Jun 2019 13:33:41 -0000
> @@ -275,6 +275,12 @@ usbd_close_pipe(struct usbd_pipe *pipe)
> return (USBD_NORMAL_COMPLETION);
> }
>
> +void
> +usbd_bus_info(struct usbd_device *dev, struct usbd_bus_info *info)
> +{
> + dev->bus->methods->info(dev, info);
> +}
> +
> usbd_status
> usbd_transfer(struct usbd_xfer *xfer)
> {
> [snip]
i think above is not good enough with only ehci, ohci, uhci and xhci
being taken care of in [snip]'ed parts of the diff unfortunately:]
just thinking about dwc2.
-Artturi
