From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40788ECE58A for ; Tue, 1 Oct 2019 16:52:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2251521783 for ; Tue, 1 Oct 2019 16:52:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733219AbfJAQn5 (ORCPT ); Tue, 1 Oct 2019 12:43:57 -0400 Received: from muru.com ([72.249.23.125]:35046 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733177AbfJAQn4 (ORCPT ); Tue, 1 Oct 2019 12:43:56 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 6BCCE811B; Tue, 1 Oct 2019 16:44:27 +0000 (UTC) Date: Tue, 1 Oct 2019 09:43:51 -0700 From: Tony Lindgren To: Yegor Yefremov Cc: Johan Hovold , Sebastian Reichel , linux-omap@vger.kernel.org, vkoul@kernel.org, Bin Liu , linux-usb , Andrey Skvortsov , giulio.benetti@benettiengineering.com, Sebastian Andrzej Siewior Subject: Re: musb: cppi41: broken high speed FTDI functionality when connected to musb directly Message-ID: <20191001164351.GJ5610@atomide.com> References: <20190927151935.GD5610@atomide.com> <20190927155738.GF5610@atomide.com> <20190930145711.GG5610@atomide.com> <20190930152330.GH5610@atomide.com> <20190930195411.6porqtm7tlokgel3@earth.universe> <20191001080339.GF13531@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org * Yegor Yefremov [191001 09:20]: > On Tue, Oct 1, 2019 at 10:03 AM Johan Hovold wrote: > > > > On Mon, Sep 30, 2019 at 09:54:11PM +0200, Sebastian Reichel wrote: > > > Hi, > > > > > > On Mon, Sep 30, 2019 at 08:23:30AM -0700, Tony Lindgren wrote: > > > > > > Actually playing with the cppi41 timeout might be more suitable here, > > > > they use the same module clock from what I remember though. So > > > > maybe increase the cppi41 autosuspend_timeout from 100 ms to 500 ms > > > > or higher: > > > > > > > > # echo 500 > /sys/bus/platform/drivers/cppi41-dma-engine/47400000.dma-controller/power/autosuspend_delay_ms > > > > > > > > If changing the autosuspend_timeout_ms value does not help, then > > > > try setting control to on there. > > > > > > I did not check the details, but from the cover-letter this might be > > > woth looking into: > > > > > > https://lore.kernel.org/lkml/20190930161205.18803-1-johan@kernel.org/ > > > > No, that one should be unrelated as it would only prevent later suspends after > > a driver has been unbound (and rebound). > > I've tried to increase the autosuspend_delay_ms and to set control to > "on" but nothing changes. Below you can see the output of my testing > script [1] (Py2 only). As one can see, the first cycle i.e. after the > port is open for the first time, fails. But the subsequent cycle is > successful. If you invoke the script again, everything repeats. > > I've also made printk() in cppi41_run_queue() and it looks like this > routine will be called from cppi41_dma_issue_pending() only in the > beginning of the second test cycle. So sounds like for you intially cppi41_dma_issue_pending() has !cdd->is_suspended and just adds the request to the queue. And then cppi41_run_queue() never gets called if this happens while we have cppi41_runtime_resume() is still running? Can you check that cppi41_dma_issue_pending() really gets called for the first request and it adds the request to the queue by adding a printk to cppi41_dma_issue_pending()? > [1] http://ftp.visionsystems.de/temp/serialtest.py For me this script somehow fails to configure the ports with: $ python2 serialtest.py -c2 /dev/ttyUSB0 /dev/ttyUSB0 Openning one of the serial ports failed Openning one of the serial ports failed The permissions are set properly as I have minicom working.. So still no luck reproducing. Regards, Tony