public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Clemens Ladisch <clemens@ladisch.de>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux1394-devel@lists.sourceforge.net,
	alsa-devel@alsa-project.org, linux-media@vger.kernel.org
Subject: Re: [PATCH] firewire: octlet AT payloads can be stack-allocated
Date: Tue, 26 Apr 2011 13:05:20 +0200	[thread overview]
Message-ID: <4DB6A6F0.3080604@ladisch.de> (raw)
In-Reply-To: <20110422151354.59c7ca77@stein>

Stefan Richter wrote:
> ...provided that the allocation persists until the packet was sent out
> to the bus.  But we do not need slab allocations anymore in order to
> satisfy streaming DMA mapping constraints, thanks to commit da28947e7e36
> "firewire: ohci: avoid separate DMA mapping for small AT payloads".
> 
> (Besides, the slab-allocated buffers that firewire-core, firewire-sbp2,
> and firedtv used to provide for 8-byte write and lock requests were
> still not fully portable since they crossed cacheline boundaries or
> shared a cacheline with unrelated CPU-accessed data.  snd-firewire-lib
> got this aspect right by using an extra kmalloc/ kfree just for the
> 8-byte transaction buffer.)
> 
> This change replaces kmalloc'ed lock transaction scratch buffers in
> firewire-core, firedtv, and snd-firewire-lib by local stack allocations.
> The lifetime requirement of these allocations is fulfilled because the
> call sites use the blocking fw_run_transaction API.
> 
> Perhaps the most notable result of the change is simpler locking because
> there is no need to serialize usages of preallocated per-device buffers
> anymore.  Also, allocations and deallocations are simpler.
> 
> firewire-sbp2's struct sbp2_orb.pointer buffer for 8-byte block write
> requests on the other hand needs to remain slab-allocated in order to
> keep the allocation around until end of AT DMA.
> 
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

Acked-by: Clemens Ladisch <clemens@ladisch.de>

      reply	other threads:[~2011-04-26 11:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4DA2B3DC.7010104@ladisch.de>
     [not found] ` <4DA2B482.4060701@ladisch.de>
     [not found]   ` <20110411142651.638311e0@stein>
2011-04-22 13:13     ` [PATCH] firewire: octlet AT payloads can be stack-allocated Stefan Richter
2011-04-26 11:05       ` Clemens Ladisch [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=4DB6A6F0.3080604@ladisch.de \
    --to=clemens@ladisch.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=stefanr@s5r6.in-berlin.de \
    /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