Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp505262pxb; Sat, 18 Sep 2021 08:59:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwYRyhiULTTF1EtZdedxatlUGX7KUqHyoMRp+njLBQR/1xkibo4K+9F9tUcpRUASo/GBmmx X-Received: by 2002:a17:906:5855:: with SMTP id h21mr18404173ejs.230.1631980798692; Sat, 18 Sep 2021 08:59:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631980798; cv=none; d=google.com; s=arc-20160816; b=UI0FVja7nZL9bNLaKHGgMsALiE1Ym76I0upDv7FJr+7r8+2HUDme0mGysv+MbTrStK AEiErE++R3KQTsRz7D/bYHGDpmpIL5sj+nzxX71TGcredvjSzo2sEM3Ene5Jff42lEdV 5Rqkr1liTDDiHHCUkL7oVst0zHhmW6QF/ivNMMO8JlK2ZRyJtlGNZqqk4L117yNF4odb C60jvF6zHNIowxiYWj3hEQH7gOXXs/x1Zfl2+kWRNNJ+wYTSxQuKuYVvYJzJNUPnXcx8 mTPMMnNygiBlgfBA3tMFM56/r64LQtPMHwEHuAh1xy4ofNNMl2UpE97NGol1UEzMaLi9 vwVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:date:message-id:references:cc:to:subject :from; bh=hWjoXVKGciDWktcIJlMf3KieEK1cre9jCflxXjp3dz4=; b=lw1sj9lhPcMs76NnOF4wQ1iBdrxdQmS1hSOHABA7hzPHImeZFceWVAC7yUmp4UGoYV JU5NItpGB3Q/t0GoH2N2yG2wJoVyj6ldrIeiyNHhWH02XB1C/CcGZRwasH/J3R03cIQP 3BSAQD+Plx0FSED9rDEOZh88xTt9AixZbbCtAagAsezvqS+3E0avNqDgNTarjuDuQBcG XzkcM6WO9EA8V/zG8Zi+qwML3uRJu6ojEKnckkEnMTovWbQc+femBPnBwUzWN+QkIMqf 4i+DNvh765yZxC/2D1UMnXMWns555nLvR+6KpYL/k5jP9ecVlMN98Q8b+stvbWexWV5d zwSQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 17si10087240ejx.425.2021.09.18.08.59.28; Sat, 18 Sep 2021 08:59:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243258AbhIRHih (ORCPT + 78 others); Sat, 18 Sep 2021 03:38:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39278 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243245AbhIRHif (ORCPT ); Sat, 18 Sep 2021 03:38:35 -0400 Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [IPv6:2001:67c:2050::465:101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 039FDC061574; Sat, 18 Sep 2021 00:37:11 -0700 (PDT) Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:105:465:1:3:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4HBN1x4xwszQjf4; Sat, 18 Sep 2021 09:37:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de From: =?UTF-8?Q?Jonas_Dre=c3=9fler?= Subject: Re: [PATCH 1/2] mwifiex: Use non-posted PCI register writes To: Brian Norris , Andy Shevchenko Cc: Amitkumar Karwar , Ganapathi Bhat , Xinming Hu , Kalle Valo , "David S. Miller" , Jakub Kicinski , Tsuchiya Yuto , linux-wireless , netdev@vger.kernel.org, Linux Kernel , linux-pci , Maximilian Luz , Andy Shevchenko , Bjorn Helgaas , =?UTF-8?Q?Pali_Roh=c3=a1r?= References: <20210830123704.221494-1-verdre@v0yd.nl> <20210830123704.221494-2-verdre@v0yd.nl> Message-ID: <0ce93e7c-b041-d322-90cd-40ff5e0e8ef0@v0yd.nl> Date: Sat, 18 Sep 2021 09:37:03 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A83FB275 Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On 9/1/21 11:07 PM, Brian Norris wrote: > Apologies for the brain-dead mailer. I forget that I should only reply > via web when I _want_ text wrapping: > > On Wed, Sep 01, 2021 at 02:04:04PM -0700, Brian Norris wrote: >> (b) latency spikes to ~6ms: >> # trace-cmd record -p function_graph -O funcgraph-abstime -l >> mwifiex_pm_wakeup_card >> # trace-cmd report >> kworker/u13:0-199 [003] 348.987306: funcgraph_entry: # >> 6219.500 us | mwifiex_pm_wakeup_card(); >> kworker/u13:0-199 [003] 349.316312: funcgraph_entry: # >> 6267.625 us | mwifiex_pm_wakeup_card(); >> kworker/u13:3-4057 [001] 352.238530: funcgraph_entry: # >> 6184.250 us | mwifiex_pm_wakeup_card(); >> kworker/u13:0-199 [002] 356.626366: funcgraph_entry: # >> 6553.166 us | mwifiex_pm_wakeup_card(); >> kworker/u13:3-4057 [002] 356.709389: funcgraph_entry: # >> 6212.500 us | mwifiex_pm_wakeup_card(); >> kworker/u13:3-4057 [002] 356.847215: funcgraph_entry: # >> 6230.292 us | mwifiex_pm_wakeup_card(); >> kworker/u13:3-4057 [000] 356.897576: funcgraph_entry: # >> 6451.667 us | mwifiex_pm_wakeup_card(); >> kworker/u13:0-199 [004] 357.175025: funcgraph_entry: # >> 6204.042 us | mwifiex_pm_wakeup_card(); >> >> whereas it used to look more like: >> >> kworker/u13:1-173 [005] 212.230542: funcgraph_entry: >> 7.000 us | mwifiex_pm_wakeup_card(); >> kworker/u13:3-1768 [005] 213.886063: funcgraph_entry: >> 9.334 us | mwifiex_pm_wakeup_card(); >> kworker/u13:3-1768 [002] 214.473273: funcgraph_entry: + >> 11.375 us | mwifiex_pm_wakeup_card(); >> kworker/u13:3-1768 [005] 214.530705: funcgraph_entry: >> 5.542 us | mwifiex_pm_wakeup_card(); >> kworker/u13:1-173 [002] 215.050168: funcgraph_entry: + >> 13.125 us | mwifiex_pm_wakeup_card(); >> kworker/u13:1-173 [002] 215.106492: funcgraph_entry: + >> 11.959 us | mwifiex_pm_wakeup_card(); >> kworker/u13:3-1768 [005] 215.484807: funcgraph_entry: >> 8.459 us | mwifiex_pm_wakeup_card(); >> kworker/u13:1-173 [003] 215.515238: funcgraph_entry: + >> 15.166 us | mwifiex_pm_wakeup_card(); >> kworker/u13:3-1768 [001] 217.175691: funcgraph_entry: + >> 11.083 us | mwifiex_pm_wakeup_card(); > > That should read: > > # trace-cmd record -p function_graph -O funcgraph-abstime -l mwifiex_pm_wakeup_card > # trace-cmd report > kworker/u13:0-199 [003] 348.987306: funcgraph_entry: # 6219.500 us | mwifiex_pm_wakeup_card(); > kworker/u13:0-199 [003] 349.316312: funcgraph_entry: # 6267.625 us | mwifiex_pm_wakeup_card(); > kworker/u13:3-4057 [001] 352.238530: funcgraph_entry: # 6184.250 us | mwifiex_pm_wakeup_card(); > kworker/u13:0-199 [002] 356.626366: funcgraph_entry: # 6553.166 us | mwifiex_pm_wakeup_card(); > kworker/u13:3-4057 [002] 356.709389: funcgraph_entry: # 6212.500 us | mwifiex_pm_wakeup_card(); > kworker/u13:3-4057 [002] 356.847215: funcgraph_entry: # 6230.292 us | mwifiex_pm_wakeup_card(); > kworker/u13:3-4057 [000] 356.897576: funcgraph_entry: # 6451.667 us | mwifiex_pm_wakeup_card(); > kworker/u13:0-199 [004] 357.175025: funcgraph_entry: # 6204.042 us | mwifiex_pm_wakeup_card(); > > vs. > > kworker/u13:1-173 [005] 212.230542: funcgraph_entry: 7.000 us | mwifiex_pm_wakeup_card(); > kworker/u13:3-1768 [005] 213.886063: funcgraph_entry: 9.334 us | mwifiex_pm_wakeup_card(); > kworker/u13:3-1768 [002] 214.473273: funcgraph_entry: + 11.375 us | mwifiex_pm_wakeup_card(); > kworker/u13:3-1768 [005] 214.530705: funcgraph_entry: 5.542 us | mwifiex_pm_wakeup_card(); > kworker/u13:1-173 [002] 215.050168: funcgraph_entry: + 13.125 us | mwifiex_pm_wakeup_card(); > kworker/u13:1-173 [002] 215.106492: funcgraph_entry: + 11.959 us | mwifiex_pm_wakeup_card(); > kworker/u13:3-1768 [005] 215.484807: funcgraph_entry: 8.459 us | mwifiex_pm_wakeup_card(); > kworker/u13:1-173 [003] 215.515238: funcgraph_entry: + 15.166 us | mwifiex_pm_wakeup_card(); > kworker/u13:3-1768 [001] 217.175691: funcgraph_entry: + 11.083 us | mwifiex_pm_wakeup_card(); > > Brian > Thanks for the pointer to that commit Brian, it turns out this is actually the change that causes the "Firmware wakeup failed" issues that I'm trying to fix with the second patch here. Also my approach is a lot messier than just reverting 062e008a6e83e7c4da7df0a9c6aefdbc849e2bb3 and also appears to be blocking even longer... Does anyone have an idea what could be the reason for the posted write not going through, or could that also be a potential firmware bug in the chip? Jonas