From patchwork Tue Jan 17 17:39:23 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Lindgren X-Patchwork-Id: 9521625 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7052F6020B for ; Tue, 17 Jan 2017 17:39:35 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 60D772852A for ; Tue, 17 Jan 2017 17:39:35 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5531A285C9; Tue, 17 Jan 2017 17:39:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 966D32852A for ; Tue, 17 Jan 2017 17:39:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751387AbdAQRjc (ORCPT ); Tue, 17 Jan 2017 12:39:32 -0500 Received: from muru.com ([72.249.23.125]:58092 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751382AbdAQRj2 (ORCPT ); Tue, 17 Jan 2017 12:39:28 -0500 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id D094A8286; Tue, 17 Jan 2017 17:40:14 +0000 (UTC) Date: Tue, 17 Jan 2017 09:39:23 -0800 From: Tony Lindgren To: Bin Liu , Grygorii Strashko , Dan Williams , Vinod Koul , Daniel Mack , Felipe Balbi , Johan Hovold , Peter Ujfalusi , Sekhar Nori , Sebastian Andrzej Siewior , dmaengine@vger.kernel.org, linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, Andy Shevchenko , Kevin Hilman , Patrick Titiano , Sergei Shtylyov Subject: Re: [PATCHv2] dmaengine: cppi41: Fix oops in cppi41_runtime_resume Message-ID: <20170117173922.GR7403@atomide.com> References: <20170113215936.GF2630@atomide.com> <20170116233329.GF7403@atomide.com> <20170116235428.GG7403@atomide.com> <20170117125919.GA31716@uda0271908> <20170117161138.GJ7403@atomide.com> <20170117162152.GE31716@uda0271908> <20170117163103.GO7403@atomide.com> <20170117164846.GG31716@uda0271908> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170117164846.GG31716@uda0271908> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP * Bin Liu [170117 08:49]: > On Tue, Jan 17, 2017 at 08:31:03AM -0800, Tony Lindgren wrote: > > * Bin Liu [170117 08:22]: > > > On Tue, Jan 17, 2017 at 08:11:39AM -0800, Tony Lindgren wrote: > > > > * Bin Liu [170117 05:00]: > > > > > On Mon, Jan 16, 2017 at 03:54:29PM -0800, Tony Lindgren wrote: > > > > > > Anyways, for the -rc series oops, we can just leave out the WARN_ON > > > > > > parts for now until drivers/usb/musb/musb_cppi41.c is fixed too. > > > > > > > > > > Giving that cppi is a submodule inside the usb subsysytem and it does't > > > > > have separate power rail or clock, what is the benefit to adding runtime > > > > > PM in the cppi driver? > > > > > > > > Good question. We need at least minimal support to enable things for > > > > probe and then idle cppi41 properly if only cppi41.ko is loaded with no > > > > USB modules. > > > > > > > > But yeah now that musb does runtime PM based on the cable detection, we > > > > pretty much guarantee that cppi41 is always enabled when USB is in use. > > > > > > > > And if there are no other devices using cppi41 dma on davinci, we can > > > > simplify the PM runtime a bit for cppi41. > > > > > > This might be a good idea. I didn't have much time to play with this > > > cppi41 runtime PM, but it seems I am having more issues than you and > > > others seeing. > > > > What kind of additional issues are you seeing not described in the $subject > > patch? > > I didn't take a note and don't remember if those are in the $subject > patch. But > > - enumeration begining with a reset that the device doesn't accept > address X, error code -71; or Some of this could be fixed by $subject patch if caused by a race. Some of it I'm suspecting might be a different issue where cppi41 dma will just hang until the device is disconnected on 1 sized in dma transfer. See the experimental patch below. > - console fooding with cppi error code -115 after thumb drive enumeration. This should get fixed with the $subject patch if we additionally set the autosuspend_delay to something sufficient, like 1000. > Again, I only tried for a few minutes and didn't take a note, since I > don't have time to look at this ATM. Well I'll post what I think we should fix for the -rc series for cppi41. If you can then please test that a bit and see if it works. Assuming things work, then all the other changes can be done later on with no rush. Regards, Tony 8< ---------------------------------------- --- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -751,6 +751,15 @@ static void musb_ep_program(struct musb *musb, u8 epnum, hw_ep->tx_channel = NULL; } + /* + * At least cppi41 in dma will just hang with size of 1 until the + * device is connected. For sizes less than 8 it seems to take a + * long time to complete. Let's use minimum size of 16 to avoid + * tiny in DMA transfers. + */ + if (!is_out && (len < 16)) + use_dma = 0; + /* candidate for DMA? */ dma_controller = musb->dma_controller; if (use_dma && is_dma_capable() && epnum && dma_controller) {