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?
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");
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.
> I agree, that whole isoc support needs proper improvement.
>
> I could/should have added RFC to the patch. As the whole intention of
> this code, for now, is to validate the gadget/uvc configfs patchseries
> mentioned in the the comments.
>
> With this patch, it is at least possible to get the gadget running on
> dummy_hcd and try out the "non-isoc dependent" parts, that are actually
> changed, in the mentioned series.
>
> The validation of the payload path, actually using the mentioned isoc
> endpoints, is left to the developer who implements the missing parts
> you mentioned above.
>
> Michael
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
