All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: "Jonas Dreßler" <verdre@v0yd.nl>
Cc: "Amitkumar Karwar" <amitkarwar@gmail.com>,
	"Ganapathi Bhat" <ganapathi017@gmail.com>,
	"Xinming Hu" <huxinming820@gmail.com>,
	"Kalle Valo" <kvalo@codeaurora.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Tsuchiya Yuto" <kitakar@gmail.com>,
	"Linux Wireless" <linux-wireless@vger.kernel.org>,
	"open list:NETWORKING DRIVERS" <netdev@vger.kernel.org>,
	"Linux Kernel" <linux-kernel@vger.kernel.org>,
	"Linux PCI" <linux-pci@vger.kernel.org>,
	"Maximilian Luz" <luzmaximilian@gmail.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Pali Rohár" <pali@kernel.org>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Johannes Berg" <johannes@sipsolutions.net>,
	"# 9798ac6d32c1 mfd : cros_ec : Add cros_ec_cmd_xfer_status
	helper" <stable@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] mwifiex: Try waking the firmware until we get an interrupt
Date: Mon, 4 Oct 2021 10:52:11 -0700	[thread overview]
Message-ID: <CAOFLbXbK5LmZbLcEs5e-0twoSkxkyKy8S6ZJVsz9Ap_a_iGZPA@mail.gmail.com> (raw)
In-Reply-To: <5f0b52be-8b9c-b015-6c5a-f2f470e37058@v0yd.nl>

Hi,

On Sun, Oct 3, 2021 at 2:18 AM Jonas Dreßler <verdre@v0yd.nl> 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_status) != 0,
>                                              WAKEUP_TRY_AGAIN_TIMEOUT) == 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=100, 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

  reply	other threads:[~2021-10-04 17:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-14 11:48 [PATCH v2 0/2] mwifiex: Work around firmware bugs on 88W8897 chip Jonas Dreßler
2021-09-14 11:48 ` [PATCH v2 1/2] mwifiex: Use non-posted PCI write when setting TX ring write pointer Jonas Dreßler
2021-09-22 11:17   ` Andy Shevchenko
2021-09-22 12:08     ` Jonas Dreßler
2021-09-22 13:22       ` Andy Shevchenko
2021-09-22 14:03   ` David Laight
2021-09-22 14:27     ` Pali Rohár
2021-09-22 15:54       ` David Laight
2021-09-30 14:27         ` Jonas Dreßler
2021-10-06 16:01           ` Jonas Dreßler
2021-09-14 11:48 ` [PATCH v2 2/2] mwifiex: Try waking the firmware until we get an interrupt Jonas Dreßler
2021-09-22 11:19   ` Andy Shevchenko
2021-09-30 18:04     ` Jonas Dreßler
2021-09-30 20:58       ` Andy Shevchenko
2021-09-30 21:07         ` Jonas Dreßler
2021-09-30 21:16           ` Andy Shevchenko
2021-10-03  9:18   ` Jonas Dreßler
2021-10-04 17:52     ` Brian Norris [this message]
2021-09-27 20:30 ` [PATCH v2 0/2] mwifiex: Work around firmware bugs on 88W8897 chip Brian Norris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOFLbXbK5LmZbLcEs5e-0twoSkxkyKy8S6ZJVsz9Ap_a_iGZPA@mail.gmail.com \
    --to=briannorris@chromium.org \
    --cc=amitkarwar@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=davem@davemloft.net \
    --cc=ganapathi017@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=huxinming820@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=kitakar@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luzmaximilian@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pali@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=verdre@v0yd.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.