Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3421123imu; Mon, 10 Dec 2018 01:45:38 -0800 (PST) X-Google-Smtp-Source: AFSGD/V3xl+7bsy6anTgZQkBxf79E3vjS3rXnagZQE8sCNMQtFp2gqkxrehYeNVvZ7urvjradYjd X-Received: by 2002:a62:6f49:: with SMTP id k70mr11627973pfc.7.1544435138554; Mon, 10 Dec 2018 01:45:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544435138; cv=none; d=google.com; s=arc-20160816; b=AyTx0syl+iGvV8Lhyko6H97lkwJsbJ4EAfZVIvCRLvhb9GwNBke5mSJDWeERticH6l lJM3SwoTRxw+lPvwDC5sPoFnBAes+Tfl6Hw+N7h3qntN1fKnrfsnH3YGY5UXaVQfGZDb kULLz+q55aA8UCqYVPXrlkrjfke5IELph5WZsfpLMPtuo0CLMsDr+Knw+2egJLeAPzGA w95CCrVz4wLFTewWHJ4gfG2HvhvfkUIKHeqNvmw+gJq5wJzWMagZSVwjbw/z+Gdvd8qm PjVDY3TJtpSdEbEgv45lO1bLKZMwyxhGPgCevlEqimRPDkMhJSUAyW/JYFCJznU0TvZ1 m+pQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :spamdiagnosticmetadata:spamdiagnosticoutput:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from:dkim-signature; bh=QWyfuf494Yi23nLZ4uJAKS9vwAmdLbl+zXsne46aF6Q=; b=j6tB9C2mB6suAoTv79Nw4puOBeGiZuHOx5ICqfWA5qUaEyyJ8th8+GF6EEDWOxbZyn otZjwKYgRokJMgGG56AvGbA1rNNGDCVq2gydpBoJ3kCA2ArVbKzqyV/HxS0aFTguyeZT WhiGfC+cvgHVguwqh5YjYv3s2xU/Oam31P2JEm3512fcGuaTSLEPxCjAenM2Pk2Avtnr 2qmqwAYnx+GFCxMztUQ/OftZr97T8mX/aWmC1cUXQd81HaheewGQ+/OmNHwxuAMvzwgq J5gDZAUmmcmBPOvuOcWgYN1NDXdFEWN7hDOlh5B0ueTqDmMtM97hFezmRxI2ar6qYHGE lmwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@xilinx.onmicrosoft.com header.s=selector1-xilinx-com header.b=ZDxNjAsC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g71si9147846pgc.419.2018.12.10.01.45.22; Mon, 10 Dec 2018 01:45:38 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@xilinx.onmicrosoft.com header.s=selector1-xilinx-com header.b=ZDxNjAsC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726846AbeLJI7k (ORCPT + 99 others); Mon, 10 Dec 2018 03:59:40 -0500 Received: from mail-eopbgr800082.outbound.protection.outlook.com ([40.107.80.82]:34523 "EHLO NAM03-DM3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726531AbeLJI7j (ORCPT ); Mon, 10 Dec 2018 03:59:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xilinx.onmicrosoft.com; s=selector1-xilinx-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QWyfuf494Yi23nLZ4uJAKS9vwAmdLbl+zXsne46aF6Q=; b=ZDxNjAsCiiIKuaTT1wOFZE1kLrf73t8NoNTThNEyZAGBDQHT2+hHVqOZDB027H/ylc+cumv4sgcdCuiLRd1iT1DMYZWHaucENyA2EvLyYiWzMV0Zm/VmDWqzts0UiTsMN+JNSA9+VIAIzVy+dH+SCIuLeobstC2+I0TvpOYQAY8= Received: from BL0PR02MB5633.namprd02.prod.outlook.com (20.177.241.80) by BL0PR02MB4579.namprd02.prod.outlook.com (10.167.181.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.22; Mon, 10 Dec 2018 08:56:43 +0000 Received: from BL0PR02MB5633.namprd02.prod.outlook.com ([fe80::68ed:9ca9:c7da:d76d]) by BL0PR02MB5633.namprd02.prod.outlook.com ([fe80::68ed:9ca9:c7da:d76d%2]) with mapi id 15.20.1404.026; Mon, 10 Dec 2018 08:56:43 +0000 From: Anurag Kumar Vulisha To: Felipe Balbi , Greg Kroah-Hartman , Shuah Khan , Alan Stern , Johan Hovold , Jaejoong Kim , Benjamin Herrenschmidt , Roger Quadros , Manu Gautam , "martin.petersen@oracle.com" , Bart Van Assche , Mike Christie , Matthew Wilcox , Colin Ian King CC: "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "v.anuragkumar@gmail.com" , Thinh Nguyen , Tejas Joglekar , Ajay Yugalkishore Pandey Subject: RE: [PATCH v7 09/10] usb: dwc3: Check for IOC/LST bit in both event->status and TRB->ctrl fields Thread-Topic: [PATCH v7 09/10] usb: dwc3: Check for IOC/LST bit in both event->status and TRB->ctrl fields Thread-Index: AQHUiWbqDI9WfI74TEmPyd+V2NlqDqVv4SkAgACgrWCAAlLUgIACXYXwgAJlVICAABFagA== Date: Mon, 10 Dec 2018 08:56:43 +0000 Message-ID: References: <1543662811-5194-1-git-send-email-anurag.kumar.vulisha@xilinx.com> <1543662811-5194-10-git-send-email-anurag.kumar.vulisha@xilinx.com> <875zw82vfj.fsf@linux.intel.com> <874lbpx3vg.fsf@linux.intel.com> <87pnu927oq.fsf@linux.intel.com> In-Reply-To: <87pnu927oq.fsf@linux.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=anuragku@xilinx.com; x-originating-ip: [149.199.50.133] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;BL0PR02MB4579;6:cLCrQ+uvdWvO1hm0k49YXJibN+n4u2dd5OUTVO9k6lHH2tZ4aBQUddKAro+E759kp/Bjl44NKaS+3vabxc8sDkyBaCFkdhx9tHUaEwuPLo6qaZQ9xzHznO3EhlkmKxd05CvfrzgwORrGcfaTQiAetiVhskjp5QK39HNZzci0fEJTvPizyL78kCy4Dz93htHg9YRUV3RI6Cb7MiED2oaKwztHsZ5yDvJFJRgheHdAN5Q9yRWPTJRe8QUzpAqfz5ZTyhThTfKu0agL0YNAb7UuGcGQ1vrSbhwO4nikjI66FNHrJ0NwJ2R+jVJyOWQVRERd2gzEbhS754Hb2bEu3E8Uex6XYpZcnhDVub3c2qXQzEO6+Qfzu1GbVeIUUVS35b0khPynIfJPBO7CMHWNMJ1edIZeGvbzLGNavcZrNMMTfdYtqa49uy7pcjVIDnt0G9uthgQ/vYB1OwGPsSbccwmWYg==;5:On3KC+dA9XatyqOrILNO5Q52LB6CCSBRk58cz3WEtDDbEDgrcywbviQkXTzY9P2vAlNo332A2ecuAlXw5VS9RE7yBNSdXWX0cF4j8mu4GsTuGWtdt4pKy102KcAiIZovXlH4TvqCzD4GF90mWVGi10cPVwXeJ3pvaoJOvnI8//U=;7:QLZfI1qMHMGXRGSC5Fh8OSBWssHpwI0G3RzOlUc9lqbZf3TXX/PBGwujhfnayPGO5xBFe3sWIduYuWHPz/IcFAh2obYkAGK1YEemvbR3f35tG7w1JC67KsgWFaAcohOcgKBUsb9JDeB7SST4vvHBIA== x-ms-office365-filtering-correlation-id: 6a5333d7-4545-49e7-5640-08d65e7d6872 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020);SRVR:BL0PR02MB4579; x-ms-traffictypediagnostic: BL0PR02MB4579: x-ld-processed: 657af505-d5df-48d0-8300-c31994686c5c,ExtAddr x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(8211001083)(3230017)(999002)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231472)(944501520)(52105112)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095);SRVR:BL0PR02MB4579;BCL:0;PCL:0;RULEID:;SRVR:BL0PR02MB4579; x-forefront-prvs: 08828D20BC x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(396003)(366004)(376002)(136003)(346002)(39860400002)(199004)(189003)(13464003)(186003)(7416002)(93886005)(102836004)(14454004)(81166006)(81156014)(99286004)(71190400001)(71200400001)(2906002)(74316002)(26005)(7736002)(14444005)(6506007)(76176011)(305945005)(5660300001)(33656002)(11346002)(6436002)(4326008)(446003)(66066001)(476003)(486006)(229853002)(6116002)(86362001)(3846002)(9686003)(2501003)(39060400002)(106356001)(53936002)(68736007)(105586002)(97736004)(316002)(478600001)(8936002)(2171002)(7696005)(110136005)(54906003)(6246003)(107886003)(55016002)(25786009)(8676002)(256004)(921003)(1121003);DIR:OUT;SFP:1101;SCL:1;SRVR:BL0PR02MB4579;H:BL0PR02MB5633.namprd02.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: xilinx.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: xyTAgZeC9M0MDyhqbUKf3Ti+HOiUsWg8NuBP92VceFSw4Aehz70lLwW5TwuRsr+tI/6BLnTvwqQYuBM/Hk4myxzBbV29rZ1kuAynlf7o0QeTOn9ST2LxHalTQl+m/n4bxhMRseUc5UhJfyvrMTq8Ud/x0sHbeT+34YZ8U2e7bZDz6rX89DeMdXFCXxGpMYZywjVTt6u0c44s6KgtXQIDD3c37rOeTSeUFdUOz7RmbOP/NCOcA6FU+vIMV6v/Lt3TguoDJILaSmqv27TdTG6szuqFM5xAQNYCV5BNqQmor7me4G+xcYi4jc2/v8KgkSsN spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a5333d7-4545-49e7-5640-08d65e7d6872 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2018 08:56:43.3769 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB4579 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Felipe, >-----Original Message----- >From: Felipe Balbi [mailto:balbi@kernel.org] >Sent: Monday, December 10, 2018 12:24 PM >To: Anurag Kumar Vulisha ; Greg Kroah-Hartman >; Shuah Khan ; Alan Stern >; Johan Hovold ; Jaejoong Kim >; Benjamin Herrenschmidt = ; >Roger Quadros ; Manu Gautam ; >martin.petersen@oracle.com; Bart Van Assche ; Mike >Christie ; Matthew Wilcox ; Coli= n Ian >King >Cc: linux-usb@vger.kernel.org; linux-kernel@vger.kernel.org; >v.anuragkumar@gmail.com; Thinh Nguyen ; Tejas Jogleka= r >; Ajay Yugalkishore Pandey >Subject: RE: [PATCH v7 09/10] usb: dwc3: Check for IOC/LST bit in both eve= nt->status >and TRB->ctrl fields > > >Hi, > >Anurag Kumar Vulisha writes: >> HI Felipe, >> >>>-----Original Message----- >>>From: Felipe Balbi [mailto:balbi@kernel.org] >>>Sent: Friday, December 07, 2018 11:42 AM >>>To: Anurag Kumar Vulisha ; Greg Kroah-Hartman >>>; Shuah Khan ; Alan Stern >>>; Johan Hovold ; Jaejoong K= im >>>; Benjamin Herrenschmidt ; >>>Roger Quadros ; Manu Gautam ; >>>martin.petersen@oracle.com; Bart Van Assche ; Mike >>>Christie ; Matthew Wilcox ; Co= lin >Ian >>>King >>>Cc: linux-usb@vger.kernel.org; linux-kernel@vger.kernel.org; >>>v.anuragkumar@gmail.com; Thinh Nguyen ; Tejas >Joglekar >>>; Ajay Yugalkishore Pandey > >>>Subject: RE: [PATCH v7 09/10] usb: dwc3: Check for IOC/LST bit in both e= vent- >>status >>>and TRB->ctrl fields >>> >>> >>>Hi, >>> >>>Anurag Kumar Vulisha writes: >>>>>> @@ -2286,7 +2286,12 @@ static int >>>>>dwc3_gadget_ep_reclaim_completed_trb(struct dwc3_ep *dep, >>>>>> if (event->status & DEPEVT_STATUS_SHORT && !chain) >>>>>> return 1; >>>>>> >>>>>> - if (event->status & (DEPEVT_STATUS_IOC | DEPEVT_STATUS_LST)) >>>>>> + if ((event->status & DEPEVT_STATUS_IOC) && >>>>>> + (trb->ctrl & DWC3_TRB_CTRL_IOC)) >>>>>> + return 1; >>>>> >>>>>this shouldn't be necessary. According to databook, event->status >>>>>contains the bits from the completed TRB. Which means that >>>>>event->status & IOC will always be equal to trb->ctrl & IOC. >>>>> >>>> Thanks for reviewing this patch. Lets consider an example where a >>>> request has num_sgs > 0 and each sg is mapped to a TRB and the last >>>> TRB has the IOC bit set. Once the controller is done with the >>>> transfer, it generates XferInProgress for the last TRB (since IOC bit >>>> is set). As a part of trb reclaim process >>>> dwc3_gadget_ep_reclaim_trb_sg() calls >>>> dwc3_gadget_ep_reclaim_completed_trb() for req->num_sgs times. Since >>>> the event already has the IOC bit set, the loop is exited from the >>>> loop at the very first TRB and the remaining TRBs (mapped to the sglis= t) are left >>>unhandled. >>>> To avoid this we modified the code to exit only if both TRB & event >>>> has the IOC bit set. >>> >>>Seems like IOC case should just test for chain flag as well: >>> >> >> Okay. Along with this logic the code for updating chain bit should also = be modified I >guess. > >not really > >> Since the IOC bit is also set when there are not enough TRBs available, = the code >should be >> modified to not set DWC3_TRB_CTRL_CHN bit when the IOC bit is set. I wil= l update >below >> changes along with your suggestions and resend the patches. > >no. Actually I don't think we're allowed to split a scatter/gather like >that. I did that quite a while ago, but I don't think we're allowed to >do so. What we should do, in that case, is not even queue that request >until we have enough for all members of the scatter/gather. But that's a >separate patch, anyway. > Okay. I have a doubt here, not pushing the request until all sgs are mapped= to enough TRBs might remove the driver complexity but reduce the performance (since we are= waiting until enough TRBs are available). Are we okay with that? =20 Thanks, Anurag Kumar Vulisha =20