linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Anup Patel <anup.patel@broadcom.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Linux MTD <linux-mtd@lists.infradead.org>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>, Ray Jui <rjui@broadcom.com>,
	Scott Branden <sbranden@broadcom.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Pramod KUMAR <pramodku@broadcom.com>,
	Vikram Prakash <vikramp@broadcom.com>,
	Sandeep Tripathy <tripathy@broadcom.com>,
	Linux ARM Kernel <linux-arm-kernel@lists.infradead.org>,
	Device Tree <devicetree@vger.kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>
Subject: Re: [PATCH v5 2/3] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
Date: Fri, 30 Oct 2015 12:47:44 -0700	[thread overview]
Message-ID: <20151030194744.GJ13239@google.com> (raw)
In-Reply-To: <1446188361-15146-3-git-send-email-anup.patel@broadcom.com>

On Fri, Oct 30, 2015 at 12:29:20PM +0530, Anup Patel wrote:
> Just like other NAND controllers,

^^ That part isn't strictly true. While READ ID data only comes out on
the lower 8 bits, that doesn't *actually* mean you can't get valid data
from a 16-bit bus in general; you just have to drop the upper 8 bits. That's
what these two commits did for read ID and parameter page read commands:

commit 3dad2344e92c6e1aeae42df1c4824f307c51bcc7
Author: Brian Norris <computersforpeace@gmail.com>
Date:   Wed Jan 29 14:08:12 2014 -0800

    mtd: nand: force NAND_CMD_READID onto 8-bit bus

commit bd9c6e99b58255b9de1982711ac9487c9a2f18be
Author: Brian Norris <computersforpeace@gmail.com>
Date:   Fri Nov 29 22:04:28 2013 -0800

    mtd: nand: don't use read_buf for 8-bit ONFI transfers

> the NAND READID command only works
> in 8bit mode for all versions of BRCMNAND controller.

But I presume *this* statement is actually true. This NAND controller doesn't
exactly give us a fully-flexible READID / read_byte / read_word command, as it
works at a higher level than that (although LOW_LEVEL_OP gives us this
flexibility now). I could imagine (though I never tested 16-bit NAND) that
16-bit READID is broken.

BTW, did you ask the HW designer about this? It'd be nice to be 100% sure.

Anyway, as I noted on the cover letter, I've pushed this patch.

Thanks,
Brian

> This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
> before doing nand_scan_ident() to ensure that BRCMNAND controller
> is in 8bit mode when NAND READID command is issued.
> 
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> Reviewed-by: Ray Jui <rjui@broadcom.com>
> Reviewed-by: Scott Branden <sbranden@broadcom.com>
> ---
>  drivers/mtd/nand/brcmnand/brcmnand.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c
> index dda96fa..b410527 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -1912,6 +1912,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
>  	struct mtd_info *mtd;
>  	struct nand_chip *chip;
>  	int ret;
> +	u16 cfg_offs;
>  	struct mtd_part_parser_data ppdata = { .of_node = dn };
>  
>  	ret = of_property_read_u32(dn, "reg", &host->cs);
> @@ -1954,6 +1955,15 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
>  
>  	chip->controller = &ctrl->controller;
>  
> +	/*
> +	 * The bootloader might have configured 16bit mode but
> +	 * NAND READID command only works in 8bit mode. We force
> +	 * 8bit mode here to ensure that NAND READID commands works.
> +	 */
> +	cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
> +	nand_writereg(ctrl, cfg_offs,
> +		      nand_readreg(ctrl, cfg_offs) & ~CFG_BUS_WIDTH);
> +
>  	if (nand_scan_ident(mtd, 1, NULL))
>  		return -ENXIO;
>  
> -- 
> 1.9.1
> 

  reply	other threads:[~2015-10-30 19:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-30  6:59 [PATCH v5 0/3] NAND support for Broadcom NS2 SoC Anup Patel
2015-10-30  6:59 ` [PATCH v5 1/3] mtd: brcmnand: factor out CFG and CFG_EXT bitfields Anup Patel
2015-10-30  6:59 ` [PATCH v5 2/3] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident() Anup Patel
2015-10-30 19:47   ` Brian Norris [this message]
2015-11-02 17:06     ` Anup Patel
2015-10-30  6:59 ` [PATCH v5 3/3] arm64: dts: Add BRCM IPROC NAND DT node for NS2 Anup Patel
2015-10-30 19:31 ` [PATCH v5 0/3] NAND support for Broadcom NS2 SoC Brian Norris
2015-11-02 17:02   ` Anup Patel
2015-11-03  8:12   ` Anup Patel

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=20151030194744.GJ13239@google.com \
    --to=computersforpeace@gmail.com \
    --cc=anup.patel@broadcom.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=f.fainelli@gmail.com \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=pramodku@broadcom.com \
    --cc=rjui@broadcom.com \
    --cc=robh+dt@kernel.org \
    --cc=sbranden@broadcom.com \
    --cc=sudeep.holla@arm.com \
    --cc=tripathy@broadcom.com \
    --cc=vikramp@broadcom.com \
    --cc=will.deacon@arm.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 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).