On Mon, Jan 31, 2022 at 12:08:20PM +0000, Kieran Bingham wrote:
> Hi Michael, Alan,
>
> Quoting Michael Grzeschik (2022-01-26 18:31:38)
> > On Wed, Jan 26, 2022 at 11:09:23AM -0500, Alan Stern wrote:
> > >On Wed, Jan 26, 2022 at 02:22:49PM +0100, Michael Grzeschik wrote:
> > >> With this patch, the dummy_hcd gains first support for isoc transfers.
> > >> It will complete the whole urb with all packages.
> > >
> > >"packets", not "packages".
> >
> > Right.
> >
> > >> Even if the gadget
> > >> side did not enqueue any request, the urb will be handled.
> > >>
> > >> Signed-off-by: Michael Grzeschik <m.grzeschik@xxxxxxxxxxxxxx>
> > >
> > >I don't like this idea. If support for isochronous transfers is added,
> > >it should be done correctly. That is, the implementation should support
> > >scheduling of transfers, periodic bandwidth reservation, high-bandwidth
> > >transfers, and so on.
> > >
> > >The whole point of dummy-hcd is to emulate a real host controller as
> > >closely as possible. Real isochronous transfers do not complete all at
> > >once.
>
> Being able to at least test uvc-gadget in a virtual environment would
> already be a big benefit. As this is emulation, not simulation is it
> essential that an exact mapping of the hardware is in place?
It doesn't have to be exact, but it should be close enough to test the
essential aspects of isochronous transfers. In particular, people will
need to be able to test the timing aspects -- they are a big part of the
isochronous mechanism.
> Is there anything we can do to support the progression of this
> development?
>
> I.e. could we support this method first with a
> WARN_ONCE("This does not fully emulate Isochronous support");
No, as Greg said, don't do that.
Improve the emulation in the patch so that it does do proper scheduling
for isochronous transfers. You don't have to worry about all the
aspects of this -- for example, since dummy-hcd supports only one device
at a time, it should be okay to leave out checks for overcommitting
periodic transfer times during a frame or microframe. (dummy-hcd
doesn't currently do that sort of check for interrupt transfers.) But
the emulation should be sufficiently realistic to return -EXDEV errors
for URBs or packets that were submitted too late.
Alternatively, you can simply keep the patch that Michael submitted as
an out-of-tree resource for people who want to test uvc-gadget.
> That would allow infrastructure to be built up that uses this
> functionality, which would then in turn feed back into providing a means
> to actually test the improvements to the isochronous support on top.
Without realistic timing emulation, the tests would be only minimally
useful.
Alan Stern
