Received: by 10.223.185.111 with SMTP id b44csp87704wrg; Fri, 9 Mar 2018 01:27:54 -0800 (PST) X-Google-Smtp-Source: AG47ELteGXfdh09vFQSPYT44iRlzTLKwQiOO0qACVB83VUmLSuKv6oCd/vM3GumnVWt4g6WlNdbA X-Received: by 2002:a17:902:7088:: with SMTP id z8-v6mr27845397plk.174.1520587674144; Fri, 09 Mar 2018 01:27:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520587674; cv=none; d=google.com; s=arc-20160816; b=H4+dL0cW/3svC8zsFHf6QSsun6w73TzPlZQuTV/0baFPWum8Et9rFZ+EmSyX/y5syz H1HO1h79DOERabDeufsyKkHdYwzqhpVNJ0iaALo0jaPSzIt9Eg5gc8OlwybAP5jUn5uU +81aUp7r+dmrMjht7U89OC9cRVql3mvPFIESQPUMHHYrf16SKNSH7VHMi0OkrTsv3URi Ib4VOK8YaH5AHtFVgNm/Oj4nWTHsPySHvVwmcsMNKyxGKXHsHa3qVqFAfanLJZYNmb27 xZC1wjQiDZdh82JZYk62v4YFe/rBI6UM/WBzZKCR7aD1vG5tAci0SZt38tsnNqAmYwFI IvEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=smTwcOhGwu9F1s3+xcdFb2dOWh8L7e+2mleB193/B2k=; b=wcwdcZWakduFD+UMaJE3PbCCRmZNIpuZ9BuH7Eh0dSOn0Zfkq6FNR7ghBLXjulgxPi hSWj4HUPgEqt6OYWgSy/RGXTlkNroL2OJJaJ3xk12tUGnO/DYKy7jEBMUcH3kR2kOL5P y+nS+fdDyGEHPLBkjUtMdV1O4N2CSvlAAlonUX6TO6Gd1qBcjoPJcHRpumKR1CDq3ysj IKNp1cSaRhgugx+8Ef97dTRuL5pd3WxbTRgk+LymcmFHPTugE/tA8Tl17mQAA8QDVHPG JVZERCyXpGrJcUtMTTa61FQ/boov4q+p9Ym4regAho4l1nj1gPGeKq8Sq0b/PRRO4O8C e0XQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=pnSgs75W; 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; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 196si465800pge.817.2018.03.09.01.27.39; Fri, 09 Mar 2018 01:27:54 -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=@ti.com header.s=ti-com-17Q1 header.b=pnSgs75W; 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; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751001AbeCIJ0r (ORCPT + 99 others); Fri, 9 Mar 2018 04:26:47 -0500 Received: from fllnx209.ext.ti.com ([198.47.19.16]:46950 "EHLO fllnx209.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750800AbeCIJ0q (ORCPT ); Fri, 9 Mar 2018 04:26:46 -0500 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by fllnx209.ext.ti.com (8.15.1/8.15.1) with ESMTP id w299Qiwt009205; Fri, 9 Mar 2018 03:26:44 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1520587604; bh=Rdsury+yw3d8h/cumorSixA900/dZqYz6qoyFjnu7Hs=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=pnSgs75WguK4GZVjFIdelw2hybS3xiOgwOQ0qDClusFJSL23LjoGDEIPs6qMggpOo cYoGRJtAFQ4mxHDNgONNDYa9fH+PaP4GKGX2WtMiAaXskFrLt3YfV378kVu4oUXYue Ax97TpwQHKfGbhzMXBNbFIRoWnElYzybIrkPcPug= Received: from DLEE106.ent.ti.com (dlee106.ent.ti.com [157.170.170.36]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id w299QiKi011563; Fri, 9 Mar 2018 03:26:44 -0600 Received: from DLEE106.ent.ti.com (157.170.170.36) by DLEE106.ent.ti.com (157.170.170.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Fri, 9 Mar 2018 03:26:43 -0600 Received: from dlep33.itg.ti.com (157.170.170.75) by DLEE106.ent.ti.com (157.170.170.36) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Fri, 9 Mar 2018 03:26:43 -0600 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id w299QghQ020847; Fri, 9 Mar 2018 03:26:42 -0600 Subject: Re: [PATCH] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume To: Felipe Balbi , Baolin Wang CC: USB , LKML References: <1519730526-22274-1-git-send-email-rogerq@ti.com> <87sh9l5z4l.fsf@linux.intel.com> <94cd6377-1327-2309-8d69-6ab0de2bdfd4@ti.com> <87po4i3o1v.fsf@linux.intel.com> <87k1uq3ho6.fsf@linux.intel.com> <8ec0485e-89af-568b-e34a-b0cd490817d0@ti.com> <87h8puwyn5.fsf@linux.intel.com> <5bc56ef5-66b1-d40c-1639-e748fe18cdbd@ti.com> <87muzha9h4.fsf@linux.intel.com> From: Roger Quadros Message-ID: Date: Fri, 9 Mar 2018 11:26:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <87muzha9h4.fsf@linux.intel.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-GB Content-Transfer-Encoding: 8bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/03/18 11:23, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: > > > >>>> When we set up the DWC3_DEPCMD_ENDTRANSFER command in >>>> dwc3_stop_active_transfer(), we can do not set DWC3_DEPCMD_CMDIOC, >>>> then there will no endpoint command complete interrupts I think. >>>> >>>> cmd |= DWC3_DEPCMD_CMDIOC; >>> >>> I remember some part of the databook mandating CMDIOC to be set. We >>> could test it out without and see if anything blows up. I would, >>> however, require a lengthy comment explaining that we're deviating from >>> databook revision x.yya, section foobar because $reasons. :-) >>> >> >> This is what the v3.10 databook says >> >> "When issuing an End Transfer command, software must set the CmdIOC >> bit (field 8) so that an Endpoint Command Complete event is generated >> after the transfer ends. This is necessary to synchronize the >> conclusion of system bus traffic before the End Transfer command is >> completed." >> >> with a note >> >> "If GUCTL2[Rst_actbitlater] is set, Software can poll the completion >> of the End Transfer command by polling the command active bit to be >> cleared to 0." >> >> fyi. >> >> Rst_actbitlater - "Enable clearing of the command active bit for the >> ENDXFER command after the command execution is completed. This bit is >> valid in device mode only." >> >> So I'd prefer not to clear CMDIOC for all cases. >> >> Could we some how just tackle the dwc3_gadget_exit case like I did in >> this patch? > > if you can send a version that doesn't iterate over all endpoints twice, > sure. We still need a comment somewhere, and I fear we may get > interrupts later in some cases. How would we deal with that? > how about explicitly masking that interrupt? Is it possible? -- cheers, -roger Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki