From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Alan Cox <alan@linux.intel.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] goldfish: NAND flash driver
Date: Sat, 26 Jan 2013 22:10:07 +0100 [thread overview]
Message-ID: <871ud7odlc.fsf@free.fr> (raw)
In-Reply-To: 20130123221245.2a3021ce@bob.linux.org.uk
Alan Cox <alan@linux.intel.com> writes:
>> > + writel(cmdp, base + NAND_COMMAND);
>> What guarantee do you have on the order of writes here ? Isn't a
>> write barrier required here ?
>
> Its a virtual platform powered by an emulator - so no barriers needed
> that I can see.
OK.
...zip...
>> > + if (goldfish_nand_cmd_with_params(mtd, cmd, addr, len,
>> > ptr, &rv)) {
>> > + writel(mtd - nand->mtd, base + NAND_DEV);
>> > + writel((u32)(addr >> 32), base + NAND_ADDR_HIGH);
>> > + writel((u32)addr, base + NAND_ADDR_LOW);
>> > + writel(len, base + NAND_TRANSFER_SIZE);
>> > + writel((u32)ptr, base + NAND_DATA);
>> > + writel(cmd, base + NAND_COMMAND);
>> > + rv = readl(base + NAND_RESULT);
>> Same question here on the order of the read wrt to previous writes.
>
> reads wont pass write anyway as its a sane platform.
Euh how so ? Assuming I understood correctly the "an emulated platform" part,
and the reads+writes end up in RAM, then an out-of-order execution core can
reorder independent read/writes. For example if base+NAND_RESULT is already in
cache, the core can perform the readl before the last writel, can't it ?
>> That looks weird (the __pa()) usage. I thought drivers should not use
>> __pa() directly.
>
> Will look at using dma_alloc_coherent for it.
Cool.
>> > + spin_lock_irqsave(&nand->lock, irq_flags);
>> Again same spin_lock question.
>
> I'm very wary of changing this but will take a look. It's actually not
> that important because its not real flash so it has unusually excellent
> performance via the emulator.
Sure.
BTW, I rechecked the patch a bit more, especially goldfish_nand_write_oob(). I
recall that a write_oob() function should first check the mtd_oob_ops.mode and
act depending on its value : MTD_OPS_PLACE_OOB, MTD_OPS_RAW, and
MTD_OPS_AUTO_OOB.
The action is different on each value (or -EINVAL returned if not handled).
Cheers.
--
Robert
PS: I have the responsiveness of a diseased turttle, and I don't expect things
will improve in the next days as I changed my home, so please be patient (or
convince my boss :))
next prev parent reply other threads:[~2013-01-26 21:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-21 23:45 [PATCH] goldfish: NAND flash driver Alan Cox
2013-01-23 20:41 ` Robert Jarzmik
2013-01-23 22:12 ` Alan Cox
2013-01-26 21:10 ` Robert Jarzmik [this message]
2013-01-27 13:10 ` Alan Cox
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=871ud7odlc.fsf@free.fr \
--to=robert.jarzmik@free.fr \
--cc=alan@linux.intel.com \
--cc=linux-mtd@lists.infradead.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.