All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Lord <liml@rtr.ca>
To: Grant Grundler <grundler@google.com>
Cc: Jeff Garzik <jgarzik@pobox.com>,
	IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: [PATCH 05/07] sata_mv: mv_fill_sg fixes
Date: Sun, 01 Feb 2009 16:46:14 -0500	[thread overview]
Message-ID: <49861826.4060004@rtr.ca> (raw)
In-Reply-To: <da824cf30902011255s52878598v5f1e98746865bcab@mail.gmail.com>

Grant Grundler wrote:
> On Fri, Jan 30, 2009 at 3:50 PM, Mark Lord <liml@rtr.ca> wrote:
..
>>
>>        if (likely(last_sg))
>>                last_sg->flags_size |= cpu_to_le32(EPRD_FLAG_END_OF_TBL);
>> +       mb(); /* ensure data structure is visible to the chipset */
> 
> It's not obvious to me what you are racing against here.
> Normally the mb() is to prevent the above store from getting executed
> *after* some MMIO read or write that would tell the chip to read the
> flags_size field (or anything recently stored in that data structure).
> 
> I guess I'm asking for the comment to indicate which MMIO write it's
> racing with.
..

It's exactly the same as the generic routine in libata-sff,
which has a mb() in the same place for the same reason:
To ensure the PRD table is visible to the chipset
before we trigger the I/O operation.

Pretty standard.

  reply	other threads:[~2009-02-01 21:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-30 23:45 [PATCH 00/07] sata_mv: ATAPI patchset Mark Lord
2009-01-30 23:46 ` [PATCH 01/07] sata_mv: cleanup chipset GENeration FLAGS Mark Lord
2009-01-30 23:47   ` [PATCH 02/07] sata_mv: rearrange mv_start_dma() and friends Mark Lord
2009-01-30 23:48     ` [PATCH 03/07] sata_mv: restructure mv_qc_issue Mark Lord
2009-01-30 23:49       ` [PATCH 04/07] sata_mv: update ata_qc_from_tag Mark Lord
2009-01-30 23:50         ` [PATCH 05/07] sata_mv: mv_fill_sg fixes Mark Lord
2009-01-30 23:51           ` [PATCH 06/07] sata_mv: introduce support for ATAPI devices Mark Lord
2009-01-30 23:52             ` [PATCH 07/07] sata_mv: optimize use of mv_edma_cfg Mark Lord
2009-02-03  4:19             ` [PATCH 06/07] sata_mv: introduce support for ATAPI devices Jeff Garzik
2009-02-01 20:55           ` [PATCH 05/07] sata_mv: mv_fill_sg fixes Grant Grundler
2009-02-01 21:46             ` Mark Lord [this message]
2009-02-01 21:50             ` [PATCH 05/07] sata_mv: mv_fill_sg fixes v2 Mark Lord
2009-01-31  2:40         ` [PATCH 08/07] sata_mv: remove leftovers Mark Lord
2009-02-01 20:49         ` [PATCH 04/07] sata_mv: update ata_qc_from_tag Grant Grundler
2009-02-01 21:45           ` Mark Lord
2009-02-03  4:14       ` [PATCH 03/07] sata_mv: restructure mv_qc_issue Jeff Garzik
2009-02-03  4:12   ` [PATCH 01/07] sata_mv: cleanup chipset GENeration FLAGS Jeff Garzik
2009-01-31  0:04 ` [PATCH 00/07] sata_mv: ATAPI patchset Mark Lord

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=49861826.4060004@rtr.ca \
    --to=liml@rtr.ca \
    --cc=grundler@google.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@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 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.