From: Ray Jui <rjui@broadcom.com>
To: Brian Norris <computersforpeace@gmail.com>,
<linux-mtd@lists.infradead.org>
Cc: Clay McClure <clay@daemons.net>,
Scott Branden <sbranden@broadcom.com>,
<bcm-kernel-feedback-list@broadcom.com>
Subject: Re: [PATCH] mtd: brcmnand: clean up flash cache for parameter pages
Date: Tue, 17 Nov 2015 17:06:53 -0800 [thread overview]
Message-ID: <564BCF2D.7060909@broadcom.com> (raw)
In-Reply-To: <1447721773-18417-1-git-send-email-computersforpeace@gmail.com>
On 11/16/2015 4:56 PM, Brian Norris wrote:
> The read_byte() handling for accessing the flash cache has some awkward
> swapping being done in the read_byte() function. Let's just make this a
> byte array, and do the swapping with the word-level macros during the
> initial buffer copy.
>
> This is just a refactoring patch, with no (intended) functional change.
>
> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
> Cc: Clay McClure <clay@daemons.net>
> Cc: Ray Jui <rjui@broadcom.com>
> Cc: Scott Branden <sbranden@broadcom.com>
> Cc: <bcm-kernel-feedback-list@broadcom.com>
> Tested-by: Clay McClure <clay@daemons.net>
> ---
> I wanted to get this out there as a proper patch, since there was some
> confusion on the previous thread in which this appeared.
>
> This does *not* fix the bug reported by Cyrille in the thread "mtd: brcmnand:
> Fix NAND_CMD_PARAM byte order". There is a candidate patch which fixes this:
>
> http://patchwork.ozlabs.org/patch/535330/
>
> But I'm awaiting a better explanation from Broadcom folks before I
> respin/accept anything like that.
Yeah still on our to-do list. Will find time to talk to our ASIC engineer.
>
> drivers/mtd/nand/brcmnand/brcmnand.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c
> index 2a437c7ed175..0f43bc95ece4 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -134,7 +134,7 @@ struct brcmnand_controller {
> dma_addr_t dma_pa;
>
> /* in-memory cache of the FLASH_CACHE, used only for some commands */
> - u32 flash_cache[FC_WORDS];
> + u8 flash_cache[FC_BYTES];
>
> /* Controller revision details */
> const u16 *reg_offsets;
> @@ -1188,6 +1188,8 @@ static void brcmnand_cmdfunc(struct mtd_info *mtd, unsigned command,
>
> if (native_cmd == CMD_PARAMETER_READ ||
> native_cmd == CMD_PARAMETER_CHANGE_COL) {
> + /* Copy flash cache word-wise */
> + u32 *flash_cache = (u32 *)ctrl->flash_cache;
> int i;
>
> brcmnand_soc_data_bus_prepare(ctrl->soc);
> @@ -1197,7 +1199,11 @@ static void brcmnand_cmdfunc(struct mtd_info *mtd, unsigned command,
> * SECTOR_SIZE_1K may invalidate it
> */
> for (i = 0; i < FC_WORDS; i++)
> - ctrl->flash_cache[i] = brcmnand_read_fc(ctrl, i);
> + /*
> + * Flash cache is big endian for parameter pages, at
> + * least on STB SoCs
> + */
> + flash_cache[i] = be32_to_cpu(brcmnand_read_fc(ctrl, i));
>
> brcmnand_soc_data_bus_unprepare(ctrl->soc);
>
> @@ -1250,8 +1256,7 @@ static uint8_t brcmnand_read_byte(struct mtd_info *mtd)
> if (host->last_byte > 0 && offs == 0)
> chip->cmdfunc(mtd, NAND_CMD_RNDOUT, addr, -1);
>
> - ret = ctrl->flash_cache[offs >> 2] >>
> - (24 - ((offs & 0x03) << 3));
> + ret = ctrl->flash_cache[offs];
> break;
> case NAND_CMD_GET_FEATURES:
> if (host->last_byte >= ONFI_SUBFEATURE_PARAM_LEN) {
>
"Tested" on Cygnus, and as expected, nothing changes. NAND still works
and ONFI still fails.
Thanks,
Ray
next prev parent reply other threads:[~2015-11-18 1:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-17 0:56 [PATCH] mtd: brcmnand: clean up flash cache for parameter pages Brian Norris
2015-11-18 1:06 ` Ray Jui [this message]
2015-11-18 22:29 ` Brian Norris
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=564BCF2D.7060909@broadcom.com \
--to=rjui@broadcom.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=clay@daemons.net \
--cc=computersforpeace@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=sbranden@broadcom.com \
/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.