Re: [PATCH 0/6] dwc-hsotg (aka dwc2) USB host contoller emulation

[Paul Zimmerman]

Thanks Gerd. I will switch over to using tracepoints, wait a few days to

see if there are any more comments, then resubmit.

Thanks,

Paul

On Mon, Mar 23, 2020 at 4:10 AM Gerd Hoffmann <address@hidden> wrote:

  Hi,

> 1) I have used printf-based debug statements while developing the
>    code, and have not implemented any tracing statements. I'm not
>    sure if that is considered acceptable for new code?

Please use tracepoints.  I'd suggest to use the "log" trace backend
which comes very close to printf-debugging; effectively all trace
points are turned into runtime-switchable printf's.

Mixing (temporary) debug printfs and tracepoints works.

> 2) I have imported the register description file from the Linux
>    kernel. This file is licensed GPL-2 only, is this OK?

Yes.  There even is a script to keep things in sync and apply some
tweaks like replacing linux kernel types with standard C types
(s/u32/uint32_t/ etc).

See scripts/update-linux-headers.sh

You might consider hooking up your file there, but probably this is
overkill given that the register descriptions are unlikely to see
frequent updates.

> 3) The emulation does not respect the max-packet size when
>    transferring packets. Since the dwc-hsotg controller only has
>    one root port, and the Qemu USB hub is only full-speed, that
>    means every device connected has to run at full speed. That
>    makes mass-storage devices in particular run very slowly. Using
>    transfers greater than max-packet size alleviates this. Is this
>    OK? I think the EHCI emulation does the same thing, since its
>    transfers seem to run at greater than real world transfer rates.

I don't think ehci uses larger packets.  I think it simply does more
transfers than physical hardware would be able to do.

uhci is pretty strict here, it counts bytes transfered and simply stops
processing queues when it has transfered enough data for the current
frame.  On the next frame timer tick it resumes work.  There is a
bandwidth= property to tweak the transfer limit, you can use that to
make uhci emulation run at the speed you want ;)

ehci and xhci simply don't count bytes and don't have a limit, they go
process queues as long as there is work to do (and they don't have to
wait for host block I/O).

> 4) I have only implemented host mode for now. Would there be any
>    benefit to implementing gadget mode as well? It seems it could
>    be useful to emulate gadget devices in Qemu, but I am not sure
>    if Qemu currently offers any support for that?

No, there isn't any gadget support yet.

cheers,
  Gerd