All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 3/4] mtd: nand: add Freescale NFC driver
Date: Wed, 13 Aug 2014 15:41:32 -0500	[thread overview]
Message-ID: <1407962492.7427.168.camel@snotra.buserror.net> (raw)
In-Reply-To: <87wqadl3h6.fsf@nbsps.com>

On Tue, 2014-08-12 at 18:58 -0400, Bill Pringlemeir wrote:
> On 12 Aug 2014, scottwood at freescale.com wrote:
> 
> > On Tue, 2014-08-12 at 23:13 +0200, Stefan Agner wrote:
> >> Am 2014-08-12 00:33, schrieb Scott Wood:
> >>> You should always be using raw I/O accessors.  If the intent is to
> >>> bypass I/O ordering for certain registers, the raw accessors should
> >>> already be skipping that.
> 
> >> Ok, will do.
> 
> > Sorry, the above should say "always be using I/O accesors", not always
> > raw ones.
> 
> This is probably because of me.  There are lines like this for
> configuration,
> 
>         /* Set configuration register. */
>         nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_ADDR_AUTO_INCR_BIT);
>         nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_BUFNO_AUTO_INCR_BIT);
>         nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_BOOT_MODE_BIT);
>         nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_DMA_REQ_BIT);
>         nfc_set(mtd, NFC_FLASH_CONFIG, CONFIG_FAST_FLASH_BIT);
> 
> If you use some sort of 'volatile', you are saying to the compiler that
> these lines are *not*,
> 
>        ldr r0, [r1, #CONFIG]    # read previous value
>        ldr r2, =~MASK
>        orr r0, #FAST_FLASH_BIT  # set one bit.
>        and r0, r2               # clear all bits at once.
>        str r0, [r1, #CONFIG]    # write it back.
> 
> Instead it will change into five different load/modify/stores.  The
> memory itself is just like SRAM except a few registers that are actually
> volatile; ie changed via the hardware.

If this is performance-critical then it would be best to modify the code
to explicitly do one read from I/O (if you can't know in advance what
the existing value will be), clear all the bits you're going to clear,
then have one explicit write back to the I/O device -- rather than
treating it as ordinary memory for the compiler to optimize accesses to.

If nothing else, it makes the code clearer to make I/O accesses
explicit, and reduces the likelihood that people see I/O accesses
without accessors and go on to do the same in some other less safe
circumstance.

-Scott

  parent reply	other threads:[~2014-08-13 20:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-06  8:59 [U-Boot] [PATCH 0/4] arm: vf610: add NAND flash support Stefan Agner
2014-08-06  8:59 ` [U-Boot] [PATCH 1/4] arm: vf610: add NFC pin mux Stefan Agner
2014-08-30 15:14   ` [U-Boot] [U-Boot,1/4] " Tom Rini
2014-08-06  8:59 ` [U-Boot] [PATCH 2/4] arm: vf610: add NFC clock support Stefan Agner
2014-08-30 15:14   ` [U-Boot] [U-Boot,2/4] " Tom Rini
2014-08-06  8:59 ` [U-Boot] [PATCH 3/4] mtd: nand: add Freescale NFC driver Stefan Agner
2014-08-06 23:01   ` Bill Pringlemeir
2014-08-11 22:33   ` Scott Wood
2014-08-12 21:13     ` Stefan Agner
2014-08-12 22:17       ` Scott Wood
2014-08-12 22:58         ` Bill Pringlemeir
2014-08-13  8:13           ` Stefan Agner
2014-08-13 11:20           ` Stefan Agner
2014-08-13 15:14             ` Bill Pringlemeir
2014-08-13 16:27               ` Stefan Agner
2014-08-13 17:11                 ` Bill Pringlemeir
2014-08-13 20:32             ` Scott Wood
2014-08-13 20:41           ` Scott Wood [this message]
2014-08-13 21:44             ` Bill Pringlemeir
2014-08-13 22:54               ` Scott Wood
2014-08-14 14:26                 ` Bill Pringlemeir
2014-08-06  8:59 ` [U-Boot] [PATCH 4/4] arm: vf610: add NAND support for vf610twr Stefan Agner

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=1407962492.7427.168.camel@snotra.buserror.net \
    --to=scottwood@freescale.com \
    --cc=u-boot@lists.denx.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.