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 <kra...@redhat.com> 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 > >
