From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751435AbdDCFbn convert rfc822-to-8bit (ORCPT ); Mon, 3 Apr 2017 01:31:43 -0400 Received: from smtprelay.synopsys.com ([198.182.47.9]:39518 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750992AbdDCFbl (ORCPT ); Mon, 3 Apr 2017 01:31:41 -0400 From: John Youn To: Felipe Balbi , Roger Quadros , Mathias Nyman , John Youn CC: "vivek.gautam@codeaurora.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2 3/4] usb: dwc3: add dual-role support Thread-Topic: [PATCH v2 3/4] usb: dwc3: add dual-role support Thread-Index: AQHSiFWY8u7EpS6HYEupsYn3t5cRdA== Date: Mon, 3 Apr 2017 05:31:39 +0000 Message-ID: <2B3535C5ECE8B5419E3ECBE300772909021B4A488C@US01WEMBX2.internal.synopsys.com> References: <1487250377-13653-1-git-send-email-rogerq@ti.com> <1487250377-13653-4-git-send-email-rogerq@ti.com> <87r31hhd7g.fsf@linux.intel.com> <46440b24-a2cd-93d6-e92e-2d80482f7d32@ti.com> <87a884kyva.fsf@linux.intel.com> <874lybktcp.fsf@linux.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.186.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/30/2017 02:27 AM, Felipe Balbi wrote: > > Hi > > Roger Quadros writes: >>>>> For something that simple, we wouldn't even need to use OTG FSM layer >>>>> because that brings no benefit for such a simple requirement. >>>> >>>> no no. I think you got it wrong. I'm not using the OTG FSM layer at all :). >>> >>> what are all the otg_fsm mentions then? Also you have: >>> >>> + struct usb_otg otg; >>> + struct otg_fsm otg_fsm; >>> >> >> I'll get rid of them. They aren't really needed. >> Now I see why you thought I was using the otg_fsm layer. :) > > fair enough > >>>>> Can you either confirm or refute the statement above? >>>> >>>> The real problem was that if host adapter was removed during a system suspend >>>> then while resuming XHCI was locking up like below. This is probably because >>>> we're trying to remove/Halt the HCD in the otg_irq_handler before XHCI driver has resumed? >>>> >>>> How can we ensure that we call dwc3_host_exit() only *after* XHCI driver has resumed? >>> >>> Well, xHCI is our child, so driver model should *already* be >>> guaranteeing that, no? Specially since you're calling this from >>> ->complete() which happens after ->resume() has been called for the >>> entire tree. It's true, however, that dwc3's ->complete() will be called >>> before xhci's ->complete(). Is this the problem you're pointing at? Or >>> do you mean xHCI is runtime suspended (or runtime resuming) while you >>> call dwc3_host_exit()? If that's the case, then there's a bug in xHCI >>> itself. >> >> Yes dwc3->complete() being called before xhci->complete(), and so HCD being >> removed before xhci->complete() causes the lockup. >> >> It could be a bug in xHCI driver as well. > > I see... > >>>> We need a way to mask the OTG events without loosing them while they are masked. >>>> Do you know how that could be achieved? >>> >>> masking doesn't clear events. It just masks them. Look at gadget.c for >>> how we do it. Basically, the code we have here is racy, really racy and >>> will cause hard-to-debug lockups. Your code can only work with >>> IRQF_ONESHOT, which we don't want to add back. >>> >>> In any case, to mask events, you set BIT 31 in GEVNTSIZ register. Just >>> copy it from gadget.c ;-) >> >> Isn't GEVNTSIZ specific to device side? We're talking about the OTG block here. > > that's true, sorry. > >> Are you sure that setting bit 31 of GEVNTSIZ will mask OTG_irq? I don't think so. >> >> Note that OTG_IRQ is a separate IRQ line than PERIPHERAL_IRQ. > > man, there's really no way to mask OTG events. This can be bad :-) > > John, can you confirm if there's really no way of masking OTG events > without loosing them? Not sure. I'll have to verify. If the IP version is 3.00a or higher you could experiment with using interrupt moderation as a global mask. John