Message ID | ZTvhEl+JcnhJXcrl@lizhi-Precision-Tower-5810 |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:d641:0:b0:403:3b70:6f57 with SMTP id cy1csp717435vqb; Fri, 27 Oct 2023 09:11:54 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHOV4g6EkvRnCnwCBnAd4/wyJnM+hkJ7oglcAjY5wP3pCnkiRFVmONKDXtCICMZM9l/aBTt X-Received: by 2002:a05:6808:1412:b0:3af:6595:e53 with SMTP id w18-20020a056808141200b003af65950e53mr3713554oiv.13.1698423114460; Fri, 27 Oct 2023 09:11:54 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1698423114; cv=pass; d=google.com; s=arc-20160816; b=uHXhwurAMzJd4v4Kg1RfKguhzT/Hw8p+bAzCpGELBkEs+zlGl0FT+0U/TpIcjZtfHT tmb7GJsUzWCxE7f97lvwR9esooxOj7QEdXuLFfaJEGAb7X/B4hCNOPCesW/bdKENYxFP yXFR1iaIV0cMDj94yvEpFvKEDpaimBfccPZvVgf/LyuiKPoXzHS8X2z0sB3+5ch9Cyn+ WkUNlDNAQoPXwgux9xB5/2TEINmgGWWwKKgybhD2+LveAbaEsBI/rYdWSppIn/J7apGJ OOVm1mvQtHQnXu3V3hiOlhCKO0Y7aC2/1n3lZc86saHTUtakgPIwXOwwfRfwrPKYTrqw me3w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-disposition:message-id :subject:to:from:date:dkim-signature; bh=fWXw4SvB6tHPZ7CSptVCnZLmNA8+hdDH/Z2BcGnqMPA=; fh=KFAfoWynIDweazu/D5CFlOi7F68GBwuUYcchyuoqwgY=; b=d4Zq1ur4fhCZ+mhFqss/O9J8HX12wqKOq4B7SwujaVaoxTwg/hLvToR+0Ij9xqbQQv oynRbtXJiGLn9RrEV65VWu4i/umx4VMFx/VPNh6PcXpY6HR8KT4qmDh8rqkH7Db+1MwU pfv3UPETU+nwWzqaFrcWNlDMWYnbp9fKbJOL3c1BlPwNi8qWTxFeQRMRk/+XmYoSRXA3 xFUZbEfL5ukPeKqfxuCew0/nPCZLcr8NDam0t996HWszsodj+yNJsfkZUh5yng3v09vf mzQR8T/ScB+6QqITbippI4OnwHofuPqh+hwFHQ2HGjAEFwpdTNagyFuUO2dfgY+pnWeQ L5ZQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@nxp.com header.s=selector2 header.b=QoSukLAO; arc=pass (i=1 spf=pass spfdomain=nxp.com dkim=pass dkdomain=nxp.com dmarc=pass fromdomain=nxp.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id 125-20020a251383000000b00d7bb3453cf2si2870025ybt.178.2023.10.27.09.11.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Oct 2023 09:11:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@nxp.com header.s=selector2 header.b=QoSukLAO; arc=pass (i=1 spf=pass spfdomain=nxp.com dkim=pass dkdomain=nxp.com dmarc=pass fromdomain=nxp.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id A648980206D7; Fri, 27 Oct 2023 09:11:34 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231785AbjJ0QLO (ORCPT <rfc822;a1648639935@gmail.com> + 25 others); Fri, 27 Oct 2023 12:11:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230440AbjJ0QLM (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 27 Oct 2023 12:11:12 -0400 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2085.outbound.protection.outlook.com [40.107.20.85]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA2161AA; Fri, 27 Oct 2023 09:11:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dUFbhibYywzVw5OShReH70fCvAbc/9LTf27TEq2jwD2VAhf5Q6XtrZFdnBCOlPzRn2IvChqyWbppipA7Am9ZZ3GNX00PKgKkKsgVDAaMj+FOy0E7+yNC8isdiUhUxc8bIhJ427FC+A3irA0T+jgyOcMtEHUbJA3n7W5rOwBRzUIEQIqAM5FmmRS83cmGJnd9lmo82zjaVMVrQvHyr+b8ij+waLyFGQ8X2XX2gcB90xmA7HULf/5pABKvpARJevtoPashHXhmsdcZHmug+Tk7v4/ZW8Jaq+ozopnzL3Ut5nrxmrCLsj5qyFJDVuEvsUVAKttiaSxhIXmRxONShHVkmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fWXw4SvB6tHPZ7CSptVCnZLmNA8+hdDH/Z2BcGnqMPA=; b=f4Xwddu13Ykdr6j91Lfc8HDCl39a2Dc/xkIZLfSKbMldY1GFSaS2lJw9K0dawUmstFB4EbcoWAtU8jGcLbbPkKaTCuc6aaUq769S5wLwMd1fStqEnsZBE/X44l348VjV4ebTg37oO4fMvN6QYFbhCQC4Hbu7mEXDop+98cXoF2uWl/A9VxDHTeOcl6FnFkIilU5PasEFwXOiu8h2PKaVHWImoijBf8TRjQEpJpUz9+ID8K3hB7ayoEryFrnV9/diTGKiOOZGQLU89sE1Apgl/kvBzsYH6FrvENK7uMNumfHi7fEFksqGtwLjmAEezQduvF/m+ISjzYV73hW6yHHiug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fWXw4SvB6tHPZ7CSptVCnZLmNA8+hdDH/Z2BcGnqMPA=; b=QoSukLAO20qgb/7HzM6gziY8mVbaOh9vuarX+oAvmimVzYjwHRaXc0trTup+aBGfHBu6CJ4arZeyPxOUER+JEKaSCgRhvPusbTHWKOhW40R6oKJrFQ9g33z41iTDAqloDv30yQkmwkEV+0XGO6d0k03PRTj80CiGAP4A+belxmo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nxp.com; Received: from AM6PR04MB4838.eurprd04.prod.outlook.com (2603:10a6:20b:4::16) by PAXPR04MB9326.eurprd04.prod.outlook.com (2603:10a6:102:2b8::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6933.8; Fri, 27 Oct 2023 16:11:06 +0000 Received: from AM6PR04MB4838.eurprd04.prod.outlook.com ([fe80::97ca:a905:8e64:c098]) by AM6PR04MB4838.eurprd04.prod.outlook.com ([fe80::97ca:a905:8e64:c098%6]) with mapi id 15.20.6933.011; Fri, 27 Oct 2023 16:11:06 +0000 Date: Fri, 27 Oct 2023 12:10:58 -0400 From: Frank Li <Frank.li@nxp.com> To: pawell@cadence.com, peter.chen@kernel.org, rogerq@kernel.org, a-govindraju@ti.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, imx@lists.linux.dev Subject: cdns3 uvc first ISO parkage lost problem Message-ID: <ZTvhEl+JcnhJXcrl@lizhi-Precision-Tower-5810> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-ClientProxiedBy: SJ0PR13CA0044.namprd13.prod.outlook.com (2603:10b6:a03:2c2::19) To AM6PR04MB4838.eurprd04.prod.outlook.com (2603:10a6:20b:4::16) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM6PR04MB4838:EE_|PAXPR04MB9326:EE_ X-MS-Office365-Filtering-Correlation-Id: 327b96b6-5762-4c6d-f11c-08dbd70752f8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: v7bi1/dy50Eif5feuoD3wDVaPJb5QEqG53PtyTRXIY9O34dy80odt6noe8gZbTBkdmA7hmnNShkQCkZHErZ+nARvyhsK1gK6gRccSxNKNo4/fXkCSJSDfI5fw+4Ou5FXnOltzI3Y9sXeCTMIWKDVy/0vSxudmyMuojuFSGmEdTE9m3cmuRZFNa+FnWhz5vVn6I7BUnxLnVOl3V69HSIowG0WmKtzShmYJ2Y88r3bzF4w+5oPvUGdopbARQmj5bMad8zRi1sGFVi/hucpj/yjWcCoZRTrLv+UcMEOLgKPbp82p2AW02IsAqEOmSky2dOt3qvKyxnycagHVd+yBMzYWAWc1RddYga+6rj/qz0v2xFPmpdK/JXCtqxmw9W3xtQb5qe6pPFmUm1YSBCkK2NJoFxWsNZxXF6JESchg8UtQqDbJvjrqaY3kD5uFjwAoW9oSJTuR00fH3ukitrQ6QBheDTZTkPcBpi/E6X1LNfkNUpFDk4f7h/HcNhYgR7fSu63u4sxBeljqKQFpnmFfOR8AiSYqvKBrpyXvUqov0xovVIZHaQfiMoYnI83nUInbIhzrfceP3U2xLvKFXAtSolSkqt29corzSdWVBh8nJLukjYBA8R3u2adVUG9xhhwsnNW X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM6PR04MB4838.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(7916004)(396003)(376002)(39860400002)(366004)(136003)(346002)(230922051799003)(1800799009)(186009)(451199024)(64100799003)(316002)(66946007)(2906002)(966005)(52116002)(6666004)(8676002)(86362001)(6512007)(8936002)(41300700001)(38350700005)(66556008)(26005)(66476007)(33716001)(6486002)(9686003)(6506007)(478600001)(5660300002)(38100700002)(83380400001)(67856001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: LQTK+xcWpO2yNiQC/FiYXXcTH0epYtWazlNaT5mesuYoWtv4FjfN39B+KZmmpj7/9IA3wmO2h/u7DEhPTxLU8nTW4CWOeHArc2umStc11/nJCd2+8Q/zmkCInv5wqj7RfMWDfC2mV4b0vCheOWXu3Wu4TKKl2VoRKIjkKzQJxbNZ9cq3G2ymkBVHPiZOmxOFOOJyfW4VTrsGNqtOVw/bw4rF29Ba0Wk9gq01HOhfWeuKXJ0F2GB1yKf4/yiD/dBachiA2nQg3A7bfKXL01Vjy8oDIho0Nv6WnGGNu64JogY3pYN6pWgH646JTHWRVowbjZRNWSWFWYy6wWKQsoyJEHxmTXEfOqWka8Dk8ATgQYP9AEHV5a1kLb9rfnuiEugTl/d/tjzIlcoK4ikZENNLeAhPS8lUopvjl0+kCm79TZlS6jyayzpZfZH9l4f0elizxU7vsJdRjKfqW+Q6rPb8+7wsRrMcHmIfpwpCLVIq69WhfvdTGLK9jSvjc/2l5W65YdETHupbiVs6LSdlLNrm2pPa/w3ToC1UDx4VSatQzkzCWVEjw1B6hdcZ4rlX54gyM7b72ky1BmV41svlwNUIW2jzPxn0jUQJefs0FnF1K8aQdhABdHCbcZ+o864pDQpp27nOIDM3lGxZzNIIU46Hdqbeh9hkJh9Lkh0CVYDg6Gsxc4NezaRZQEqQDnh6e0hT8xOe9zd01/LpAu9Q9Tz8+RWm8nNycWAa9L3+jjFZjQMQY0fJM5urYxxLgOosgRaMJGAnxg5t8AREG/taatE6jE/+jvZ+qy95rqh3S4+qxEo1JBPzaGK4p3U9uX6cMziD2uYXgUh5C15UkQO2BFeyBi73blaALoA/Jjn9JS52se1ZHw889TcPiQimmHNFth7qGH+H8mnhgZ9sQx+ybi75dow7A0Y5QTJBdE0Z7kuR6eh+mm+gLEaSn8vvnSLrgCTvNLCd3sJ+zTa1DVN7tzZ3j8Em6w3nT2SVPYwyJz6rPdt5eRDaTrHP2wu8GUZ6m8l927Ug0q/4FIEJusP1sen9xxe5tbQw4KZGK8+kNNXfrZ+QjO9NFqrTSOTjZVF8FUK9AQcaTll6/EYCuKUXkCX85xsp+aXRFH6CQU5e3WDroBft6eQ7ML0WCwsBpmGJJ1B+SWWvLgNQ1lFqkEKnx1RzJ1Sq5yQ+K0pU3yLwp7xINVX6qW9FyhOrHjkDGFt27rJMLvTAGl3lFfqwsiVhMdLWs5FuI6ZCMRaU/PjRk8oZRbb/E4OIF91dLVRIhzeeOMUsVypLGwR8WOwG9pDW8jYxWp/BI0U95xayQ7tg9CDrnrNjKYl9bLmtrGAAoT/zPafIQIY+9Trjj/JemmaBh8tebc1G1qFXFXgLxQcKqUEeaszeqry0B+o/OOTSyESButN76smRSuPhRa3oNm0LV2k+90tSzdwQVFkV5I2IsbRctMbTE5wDMqUu4XKvkni8tH5HlSnpX6xVVMeV5ljHDFM0weLTopaZSbPvcDfZwnZrDKpKti+vAo2eqNuL1OOzHWXgM+X1pISjwv9LH2bGJCvU1tZsTQWv4UGki68upM6akMvWXgy+E7RAVVWkSyl0Yw6O X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 327b96b6-5762-4c6d-f11c-08dbd70752f8 X-MS-Exchange-CrossTenant-AuthSource: AM6PR04MB4838.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2023 16:11:06.2862 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: SCqrDArIzRXd2AA3RTNfWwTp6Bpr7LHsYLH+3xDQzUnErpk0fPA72ClWtA5+tb8wT6nik2XWczQMZhMh/2xCpw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR04MB9326 X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Fri, 27 Oct 2023 09:11:34 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780925715165276373 X-GMAIL-MSGID: 1780925715165276373 |
Series |
cdns3 uvc first ISO parkage lost problem
|
|
Commit Message
Frank Li
Oct. 27, 2023, 4:10 p.m. UTC
hi Pawel Laszczak Recently, I met the problem when use uvc. UVC report jpg header error. Basic reproduce steps. Gadget side: 1 - https://gist.github.com/kbingham/c39c4cc7c20882a104c08df5206e2f9f?permalink_comment_id=3270713 uvc-gadget.sh start 2 - https://git.ideasonboard.org/uvc-gadget.git uvc-gadget -i test.jpg Host side: https://github.com/thekvs/uvccapture2 uvccapture2 --device /dev/video0 --resolution 640x360 --count 1 --result 8qxp.jpeg It will report jpeg header error. After debugs, I found two problem. Problem 1, sg is enabled. so uvc driver will use sg. each package include two trb, trb0 is 8bytes header, trb1 is 1016bytes. total 1024. num_trb here is wrong. it should be num_trb = priv_ep->interval * request->num_mapped_sgs. because priv_ep->interval is 1, I just simple set to request->num_mapped_sg as below patch. USB analyer show one whole 1024 ISO package sent out as expectation although document said only support one TD when use ISO (Maybe my doc is too old). *** Problem 2 *** According to doc and my observation, looks like hardware fetch data into FIFO when get SOF, then transfer data when get IN token. Each SOF will increase TRB regardless it is ready or not. When gadget complete equeue ISO data, so SOF will increase TRB regardless if there are IN token. SOF SOF SOF SOF IN SOF .... TRB0 TRB1 TRB2 TRB3 ... Host may start get data at some time after gadget queue data. So TRB0..2 data will be lost. If it is audio data, it should be okay. But for uvc, it is jpeg header, so host side report error. I checked dwc gadget driver, which start equeue ISO data only get NYET. I check cdns spec, there are ISOERR. But it is never happen. According to document, ISOERR should issue when IN token and FIFO no data. I tried below method 1. Delay queue TRB, but no ISOERR. 2. queue a lenght 0 TRB,but no ISOERR My question is how to delay queue TRB to ISO IN token really happen to avoid lost JPEG header. Frank
Comments
> >hi Pawel Laszczak > >Recently, I met the problem when use uvc. UVC report jpg header error. > >Basic reproduce steps. >Gadget side: >1 - > https://urldefense.com/v3/__https://gist.github.com/kbingham/c39c >4cc7c20882a104c08df5206e2f9f?permalink_comment_id=3270713__;!!EHscm >S1ygiU1lA!H1h8GlLnbS6vqklXm_2qGyinP638O62Kk2eLB9zeMkjAGXUAPYyPXDL >FasSqYt16xq0RGT0Ff-cP4A$ > uvc-gadget.sh start >2 - > https://urldefense.com/v3/__https://git.ideasonboard.org/uvc- >gadget.git__;!!EHscmS1ygiU1lA!H1h8GlLnbS6vqklXm_2qGyinP638O62Kk2eLB9z >eMkjAGXUAPYyPXDLFasSqYt16xq0RGT1ogOdRQA$ > uvc-gadget -i test.jpg > > >Host side: > https://urldefense.com/v3/__https://github.com/thekvs/uvccapture2 >__;!!EHscmS1ygiU1lA!H1h8GlLnbS6vqklXm_2qGyinP638O62Kk2eLB9zeMkjAGX >UAPYyPXDLFasSqYt16xq0RGT1MNlKiXA$ > uvccapture2 --device /dev/video0 --resolution 640x360 --count 1 -- >result 8qxp.jpeg > > It will report jpeg header error. > > >After debugs, I found two problem. > >Problem 1, sg is enabled. so uvc driver will use sg. each package include two >trb, trb0 is 8bytes header, trb1 is 1016bytes. total 1024. > >num_trb here is wrong. >it should be > num_trb = priv_ep->interval * request->num_mapped_sgs. > >because priv_ep->interval is 1, I just simple set to request->num_mapped_sg >as below patch. USB analyer show one whole 1024 ISO package sent out as >expectation although document said only support one TD when use ISO >(Maybe my doc is too old). Support for sg in uvc has been added after upstreaming this driver, so the driver needs some improvement. Calculating of num_trb probably will more complicated change. You can see how it is implemented in https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/udc/cdns2/cdns2-gadget.c#L412. CDNS2 is different controller and support only HS but has borrowed the DMA part from CDNS3. It was upsteamed after adding sg to UVC. Regarding TD, it is true that controller can support only one TD per SOF but this TD can contain many TRBs > >diff --git a/drivers/usb/cdns3/cdns3-gadget.c b/drivers/usb/cdns3/cdns3- >gadget.c >index 69a44bd7e5d02..8cc99a885883f 100644 >--- a/drivers/usb/cdns3/cdns3-gadget.c >+++ b/drivers/usb/cdns3/cdns3-gadget.c >@@ -1125,10 +1125,7 @@ static int cdns3_ep_run_transfer(struct >cdns3_endpoint *priv_ep, > struct scatterlist *s = NULL; > bool sg_supported = !!(request->num_mapped_sgs); > >- if (priv_ep->type == USB_ENDPOINT_XFER_ISOC) >- num_trb = priv_ep->interval; >- else >- num_trb = sg_supported ? request->num_mapped_sgs : 1; >+ num_trb = sg_supported ? request->num_mapped_sgs : 1; > > if (num_trb > priv_ep->free_trbs) { > priv_ep->flags |= EP_RING_FULL; > > >*** Problem 2 *** > >According to doc and my observation, looks like hardware fetch data into FIFO >when get SOF, then transfer data when get IN token. Each SOF will increase >TRB regardless it is ready or not. Yes, but this fetched data will be sent in next ITP. > >When gadget complete equeue ISO data, so SOF will increase TRB regardless if >there are IN token. > > SOF SOF SOF SOF IN SOF .... > TRB0 TRB1 TRB2 TRB3 ... > > >Host may start get data at some time after gadget queue data. > >So TRB0..2 data will be lost. > >If it is audio data, it should be okay. But for uvc, it is jpeg header, so host side >report error. > >I checked dwc gadget driver, which start equeue ISO data only get NYET. > >I check cdns spec, there are ISOERR. But it is never happen. According to >document, ISOERR should issue when IN token and FIFO no data. > Current CDNS3 driver has disabled ISOERR. Did you enable it? >I tried below method > 1. Delay queue TRB, but no ISOERR. > 2. queue a lenght 0 TRB,but no ISOERR > >My question is how to delay queue TRB to ISO IN token really happen to avoid >lost JPEG header. > >Frank > > > > >
On Mon, Oct 30, 2023 at 06:34:48AM +0000, Pawel Laszczak wrote: > > > > >hi Pawel Laszczak > > > >Recently, I met the problem when use uvc. UVC report jpg header error. > > > >Basic reproduce steps. > >Gadget side: > >1 - > > https://urldefense.com/v3/__https://gist.github.com/kbingham/c39c > >4cc7c20882a104c08df5206e2f9f?permalink_comment_id=3270713__;!!EHscm > >S1ygiU1lA!H1h8GlLnbS6vqklXm_2qGyinP638O62Kk2eLB9zeMkjAGXUAPYyPXDL > >FasSqYt16xq0RGT0Ff-cP4A$ > > uvc-gadget.sh start > >2 - > > https://urldefense.com/v3/__https://git.ideasonboard.org/uvc- > >gadget.git__;!!EHscmS1ygiU1lA!H1h8GlLnbS6vqklXm_2qGyinP638O62Kk2eLB9z > >eMkjAGXUAPYyPXDLFasSqYt16xq0RGT1ogOdRQA$ > > uvc-gadget -i test.jpg > > > > > >Host side: > > https://urldefense.com/v3/__https://github.com/thekvs/uvccapture2 > >__;!!EHscmS1ygiU1lA!H1h8GlLnbS6vqklXm_2qGyinP638O62Kk2eLB9zeMkjAGX > >UAPYyPXDLFasSqYt16xq0RGT1MNlKiXA$ > > uvccapture2 --device /dev/video0 --resolution 640x360 --count 1 -- > >result 8qxp.jpeg > > > > It will report jpeg header error. > > > > > >After debugs, I found two problem. > > > >Problem 1, sg is enabled. so uvc driver will use sg. each package include two > >trb, trb0 is 8bytes header, trb1 is 1016bytes. total 1024. > > > >num_trb here is wrong. > >it should be > > num_trb = priv_ep->interval * request->num_mapped_sgs. > > > >because priv_ep->interval is 1, I just simple set to request->num_mapped_sg > >as below patch. USB analyer show one whole 1024 ISO package sent out as > >expectation although document said only support one TD when use ISO > >(Maybe my doc is too old). > > Support for sg in uvc has been added after upstreaming this driver, so the driver > needs some improvement. > > Calculating of num_trb probably will more complicated change. > > You can see how it is implemented in > https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/udc/cdns2/cdns2-gadget.c#L412. > > CDNS2 is different controller and support only HS but has borrowed the DMA part from CDNS3. > It was upsteamed after adding sg to UVC. > > Regarding TD, it is true that controller can support only one TD per SOF but this TD can contain many TRBs Okay, great. I can work a patch if I can resolve problem 2. > > > > >diff --git a/drivers/usb/cdns3/cdns3-gadget.c b/drivers/usb/cdns3/cdns3- > >gadget.c > >index 69a44bd7e5d02..8cc99a885883f 100644 > >--- a/drivers/usb/cdns3/cdns3-gadget.c > >+++ b/drivers/usb/cdns3/cdns3-gadget.c > >@@ -1125,10 +1125,7 @@ static int cdns3_ep_run_transfer(struct > >cdns3_endpoint *priv_ep, > > struct scatterlist *s = NULL; > > bool sg_supported = !!(request->num_mapped_sgs); > > > >- if (priv_ep->type == USB_ENDPOINT_XFER_ISOC) > >- num_trb = priv_ep->interval; > >- else > >- num_trb = sg_supported ? request->num_mapped_sgs : 1; > >+ num_trb = sg_supported ? request->num_mapped_sgs : 1; > > > > if (num_trb > priv_ep->free_trbs) { > > priv_ep->flags |= EP_RING_FULL; > > > > > >*** Problem 2 *** > > > >According to doc and my observation, looks like hardware fetch data into FIFO > >when get SOF, then transfer data when get IN token. Each SOF will increase > >TRB regardless it is ready or not. > > Yes, but this fetched data will be sent in next ITP. > > > > >When gadget complete equeue ISO data, so SOF will increase TRB regardless if > >there are IN token. > > > > SOF SOF SOF SOF IN SOF .... > > TRB0 TRB1 TRB2 TRB3 ... > > > > > >Host may start get data at some time after gadget queue data. > > > >So TRB0..2 data will be lost. > > > >If it is audio data, it should be okay. But for uvc, it is jpeg header, so host side > >report error. > > > >I checked dwc gadget driver, which start equeue ISO data only get NYET. > > > >I check cdns spec, there are ISOERR. But it is never happen. According to > >document, ISOERR should issue when IN token and FIFO no data. > > > > Current CDNS3 driver has disabled ISOERR. Did you enable it? Yes, I enabled all IRQ. + if (priv_ep->type == USB_ENDPOINT_XFER_ISOC && priv_ep->dir) { + priv_ep->flags |= EP_QUIRK_ISO_IN_NOST; + reg |= 0xFFFF; + } Supposed ISOERR should happen even DMA is disabled. But I also tried enable DMA, and using lenght 0 TRB and link to loop. Still no ISOERR happen. I can see TRBADDR changed, but still no ISOERR irq/447-5b13000-200 [000] d..1. 78.662729: cdns3_epx_irq: IRQ for ep2in: 00000804 IOC , ep_traddr: c0086018 ep_last_sid: 00000000 use_streams: 0 ^^^^^^^ irq/447-5b13000-200 [000] d..1. 78.662851: cdns3_epx_irq: IRQ for ep2in: 00000804 IOC , ep_traddr: c008600c ep_last_sid: 00000000 use_streams: 0 irq/447-5b13000-200 [000] d..1. 78.662975: cdns3_epx_irq: IRQ for ep2in: 00000804 IOC , ep_traddr: c0086018 ep_last_sid: 00000000 use_streams: 0 STS is 0x804, only IOC set. Frank > > >I tried below method > > 1. Delay queue TRB, but no ISOERR. > > 2. queue a lenght 0 TRB,but no ISOERR > > > >My question is how to delay queue TRB to ISO IN token really happen to avoid > >lost JPEG header. > > > >Frank > > > > > > > > > > >
> >On Mon, Oct 30, 2023 at 06:34:48AM +0000, Pawel Laszczak wrote: >> >> > >> >hi Pawel Laszczak >> > >> >Recently, I met the problem when use uvc. UVC report jpg header error. >> > >> >Basic reproduce steps. >> >Gadget side: >> >1 - >> > https://urldefense.com/v3/__https://gist.github.com/kbingham/c39c >> >>4cc7c20882a104c08df5206e2f9f?permalink_comment_id=3270713__;!!EHsc >m >> >>S1ygiU1lA!H1h8GlLnbS6vqklXm_2qGyinP638O62Kk2eLB9zeMkjAGXUAPYyPXD >L >> >FasSqYt16xq0RGT0Ff-cP4A$ >> > uvc-gadget.sh start >> >2 - >> > https://urldefense.com/v3/__https://git.ideasonboard.org/uvc- >> >>gadget.git__;!!EHscmS1ygiU1lA!H1h8GlLnbS6vqklXm_2qGyinP638O62Kk2eLB >9z >> >eMkjAGXUAPYyPXDLFasSqYt16xq0RGT1ogOdRQA$ >> > uvc-gadget -i test.jpg >> > >> > >> >Host side: >> > https://urldefense.com/v3/__https://github.com/thekvs/uvccapture2 >> >>__;!!EHscmS1ygiU1lA!H1h8GlLnbS6vqklXm_2qGyinP638O62Kk2eLB9zeMkjAG >X >> >UAPYyPXDLFasSqYt16xq0RGT1MNlKiXA$ >> > uvccapture2 --device /dev/video0 --resolution 640x360 --count 1 -- >> >result 8qxp.jpeg >> > >> > It will report jpeg header error. >> > >> > >> >After debugs, I found two problem. >> > >> >Problem 1, sg is enabled. so uvc driver will use sg. each package >> >include two trb, trb0 is 8bytes header, trb1 is 1016bytes. total 1024. >> > >> >num_trb here is wrong. >> >it should be >> > num_trb = priv_ep->interval * request->num_mapped_sgs. >> > >> >because priv_ep->interval is 1, I just simple set to >> >request->num_mapped_sg as below patch. USB analyer show one whole >> >1024 ISO package sent out as expectation although document said only >> >support one TD when use ISO (Maybe my doc is too old). >> >> Support for sg in uvc has been added after upstreaming this driver, >> so the driver needs some improvement. >> >> Calculating of num_trb probably will more complicated change. >> >> You can see how it is implemented in >> >https://urldefense.com/v3/__https://elixir.bootlin.com/linux/latest/source/d >rivers/usb/gadget/udc/cdns2/cdns2- >gadget.c*L412__;Iw!!EHscmS1ygiU1lA!EZS2StTKnSzdCT7N5B1- >l8nGXQgS63KwgcGINcpBC8rnRJu2u8ryV1UjwQb6YfwYLPq9T_115KC5qQ$ . >> >> CDNS2 is different controller and support only HS but has borrowed the >DMA part from CDNS3. >> It was upsteamed after adding sg to UVC. >> >> Regarding TD, it is true that controller can support only one TD per >> SOF but this TD can contain many TRBs > >Okay, great. I can work a patch if I can resolve problem 2. At this moment I don't know how to resolve the problem 2. I'm going to recreate this case on my side and try to find some solution. Pawel > >> >> > >> >diff --git a/drivers/usb/cdns3/cdns3-gadget.c >> >b/drivers/usb/cdns3/cdns3- gadget.c index >> >69a44bd7e5d02..8cc99a885883f 100644 >> >--- a/drivers/usb/cdns3/cdns3-gadget.c >> >+++ b/drivers/usb/cdns3/cdns3-gadget.c >> >@@ -1125,10 +1125,7 @@ static int cdns3_ep_run_transfer(struct >> >cdns3_endpoint *priv_ep, >> > struct scatterlist *s = NULL; >> > bool sg_supported = !!(request->num_mapped_sgs); >> > >> >- if (priv_ep->type == USB_ENDPOINT_XFER_ISOC) >> >- num_trb = priv_ep->interval; >> >- else >> >- num_trb = sg_supported ? request->num_mapped_sgs : 1; >> >+ num_trb = sg_supported ? request->num_mapped_sgs : 1; >> > >> > if (num_trb > priv_ep->free_trbs) { >> > priv_ep->flags |= EP_RING_FULL; >> > >> > >> >*** Problem 2 *** >> > >> >According to doc and my observation, looks like hardware fetch data >> >into FIFO when get SOF, then transfer data when get IN token. Each >> >SOF will increase TRB regardless it is ready or not. >> >> Yes, but this fetched data will be sent in next ITP. >> >> > >> >When gadget complete equeue ISO data, so SOF will increase TRB >> >regardless if there are IN token. >> > >> > SOF SOF SOF SOF IN SOF .... >> > TRB0 TRB1 TRB2 TRB3 ... >> > >> > >> >Host may start get data at some time after gadget queue data. >> > >> >So TRB0..2 data will be lost. >> > >> >If it is audio data, it should be okay. But for uvc, it is jpeg >> >header, so host side report error. >> > >> >I checked dwc gadget driver, which start equeue ISO data only get NYET. >> > >> >I check cdns spec, there are ISOERR. But it is never happen. >> >According to document, ISOERR should issue when IN token and FIFO no >data. >> > >> >> Current CDNS3 driver has disabled ISOERR. Did you enable it? > >Yes, I enabled all IRQ. > >+ if (priv_ep->type == USB_ENDPOINT_XFER_ISOC && priv_ep->dir) { >+ priv_ep->flags |= EP_QUIRK_ISO_IN_NOST; >+ reg |= 0xFFFF; >+ } > >Supposed ISOERR should happen even DMA is disabled. >But I also tried enable DMA, and using lenght 0 TRB and link to loop. > >Still no ISOERR happen. I can see TRBADDR changed, but still no ISOERR > > > irq/447-5b13000-200 [000] d..1. 78.662729: cdns3_epx_irq: IRQ for ep2in: >00000804 IOC , ep_traddr: c0086018 ep_last_sid: 00000000 use_streams: 0 > > ^^^^^^^ > irq/447-5b13000-200 [000] d..1. 78.662851: cdns3_epx_irq: IRQ for ep2in: >00000804 IOC , ep_traddr: c008600c ep_last_sid: 00000000 use_streams: 0 > irq/447-5b13000-200 [000] d..1. 78.662975: cdns3_epx_irq: IRQ for ep2in: >00000804 IOC , ep_traddr: c0086018 ep_last_sid: 00000000 use_streams: 0 > >STS is 0x804, only IOC set. > >Frank > >> >> >I tried below method >> > 1. Delay queue TRB, but no ISOERR. >> > 2. queue a lenght 0 TRB,but no ISOERR >> > >> >My question is how to delay queue TRB to ISO IN token really happen >> >to avoid lost JPEG header. >> > >> >Frank >> > >> > >> > >> > >> > >>
On Mon, Nov 06, 2023 at 11:12:10AM +0000, Pawel Laszczak wrote: > > > >On Mon, Oct 30, 2023 at 06:34:48AM +0000, Pawel Laszczak wrote: > >> > >> > > >> >hi Pawel Laszczak > >> > > >> >Recently, I met the problem when use uvc. UVC report jpg header error. > >> > > >> >Basic reproduce steps. > >> >Gadget side: > >> >1 - > >> > https://urldefense.com/v3/__https://gist.github.com/kbingham/c39c > >> > >>4cc7c20882a104c08df5206e2f9f?permalink_comment_id=3270713__;!!EHsc > >m > >> > >>S1ygiU1lA!H1h8GlLnbS6vqklXm_2qGyinP638O62Kk2eLB9zeMkjAGXUAPYyPXD > >L > >> >FasSqYt16xq0RGT0Ff-cP4A$ > >> > uvc-gadget.sh start > >> >2 - > >> > https://urldefense.com/v3/__https://git.ideasonboard.org/uvc- > >> > >>gadget.git__;!!EHscmS1ygiU1lA!H1h8GlLnbS6vqklXm_2qGyinP638O62Kk2eLB > >9z > >> >eMkjAGXUAPYyPXDLFasSqYt16xq0RGT1ogOdRQA$ > >> > uvc-gadget -i test.jpg > >> > > >> > > >> >Host side: > >> > https://urldefense.com/v3/__https://github.com/thekvs/uvccapture2 > >> > >>__;!!EHscmS1ygiU1lA!H1h8GlLnbS6vqklXm_2qGyinP638O62Kk2eLB9zeMkjAG > >X > >> >UAPYyPXDLFasSqYt16xq0RGT1MNlKiXA$ > >> > uvccapture2 --device /dev/video0 --resolution 640x360 --count 1 -- > >> >result 8qxp.jpeg > >> > > >> > It will report jpeg header error. > >> > > >> > > >> >After debugs, I found two problem. > >> > > >> >Problem 1, sg is enabled. so uvc driver will use sg. each package > >> >include two trb, trb0 is 8bytes header, trb1 is 1016bytes. total 1024. > >> > > >> >num_trb here is wrong. > >> >it should be > >> > num_trb = priv_ep->interval * request->num_mapped_sgs. > >> > > >> >because priv_ep->interval is 1, I just simple set to > >> >request->num_mapped_sg as below patch. USB analyer show one whole > >> >1024 ISO package sent out as expectation although document said only > >> >support one TD when use ISO (Maybe my doc is too old). > >> > >> Support for sg in uvc has been added after upstreaming this driver, > >> so the driver needs some improvement. > >> > >> Calculating of num_trb probably will more complicated change. > >> > >> You can see how it is implemented in > >> > >https://urldefense.com/v3/__https://elixir.bootlin.com/linux/latest/source/d > >rivers/usb/gadget/udc/cdns2/cdns2- > >gadget.c*L412__;Iw!!EHscmS1ygiU1lA!EZS2StTKnSzdCT7N5B1- > >l8nGXQgS63KwgcGINcpBC8rnRJu2u8ryV1UjwQb6YfwYLPq9T_115KC5qQ$ . > >> > >> CDNS2 is different controller and support only HS but has borrowed the > >DMA part from CDNS3. > >> It was upsteamed after adding sg to UVC. > >> > >> Regarding TD, it is true that controller can support only one TD per > >> SOF but this TD can contain many TRBs > > > >Okay, great. I can work a patch if I can resolve problem 2. > > At this moment I don't know how to resolve the problem 2. > I'm going to recreate this case on my side and try to find some solution. > > Pawel I post a sg ISO fix patch, in case you need it. https://lore.kernel.org/imx/BYAPR07MB538112FE4150BC19696D7613DDAAA@BYAPR07MB5381.namprd07.prod.outlook.com/#R It fixed my case. but android looks like still issue. Recently quite busy. Frank Li > > > > >> > >> > > >> >diff --git a/drivers/usb/cdns3/cdns3-gadget.c > >> >b/drivers/usb/cdns3/cdns3- gadget.c index > >> >69a44bd7e5d02..8cc99a885883f 100644 > >> >--- a/drivers/usb/cdns3/cdns3-gadget.c > >> >+++ b/drivers/usb/cdns3/cdns3-gadget.c > >> >@@ -1125,10 +1125,7 @@ static int cdns3_ep_run_transfer(struct > >> >cdns3_endpoint *priv_ep, > >> > struct scatterlist *s = NULL; > >> > bool sg_supported = !!(request->num_mapped_sgs); > >> > > >> >- if (priv_ep->type == USB_ENDPOINT_XFER_ISOC) > >> >- num_trb = priv_ep->interval; > >> >- else > >> >- num_trb = sg_supported ? request->num_mapped_sgs : 1; > >> >+ num_trb = sg_supported ? request->num_mapped_sgs : 1; > >> > > >> > if (num_trb > priv_ep->free_trbs) { > >> > priv_ep->flags |= EP_RING_FULL; > >> > > >> > > >> >*** Problem 2 *** > >> > > >> >According to doc and my observation, looks like hardware fetch data > >> >into FIFO when get SOF, then transfer data when get IN token. Each > >> >SOF will increase TRB regardless it is ready or not. > >> > >> Yes, but this fetched data will be sent in next ITP. > >> > >> > > >> >When gadget complete equeue ISO data, so SOF will increase TRB > >> >regardless if there are IN token. > >> > > >> > SOF SOF SOF SOF IN SOF .... > >> > TRB0 TRB1 TRB2 TRB3 ... > >> > > >> > > >> >Host may start get data at some time after gadget queue data. > >> > > >> >So TRB0..2 data will be lost. > >> > > >> >If it is audio data, it should be okay. But for uvc, it is jpeg > >> >header, so host side report error. > >> > > >> >I checked dwc gadget driver, which start equeue ISO data only get NYET. > >> > > >> >I check cdns spec, there are ISOERR. But it is never happen. > >> >According to document, ISOERR should issue when IN token and FIFO no > >data. > >> > > >> > >> Current CDNS3 driver has disabled ISOERR. Did you enable it? > > > >Yes, I enabled all IRQ. > > > >+ if (priv_ep->type == USB_ENDPOINT_XFER_ISOC && priv_ep->dir) { > >+ priv_ep->flags |= EP_QUIRK_ISO_IN_NOST; > >+ reg |= 0xFFFF; > >+ } > > > >Supposed ISOERR should happen even DMA is disabled. > >But I also tried enable DMA, and using lenght 0 TRB and link to loop. > > > >Still no ISOERR happen. I can see TRBADDR changed, but still no ISOERR > > > > > > irq/447-5b13000-200 [000] d..1. 78.662729: cdns3_epx_irq: IRQ for ep2in: > >00000804 IOC , ep_traddr: c0086018 ep_last_sid: 00000000 use_streams: 0 > > > > ^^^^^^^ > > irq/447-5b13000-200 [000] d..1. 78.662851: cdns3_epx_irq: IRQ for ep2in: > >00000804 IOC , ep_traddr: c008600c ep_last_sid: 00000000 use_streams: 0 > > irq/447-5b13000-200 [000] d..1. 78.662975: cdns3_epx_irq: IRQ for ep2in: > >00000804 IOC , ep_traddr: c0086018 ep_last_sid: 00000000 use_streams: 0 > > > >STS is 0x804, only IOC set. > > > >Frank > > > >> > >> >I tried below method > >> > 1. Delay queue TRB, but no ISOERR. > >> > 2. queue a lenght 0 TRB,but no ISOERR > >> > > >> >My question is how to delay queue TRB to ISO IN token really happen > >> >to avoid lost JPEG header. > >> > > >> >Frank > >> > > >> > > >> > > >> > > >> > > >>
diff --git a/drivers/usb/cdns3/cdns3-gadget.c b/drivers/usb/cdns3/cdns3-gadget.c index 69a44bd7e5d02..8cc99a885883f 100644 --- a/drivers/usb/cdns3/cdns3-gadget.c +++ b/drivers/usb/cdns3/cdns3-gadget.c @@ -1125,10 +1125,7 @@ static int cdns3_ep_run_transfer(struct cdns3_endpoint *priv_ep, struct scatterlist *s = NULL; bool sg_supported = !!(request->num_mapped_sgs); - if (priv_ep->type == USB_ENDPOINT_XFER_ISOC) - num_trb = priv_ep->interval; - else - num_trb = sg_supported ? request->num_mapped_sgs : 1; + num_trb = sg_supported ? request->num_mapped_sgs : 1; if (num_trb > priv_ep->free_trbs) { priv_ep->flags |= EP_RING_FULL;