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=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 11888C4360C for ; Fri, 27 Sep 2019 15:19:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E333A207E0 for ; Fri, 27 Sep 2019 15:19:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727602AbfI0PTj (ORCPT ); Fri, 27 Sep 2019 11:19:39 -0400 Received: from muru.com ([72.249.23.125]:34630 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727076AbfI0PTj (ORCPT ); Fri, 27 Sep 2019 11:19:39 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 903F28022; Fri, 27 Sep 2019 15:20:10 +0000 (UTC) Date: Fri, 27 Sep 2019 08:19:35 -0700 From: Tony Lindgren To: Yegor Yefremov Cc: linux-omap@vger.kernel.org, vkoul@kernel.org, Bin Liu , linux-usb Subject: Re: musb: cppi41: broken high speed FTDI functionality when connected to musb directly Message-ID: <20190927151935.GD5610@atomide.com> References: 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 [190927 12:31]: > On Fri, Sep 27, 2019 at 10:18 AM Yegor Yefremov > wrote: > > > > I was porting my system from 3.18/4.2 to 5.3. During this process I > > noticed that FT4232 that is attached directly to musb is not working > > correctly when opened for the first time: tx is working but nothing > > can be received. On the second opening everything is working fine. > > When the same chip is connected via a USB hub - everything is working > > from the very beginning. > > > > I could reproduce this issue using BeagleBone Black with omap2plus_defconfig. > > > > # lsusb -t > > +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M > > |__ Port 1: Dev 2, If 0, Class=, Driver=ftdi_sio, 480M > > |__ Port 1: Dev 2, If 1, Class=, Driver=ftdi_sio, 480M > > |__ Port 1: Dev 2, If 2, Class=, Driver=ftdi_sio, 480M > > |__ Port 1: Dev 2, If 3, Class=, Driver=ftdi_sio, 480M > > > > git bisect revealed the following: > > > > fdea2d09b997ba4c86e7a707a5fac87c305f2131 is the first bad commit > > commit fdea2d09b997ba4c86e7a707a5fac87c305f2131 > > Author: Tony Lindgren > > Date: Wed Aug 31 07:19:59 2016 -0700 > > > > dmaengine: cppi41: Add basic PM runtime support > > > > Let's keep the device enabled between cppi41_dma_issue_pending() > > and dmaengine_desc_get_callback_invoke() and rely on the PM runtime > > autoidle timeout elsewhere. > > > > As the PM runtime is for whole device, not for each channel, > > we need to queue pending transfers if the device is PM runtime > > suspended. Then we start the pending transfers in PM runtime > > resume. > > > > Signed-off-by: Tony Lindgren > > Signed-off-by: Vinod Koul > > > > :040000 040000 8cf92c09083541dfdee01cc2973e73ef520f4fb1 > > a03c1a7ba8e723f7b503733c46edaa4141483265 M drivers > > > > Any idea? > > The problems can be reproduced with other FTDI chips like FT232R. > > Invoking "minicom -D /dev/ttyUSB0" and typing some characters is > enough to reproduce the issue (just in case, hw flow control should be > disabled). > > cp210x based converter is working without an issue. So only FTDI chips > are affected so far. Hmm OK. Maybe this could be an issue where the FTDI chip takes longer to enumerate and cppi41 is already suspended by then? At least we had a similar issue with commit ae4a3e028bb8 ("dmaengine: cppi41: Fix runtime PM timeouts with USB mass storage"). Regards, Tony