ath10k.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Adrian Chadd <adrian@freebsd.org>
Cc: Adrian Chadd <adrian@FreeBSD.org>,
	linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: go back to using dma_alloc_coherent() for firmware scratch memory.
Date: Wed, 31 May 2017 13:15:00 +0200	[thread overview]
Message-ID: <3f92c875c8fa4c66a3e32d88947c18b7@euamsexm01a.eu.qualcomm.com> (raw)
In-Reply-To: <20170501214327.5621-1-adrian@freebsd.org>

Adrian Chadd <adrian@freebsd.org> wrote:

> This reverts commit b057886524be ("ath10k: do not use coherent memory for
> allocated device memory chunks") in 2015 which converted this allocation from
> dma_map_coherent() to kzalloc() / dma_map_single().
> 
> The current problem manifests when using later model NICs with larger
> (>700KiB) scratch spaces in memory.  Although the kzalloc call
> succeeds, the software IOMMU TLB code (via dma_map_single()) panics
> because it can't find 700KiB of linear physmem bounce buffers for DMA.
> Now, this is a bit of a silly failure mode for the dma map API,
> but it's what we currently have to play with.
> 
> In these cases, doing kzalloc() works fine, but the dma_map_single()
> call fails.
> 
> After chatting with Linus briefly about this, it indeed should be
> using dma_alloc_coherent() for doing larger device memory allocation
> that requires some kind of physical address mapping.
> 
> You're not supposed to be using kzalloc and dma_map_* calls for
> large memory regions, and I'm guessing not for long-held mappings
> either.  Typically dma mappings should be temporary for DMA,
> not long held like these.
> 
> Now, since hopefully the major annoying underlying problem has also been
> addressed (ie, ath10k is no longer tears down all of these allocations
> and reallocates them every time the vdevs are brought down) fragmentation
> should stop being such a touchy issue.  If it is though, using
> dma_alloc_coherent() use gets us access to the CMB APIs too relatively
> easily and ideally we would be allocating memory early in boot for
> exactly these reasons.
> 
> Signed-off-by: Adrian Chadd <adrian@FreeBSD.org>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Patch applied to ath-next branch of ath.git, thanks.

79e68821582d ath10k: go back to using dma_alloc_coherent() for firmware scratch memory

-- 
https://patchwork.kernel.org/patch/9707059/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

      parent reply	other threads:[~2017-05-31 11:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-01 21:43 [PATCH] [ath10k] go back to using dma_alloc_coherent() for firmware scratch memory Adrian Chadd
     [not found] ` <CAHjFwoAr6Tjh=Zpr_JhEp_-g_0XJ+LDUagsfJh=vqseqzBC1Pw@mail.gmail.com>
2017-05-11  3:55   ` Kalle Valo
2017-05-11  4:02     ` Su Kang Yin
2017-05-11  4:10       ` Kalle Valo
2017-05-17 10:06 ` Sven Eckelmann
2017-05-19  9:02   ` Kalle Valo
2017-05-19  9:10 ` Kalle Valo
2017-05-31 11:15 ` Kalle Valo [this message]

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=3f92c875c8fa4c66a3e32d88947c18b7@euamsexm01a.eu.qualcomm.com \
    --to=kvalo@qca.qualcomm.com \
    --cc=adrian@freebsd.org \
    --cc=ath10k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).