linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Agner <stefan@agner.ch>
To: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Cc: dwmw2@infradead.org, computersforpeace@gmail.com,
	mark.rutland@arm.com, boris.brezillon@free-electrons.com,
	aaron@tastycactus.com, marb@ixxat.de, pawel.moll@arm.com,
	ijc+devicetree@hellion.org.uk, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, robh+dt@kernel.org,
	linux-mtd@lists.infradead.org, kernel@pengutronix.de,
	galak@codeaurora.org, shawn.guo@linaro.org,
	linux-arm-kernel@lists.infradead.org, bpringlemeir@nbsps.com
Subject: Re: [PATCH v4 1/6] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
Date: Wed, 03 Jun 2015 17:05:16 +0200	[thread overview]
Message-ID: <b3b09b4b8c97cbfc88fa0d5fdc5e40cd@agner.ch> (raw)
In-Reply-To: <20150603130825.GA23991@breakpoint.cc>

On 2015-06-03 15:08, Sebastian Andrzej Siewior wrote:
> On 2015-03-25 17:28:24 [+0100], Stefan Agner wrote:
>> diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
>> new file mode 100644
>> index 0000000..23c1510
>> --- /dev/null
>> +++ b/drivers/mtd/nand/vf610_nfc.c
>> @@ -0,0 +1,686 @@
> …
>> +static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
>> +{
>> +	return readl(nfc->regs + reg);
>> +}
>> +
>> +static inline void vf610_nfc_write(struct vf610_nfc *nfc, uint reg, u32 val)
>> +{
>> +	writel(val, nfc->regs + reg);
>> +}
> …
> 
>> +static void vf610_nfc_send_command(struct vf610_nfc *nfc, u32 cmd_byte1,
>> +				   u32 cmd_code)
>> +{
>> +	void __iomem *reg = nfc->regs + NFC_FLASH_CMD2;
>> +	u32 tmp;
>> +
>> +	vf610_nfc_clear_status(nfc);
>> +
>> +	tmp = __raw_readl(reg);
>> +	tmp &= ~(CMD_BYTE1_MASK | CMD_CODE_MASK | BUFNO_MASK);
>> +	tmp |= cmd_byte1 << CMD_BYTE1_SHIFT;
>> +	tmp |= cmd_code << CMD_CODE_SHIFT;
>> +	__raw_writel(tmp, reg);
>> +}
> 
> Why readl() vs __raw_readl() dito for write?
> vf610_nfc_{read|write} is good since for PPC we would need out_be32()
> here instead.
> It would be nice if you could abstract the __raw_ once as well. And I am
> not sure if you need those at all since the former functions should work
> here just fine.

As Boris guessed correctly, the reason I used the raw variant was due to
performance improvements due to the barrier. However, I will use
{read|write}l_relaxed instead, which should offer endian abstraction
while not having the performance penalty due to extensive barriers...

--
Stefan


  reply	other threads:[~2015-06-03 15:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-25 16:28 [PATCH v4 0/6] mtd: nand: vf610_nfc: Freescale NFC for VF610 Stefan Agner
2015-03-25 16:28 ` [PATCH v4 1/6] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others Stefan Agner
2015-06-02  1:32   ` Brian Norris
2015-06-02  9:01     ` Stefan Agner
2015-06-03  8:10   ` Sebastian Andrzej Siewior
2015-06-03  9:45     ` Stefan Agner
2015-06-03 12:03       ` Sebastian Andrzej Siewior
2015-06-03 15:09         ` Stefan Agner
2015-06-09 20:05           ` Sebastian Andrzej Siewior
2015-06-03 13:08   ` Sebastian Andrzej Siewior
2015-06-03 15:05     ` Stefan Agner [this message]
2015-06-09 20:07       ` Sebastian Andrzej Siewior
2015-06-09 20:31         ` Stefan Agner
2015-06-12 19:44           ` Sebastian Andrzej Siewior
2015-06-17 13:02         ` Stefan Agner
2015-06-18 18:27           ` Sebastian Andrzej Siewior
2015-03-25 16:28 ` [PATCH v4 2/6] mtd: nand: vf610_nfc: add hardware BCH-ECC support Stefan Agner
2015-03-25 16:28 ` [PATCH v4 3/6] mtd: nand: vf610_nfc: add device tree bindings Stefan Agner
2015-03-25 16:28 ` [PATCH v4 4/6] ARM: vf610: enable NAND Flash Controller Stefan Agner
2015-03-25 16:28 ` [PATCH v4 5/6] ARM: dts: vf610: add NAND flash controller peripherial Stefan Agner
2015-03-25 16:28 ` [PATCH v4 6/6] ARM: dts: vf-colibri: enable NAND flash controller 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=b3b09b4b8c97cbfc88fa0d5fdc5e40cd@agner.ch \
    --to=stefan@agner.ch \
    --cc=aaron@tastycactus.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=bpringlemeir@nbsps.com \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marb@ixxat.de \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=sebastian@breakpoint.cc \
    --cc=shawn.guo@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).