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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 124F7C433EF for ; Mon, 4 Oct 2021 17:52:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E799861154 for ; Mon, 4 Oct 2021 17:52:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234817AbhJDRyN (ORCPT ); Mon, 4 Oct 2021 13:54:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41736 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233597AbhJDRyN (ORCPT ); Mon, 4 Oct 2021 13:54:13 -0400 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C04F7C061745 for ; Mon, 4 Oct 2021 10:52:23 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id p13so39962549edw.0 for ; Mon, 04 Oct 2021 10:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SVy+42avAMDVs9YXx1N0MW72e1XqpRIo0we4Jey6TgQ=; b=USZyRilZz6erOG49DFYjzZ7yWgjOF6KTPmH52T4Gemm+QUM3Fsk9hCPuO1ae+CsKMy 5cxbMWN0+QWJ7TNvMS+xMUWtoLMWb5t6Z7EiTWRxNQI0EeXpbmWGUY7HPhtaBMFPRnN1 tyqo3akeIm/LNXB/Hnk8xMZ2sGRkMTJTjJrVs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SVy+42avAMDVs9YXx1N0MW72e1XqpRIo0we4Jey6TgQ=; b=ljma+VEP4vuYg50NdnNnPDKMCwFpfoLcz0w0Rq4VXVrLixo3R4V6O9DxGM+MDXVqnp fX4FuxrPdg7gBQ/Rtbd3cpe9GPE3vDPPsHMax2aW5B/yjw90ci/mZmVjr5IdV5E6QwDe 0JO2psPsArJTuC+pNBAWzI7HOGKjciOIwBN9fcpuppaOvACph4XneacJgd9EOJsjgmmu k1KYCeOGrk+DiyWKfNr1InbhHko85qnpRSRfVFn5IumOC3G5NSi/nT2nMB956s4ydP0s HJj0+BhbsY0bHs7NFyv1WcUMUUzZG9beDeKAY0G0lRjgZ8ZBJx29fF5pHH+FumVLnav/ Oe5g== X-Gm-Message-State: AOAM531OLWrgf4+xPOEHVYggK+nhiulH5ADaXmekr22IRLP1a6CNNMAi wj48cEhPV3Ng6xIDn6J6s8q0k1xJ6FqVEpROOgN+ZQ== X-Google-Smtp-Source: ABdhPJw473yRin1rcK/LShFHmhtAKymPp2Nzjft1z63Ov1VE3CPb6pN7T9mMOt0Y7yINQAzbdd9Z9LQmL/AJ4fFVqJE= X-Received: by 2002:a17:906:60c7:: with SMTP id f7mr18468620ejk.57.1633369942391; Mon, 04 Oct 2021 10:52:22 -0700 (PDT) MIME-Version: 1.0 References: <20210914114813.15404-1-verdre@v0yd.nl> <20210914114813.15404-3-verdre@v0yd.nl> <5f0b52be-8b9c-b015-6c5a-f2f470e37058@v0yd.nl> In-Reply-To: <5f0b52be-8b9c-b015-6c5a-f2f470e37058@v0yd.nl> From: Brian Norris Date: Mon, 4 Oct 2021 10:52:11 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] mwifiex: Try waking the firmware until we get an interrupt To: =?UTF-8?Q?Jonas_Dre=C3=9Fler?= Cc: Amitkumar Karwar , Ganapathi Bhat , Xinming Hu , Kalle Valo , "David S. Miller" , Jakub Kicinski , Tsuchiya Yuto , Linux Wireless , "open list:NETWORKING DRIVERS" , Linux Kernel , Linux PCI , Maximilian Luz , Andy Shevchenko , Bjorn Helgaas , =?UTF-8?Q?Pali_Roh=C3=A1r?= , Heiner Kallweit , Johannes Berg , "# 9798ac6d32c1 mfd : cros_ec : Add cros_ec_cmd_xfer_status helper" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Hi, On Sun, Oct 3, 2021 at 2:18 AM Jonas Dre=C3=9Fler wrote: > So I think I have another solution that might be a lot more elegant, how > about this: > > try_again: > n_tries++; > > mwifiex_write_reg(adapter, reg->fw_status, FIRMWARE_READY_PCIE); > > if (wait_event_interruptible_timeout(adapter->card_wakeup_wait_q, > READ_ONCE(adapter->int_statu= s) !=3D 0, > WAKEUP_TRY_AGAIN_TIMEOUT) = =3D=3D 0 && > n_tries < MAX_N_WAKEUP_TRIES) { > goto try_again; > } Isn't wait_event_interruptible_timeout()'s timeout in jiffies, which is not necessarily that predictable, and also a lot more coarse-grained than we want? (As in, if HZ=3D100, we're looking at precision on the order of 10ms, whereas the expected wakeup latency is ~6ms.) That would be OK for well-behaved PCI cases, where we never miss a write, but it could ~double your latency for your bad systems that will need more than one run of the loop. Also, feels like a do/while could be cleaner, but that's a lesser detail. > and then call wake_up_interruptible() in the mwifiex_interrupt_status() > interrupt handler. > > This solution should make sure we always keep wakeup latency to a minimum > and can still retry the register write if things didn't work. Brian