Skip to content

L
linux
Switch branch/tag
  1. 20 Jan, 2017 5 commits
    • Martin Blumenstingl's avatar
      brcmfmac: add support for BCM43455 with modalias sdio:c00v02D0dA9BF · a62a7788
      Martin Blumenstingl authored 
      BCM43455 is a more recent revision of the BCM4345. Some of the BCM43455
got a dedicated SDIO device ID which is currently not supported by
brcmfmac.
Adding the new sdio_device_id to brcmfmac is enough to get the BCM43455
supported because the chip itself is already supported (due to BCM4345
support in the driver).
Signed-off-by: default avatarMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: default avatarArend van Spriel <arend.vanspriel@broadcom.com>
Reviewed-by: default avatarAndreas Färber <afaerber@suse.de>
Tested-by: default avatarAndreas Färber <afaerber@suse.de>
Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      a62a7788
    • Brian Norris's avatar
      mwifiex: don't complain about 'unknown event id: 0x63' · 0ed917d0
      Brian Norris authored 
      Marvell folks tell me this is a debugging event that the driver doesn't
need to handle, but on 8997 w/ firmware 16.68.1.p97, I see several of
these sorts of messages at (for instance) boot time:

[   13.825848] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63
[   14.838561] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63
[   14.850397] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63
[   32.529923] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63

Let's handle this "event" with a much lower verbosity.
Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      0ed917d0
    • Brian Norris's avatar
      mwifiex: pcie: read FROMDEVICE DMA-able memory with READ_ONCE() · fe116788
      Brian Norris authored 
      In mwifiex_delay_for_sleep_cookie(), we're looping and waiting for the
PCIe endpoint to write a magic value back to memory, to signal that it
has finished going to sleep. We're not letting the compiler know that
this might change underneath our feet though. Let's do that, for good
hygiene.

I'm not aware of this fixing any concrete problems. I also give no
guarantee that this loop is actually correct in any other way, but at
least this looks like an improvement to me.
Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      fe116788
    • Brian Norris's avatar
      mwifiex: pcie: don't loop/retry interrupt status checks · 5d5ddb5e
      Brian Norris authored 
      The following sequence occurs when using IEEE power-save on 8997:
(a) driver sees SLEEP event
(b) driver issues SLEEP CONFIRM
(c) driver recevies CMD interrupt; within the interrupt processing loop,
    we do (d) and (e):
(d) wait for FW sleep cookie (and often time out; it takes a while), FW
    is putting card into low power mode
(e) re-check PCIE_HOST_INT_STATUS register; quit loop with 0 value

But at (e), no one actually signaled an interrupt (i.e., we didn't check
adapter->int_status). And what's more, because the card is going to
sleep, this register read appears to take a very long time in some cases
-- 3 milliseconds in my case!

Now, I propose that (e) is completely unnecessary. If there were any
additional interrupts signaled after the start of this loop, then the
interrupt handler would have set adapter->int_status to non-zero and
queued more work for the main loop -- and we'd catch it on the next
iteration of the main loop.

So this patch drops all the looping/re-reading of PCIE_HOST_INT_STATUS,
which avoids the problematic (and slow) register read in step (e).

Incidentally, this is a very similar issue to the one fixed in commit
ec815dd2 ("mwifiex: prevent register accesses after host is
sleeping"), except that the register read is just very slow instead of
fatal in this case.

Tested on 8997 in both MSI and (though not technically supported at the
moment) MSI-X mode.
Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      5d5ddb5e
    • Brian Norris's avatar
      mwifiex: pcie: use posted write to wake up firmware · 062e008a
      Brian Norris authored 
      Depending on system factors (e.g., the PCIe link PM state), the first
read to wake up the Wifi firmware can take a long time. There is no
reason to use a (blocking, non-posted) read at this point, so let's just
use a write instead. Write vs. read doesn't matter functionality-wise --
it's just a dummy operation. But let's make sure to re-write with the
correct "ready" signature, since we check for that in other parts of the
driver.

This has been shown to decrease the time spent blocking in this function
on RK3399.
Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      062e008a
  3. 19 Jan, 2017 7 commits
  5. 17 Jan, 2017 14 commits
  7. 12 Jan, 2017 13 commits
  9. 11 Jan, 2017 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7