All of lore.kernel.org
 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
> 

WARNING: multiple messages have this Message-ID (diff)
From: computersforpeace@gmail.com (Brian Norris)
To: linux-arm-kernel@lists.infradead.org
Subject: [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
> 

WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <computersforpeace@gmail.com>
To: Anup Patel <anup.patel@broadcom.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Device Tree <devicetree@vger.kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Scott Branden <sbranden@broadcom.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Kumar Gala <galak@codeaurora.org>,
	Will Deacon <will.deacon@arm.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Ray Jui <rjui@broadcom.com>,
	Vikram Prakash <vikramp@broadcom.com>,
	Rob Herring <robh+dt@kernel.org>,
	Linux MTD <linux-mtd@lists.infradead.org>,
	Sandeep Tripathy <tripathy@broadcom.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Pramod KUMAR <pramodku@broadcom.com>,
	BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Linux ARM Kernel <linux-arm-kernel@lists.infradead.org>
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: 24+ 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 ` Anup Patel
2015-10-30  6:59 ` 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   ` 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  6:59   ` Anup Patel
2015-10-30  6:59   ` Anup Patel
2015-10-30 19:47   ` Brian Norris [this message]
2015-10-30 19:47     ` Brian Norris
2015-10-30 19:47     ` Brian Norris
2015-11-02 17:06     ` Anup Patel
2015-11-02 17:06       ` Anup Patel
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  6:59   ` Anup Patel
2015-10-30 19:31 ` [PATCH v5 0/3] NAND support for Broadcom NS2 SoC Brian Norris
2015-10-30 19:31   ` Brian Norris
2015-10-30 19:31   ` Brian Norris
2015-11-02 17:02   ` Anup Patel
2015-11-02 17:02     ` Anup Patel
2015-11-03  8:12   ` Anup Patel
2015-11-03  8:12     ` 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 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.