All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@keyaccess.nl>
To: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: Takashi Iwai <tiwai@suse.de>, Alsa-devel <alsa-devel@alsa-project.org>
Subject: Re: [PATCH] wss_lib: do not mess mixer settings during probe
Date: Mon, 25 Aug 2008 02:23:52 +0200	[thread overview]
Message-ID: <48B1FB98.2090401@keyaccess.nl> (raw)
In-Reply-To: <48B1E2C0.8000105@keyaccess.nl>

On 25-08-08 00:37, Rene Herman wrote:

> On 24-08-08 21:48, Krzysztof Helt wrote:
> 
>> From the Documentation/memory-barriers.txt
>> "
>> (*) inX(), outX():
>> ...
>>     They are guaranteed to be fully ordered with respect to each other.
>>
>>     They are not guaranteed to be fully ordered with respect to other 
>> types of
>>      memory and I/O operation.
>> ...
>> "
>>
>> No barriers are needed in this case. 
> 
> On x86 certainly not and I would expect these barriers are there for 
> cases/architectures where inb() and outb() are redefined to memory 
> mapped I/O or there would just be no point at all.
> 
> In that case, the first outb() writes an index and we'd better make sure 
> that it hits the hardware before we write the value. Hence my suspicion 
> that if at all, the mb() should be in between.
> 
> No idea who added those and why...

Well, thinking about this more, I guess it actually makes some sense.

No need for a wmb() in between because we know that the outbs are fully 
ordered (supposedly even when redefined) but being a general accessor 
function we pretend we don't know that the next access is going to be 
through an inb/outb again -- we are supposedly being careful to allow 
combining using this accessor with direct MMIO access on other and/or 
virtualized architectures.

That is... as far as I understand this in the first place. Takashi or 
Jaroslav, do you perhaps remember barriers being added to cs4231_lib() 
and why? Could we just get rid of them?

(context was snipped, but this question is about the mb() in 
snd_cs4231_dout; snd_wss_dout in the new wss_lib form).

Rene.

  reply	other threads:[~2008-08-25  0:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-24 16:08 [PATCH] wss_lib: do not mess mixer settings during probe Krzysztof Helt
2008-08-24 18:36 ` Rene Herman
2008-08-24 19:48   ` Krzysztof Helt
2008-08-24 22:37     ` Rene Herman
2008-08-25  0:23       ` Rene Herman [this message]
2008-08-25  5:45       ` Takashi Iwai
2008-08-25  6:19 ` Takashi Iwai

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=48B1FB98.2090401@keyaccess.nl \
    --to=rene.herman@keyaccess.nl \
    --cc=alsa-devel@alsa-project.org \
    --cc=krzysztof.h1@poczta.fm \
    --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.