All of lore.kernel.org
 help / color / mirror / Atom feed
From: Clemens Ladisch <clemens@ladisch.de>
To: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: tiwai@suse.de, alsa-devel@alsa-project.org,
	ffado-devel@lists.sourceforge.net
Subject: Re: [PATCH 26/29] ALSA: oxfw: Add support AMDTP in-stream
Date: Mon, 24 Nov 2014 14:54:17 +0100	[thread overview]
Message-ID: <54733889.8050303@ladisch.de> (raw)
In-Reply-To: <546DC356.8010207@sakamocchi.jp>

Takashi Sakamoto wrote:
> On Nov 17 2014 06:21, Clemens Ladisch wrote:
>> And why are the substreams counters atomic?
>> Can't they just be normal variables accessed from inside the mutex?
>
> Just for my convinience. I didn't want to write many
> mutex_lock()/mutex_unlock() because wrong coding of them causes-dead
> lock

Just use a kernel compiled with CONFIG_PROVE_LOCKING.

> An attached patch achieves your idea over my patchset. Handling
> reference counter is easy to understand (because it's arithmetric
> operation) but I don't like much mutex_lock()/mutex_unlock().
>
> Can I request you to explain about the advantages of your idea?

It makes the driver work correctly.

There's nothing wrong with atomic_t itself, but in this case, none of
the accesses would be valid outside of the lock, so it is not necessary
for them to be atomic.

In theory, it would be possible to use atomic_t to synchronize multiple
streams, but this requires that
1. two CPUs that start a stream at the same time do not both think they
   are the first, so you *must* use something like atomic_inc_and_test(),
   and
2. when one CPU is still starting a stream, code on all other CPUs must
   be able to work correctly, without synchronization.  This is not
   possible if the code requires to know that the DMA actually has
   started; consider the following code:

   void start_some_substream(...)
   {
       if (atomic_inc_and_test(substreams)) {
           mutex_lock();
           // lots of stuff to start DMA ...
           mutex_unlock();
       } else {
           // wait for the DMA to be started
       }
       ...
   }

   How could the 'else' branch ensure that the DMA engine is started?
   Just taking the mutex is not enough, because it could happen before
   the mutex_lock() of the first stream.  This is not possible without
   moving the inc_and_test into the locked region.


Regards,
Clemens

  parent reply	other threads:[~2014-11-24 13:54 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-26 13:03 [PATCH 00/29 v2] ALSA: Enhancement for existed FireWire drivers Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 01/29] ALSA: dice: Rename structure and its members Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 02/29] ALSA: dice: Move file to its own directory Takashi Sakamoto
2014-11-18 12:57   ` Clemens Ladisch
2014-11-18 15:29     ` Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 03/29] ALSA: dice: Split transaction functionality into a file Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 04/29] ALSA: dice: Split stream " Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 05/29] ALSA: dice: Split PCM " Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 06/29] ALSA: dice: Split hwdep " Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 07/29] ALSA: dice: Split proc interface " Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 08/29] ALSA: dice: Add new functions for constraints of PCM parameters Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 09/29] ALSA: dice: Change the way to start stream Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 10/29] ALSA: dice: Add support for duplex streams with synchronization Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 11/29] ALSA: dice: Support for non SYT-Match sampling clock source mode Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 12/29] ALSA: dice: Add support for capturing PCM samples Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 13/29] ALSA: dice: Add support for MIDI capture/playback Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 14/29] ALSA: dice: remove experimental state Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 15/29] ALSA: speakers: Rename to oxfw and rename some members Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 16/29] ALSA: oxfw: Move to its own directory Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 17/29] ALSA: oxfw: Split stream functionality to a new file and add a header file Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 18/29] ALSA: oxfw: Split PCM functionality to a new file Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 19/29] ALSA: oxfw: Split control " Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 20/29] ALSA: oxfw: Change the way to name card Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 21/29] ALSA: oxfw: Add support for AV/C stream format command to get/set supported stream formation Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 22/29] ALSA: oxfw: Change the way to make PCM rules/constraints Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 23/29] ALSA: oxfw: Add proc interface for debugging purpose Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 24/29] ALSA: oxfw: Change the way to start stream Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 25/29] ALSA: oxfw: Add support for Behringer/Mackie devices Takashi Sakamoto
2014-11-16 20:57   ` Clemens Ladisch
2014-11-18 15:24     ` Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 26/29] ALSA: oxfw: Add support AMDTP in-stream Takashi Sakamoto
2014-11-16 21:21   ` Clemens Ladisch
2014-11-20 10:32     ` Takashi Sakamoto
2014-11-24  1:03       ` Takashi Sakamoto
2014-11-24 13:54       ` Clemens Ladisch [this message]
     [not found]         ` <54746395.4070807@sakamocchi.jp>
2014-11-25 12:04           ` Clemens Ladisch
2014-11-25 22:41             ` Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 27/29] ALSA: oxfw: add support for capturing PCM samples Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 28/29] ALSA: oxfw: Add support for capture/playback MIDI messages Takashi Sakamoto
2014-10-26 13:03 ` [PATCH 29/29] ALSA: oxfw: Add hwdep interface Takashi Sakamoto
2014-10-26 13:29 ` [PATCH] hwdep: add OXFW driver support Takashi Sakamoto
2014-10-26 13:43   ` [PATCH alsa-lib] " Takashi Sakamoto
2014-10-26 16:51 ` [PATCH 00/29 v2] ALSA: Enhancement for existed FireWire drivers Stefan Richter
2014-11-14 10:50 ` Takashi Iwai
2014-11-14 12:08   ` Clemens Ladisch

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=54733889.8050303@ladisch.de \
    --to=clemens@ladisch.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=ffado-devel@lists.sourceforge.net \
    --cc=o-takashi@sakamocchi.jp \
    --cc=tiwai@suse.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 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.