Hi Michael, thanks for the prompt reply! On Mon, Sep 26, 2022 at 10:15:41PM +0200, Michael Grzeschik wrote: > Hi Dan! > > On Mon, Sep 26, 2022 at 02:53:06PM -0500, Dan Vacura wrote: > > > > Hello uvc gadget developers, > > > > I'm working on a 5.15.41 based kernel on a qcom chipset with the dwc3 > > controller and I'm encountering two problems related to the recent performance > > improvement changes: > > What's about that odd kernel number. UVC is under heavy development, if > you plan to work with this code, you should probably test top of tree. Yes, it's a bit behind and it looks like some of the initial work you did for scatter/gather got pulled into the 5.15 tree, but subsequent changes didn't. I don't have much control over the kernel versioning as we're part of the GKI Android initiative: https://source.android.com/docs/core/architecture/kernel/generic-kernel-image and we can only work off of what is provided, like this release line: https://android.googlesource.com/kernel/common/+log/refs/heads/android13-5.15 Perhaps we can revert these changes for the 5.15 kernel (and other versions) they were not intended for? > > > https://patchwork.kernel.org/project/linux-usb/patch/20210628155311.16762-5-m.grzeschik@xxxxxxxxxxxxxx/ and > > https://patchwork.kernel.org/project/linux-usb/patch/20210628155311.16762-6-m.grzeschik@xxxxxxxxxxxxxx/ > > > > If I revert these two changes, then I have much improved stability and a > > transmission problem I'm seeing is gone. Has there been any success from > > others on 5.15 with this uvc improvement and any recommendations for my > > current problems? Those being: > > > > 1) a smmu panic, snippet here: > > > > <3>[ 718.314900][ T803] arm-smmu 15000000.apps-smmu: Unhandled arm-smmu context fault from a600000.dwc3! > > <3>[ 718.314994][ T803] arm-smmu 15000000.apps-smmu: FAR = 0x00000000efe60800 > > <3>[ 718.315023][ T803] arm-smmu 15000000.apps-smmu: PAR = 0x0000000000000000 > > <3>[ 718.315048][ T803] arm-smmu 15000000.apps-smmu: FSR = 0x40000402 [TF R SS ] > > <3>[ 718.315074][ T803] arm-smmu 15000000.apps-smmu: FSYNR0 = 0x5f0003 > > <3>[ 718.315096][ T803] arm-smmu 15000000.apps-smmu: FSYNR1 = 0xaa02 > > <3>[ 718.315117][ T803] arm-smmu 15000000.apps-smmu: context bank# = 0x1b > > <3>[ 718.315141][ T803] arm-smmu 15000000.apps-smmu: TTBR0 = 0x001b0000c2a92000 > > <3>[ 718.315165][ T803] arm-smmu 15000000.apps-smmu: TTBR1 = 0x001b000000000000 > > <3>[ 718.315192][ T803] arm-smmu 15000000.apps-smmu: SCTLR = 0x0a5f00e7 ACTLR = 0x00000003 > > <3>[ 718.315245][ T803] arm-smmu 15000000.apps-smmu: CBAR = 0x0001f300 > > <3>[ 718.315274][ T803] arm-smmu 15000000.apps-smmu: MAIR0 = 0xf404ff44 MAIR1 = 0x0000efe4 > > <3>[ 718.315297][ T803] arm-smmu 15000000.apps-smmu: SID = 0x40 > > <3>[ 718.315318][ T803] arm-smmu 15000000.apps-smmu: Client info: BID=0x5, PID=0xa, MID=0x2 > > <3>[ 718.315377][ T803] arm-smmu 15000000.apps-smmu: soft iova-to-phys=0x0000000000000000 > > > > I can reduce this panic with the proposed patch, but it still happens until I > > disable the "req->no_interrupt = 1" logic. > > > > 2) The frame is not fully transmitted in dwc3 with sg support enabled. > > > > There seems to be a mapping limit I'm seeing where only the roughly first > > 70% of the total frame is sent. Interestingly, if I allocate a larger > > size for the buffer upfront, in uvc_queue_setup(), like sizes[0] = > > video->imagesize * 3. Then the issue rarely happens. For example, when I > > do YUYV I see green, uninitialized data, at the bottom part of the > > frame. If I do MJPG with smaller filled sizes, the transmission is fine. > > > > +-------------------------+ > > | | > > | | > > | | > > | Good data | > > | | > > | | > > | | > > +-------------------------+ > > |xxxxxxxxxxxxxxxxxxxxxxxxx| > > |xxxx Bad data xxxxxxxxx| > > |xxxxxxxxxxxxxxxxxxxxxxxxx| > > +-------------------------+ > > > > > > Appreciate any thoughts or feedback related to these issues. > > Anyway, this is probably due to the frames being given back to early to > the frameproducer. We have the following patches mainline now to fix this issue: > > aef11279888c00e1841a3533a35d279285af3a51 usb: gadget: uvc: improve sg exit condition > 9b969f93bcef9b3d9e92f1810e22bbd6c344a0e5 usb: gadget: uvc: giveback vb2 buffer on req complete Yes, I did grab those in addition to some other necessary changes, noted in my patch here: https://patchwork.kernel.org/project/linux-usb/patch/20220926195307.110121-2-w36195@xxxxxxxxxxxx/ I also pulled a lot of patches from the dwc3 to be almost at parity with top of tree for the core.c/h, ep0.c/h, and gadget.c/h files, but these issues persisted. Out of curiosity, have you tested these changes with dwc3 and if so, have you tried "usb: gadget: uvc: decrease the interrupt load to a quarter" with scatter/gather disabled? For me the crash occurs more often. Thanks, Dan > > You might need some patches beforehand to get them applied on your > stack. > > Regards, > 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 |
