All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: linux-mtd@lists.infradead.org, Pekon Gupta <pekon@ti.com>,
	u.kleine-koenig@pengutronix.de
Subject: Re: [PATCH 1/2] mtd: nand: force NAND_CMD_READID onto 8-bit bus
Date: Thu, 30 Jan 2014 09:17:04 -0300	[thread overview]
Message-ID: <20140130121704.GA11285@localhost> (raw)
In-Reply-To: <1391033909-6563-1-git-send-email-computersforpeace@gmail.com>

On Wed, Jan 29, 2014 at 02:18:28PM -0800, Brian Norris wrote:
> The NAND command helpers tend to automatically shift the column address
> for x16 bus devices, since most commands expect a word address, not a
> byte address. The Read ID command, however, expects an 8-bit address
> (i.e., 0x00, 0x20, or 0x40 should not be translated to 0x00, 0x10, or
> 0x20).
> 
> This fixes the column address for a few drivers which imitate the
> nand_base defaults. Note that I don't touch sh_flctl.c, since it already
> handles this problem slightly differently (note its comment "READID is
> always performed using an 8-bit bus").
> 
> I have not tested this patch, as I only have x8 parts up for testing at
> this point. Hopefully that can change soon...
> 
> Signed-off-by: Brian Norris <computersforpeace@gmail.com>

I applied both patches and tested on my AM335x board (omap2-nand driver).
Both 8-bit and 16-bit devices get ONFI-probed and pass a nandtest round.

Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

Also, checked that without these patches, the 16-bit device would be ID-probed,
but not detected as ONFI-compliant.

[..]
> +
> +/**
> + * Check if the opcode's address should be sent only on the lower 8 bits
> + * @command: opcode to check
> + */
> +static inline int nand_opcode_8bits(unsigned int command)
> +{
> +	return command == NAND_CMD_READID;
> +}
> +
>  #endif /* __LINUX_MTD_NAND_H */

With the introduction of this function, I think all the problems we've
discussed. The solution looks good to me so. Nice job!
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

  parent reply	other threads:[~2014-01-30 12:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-29 22:18 [PATCH 1/2] mtd: nand: force NAND_CMD_READID onto 8-bit bus Brian Norris
2014-01-29 22:18 ` [PATCH 2/2] mtd: nand: don't use read_buf for 8-bit ONFI transfers Brian Norris
2014-01-30 12:20   ` Ezequiel Garcia
2014-01-30 12:17 ` Ezequiel Garcia [this message]
2014-01-30 18:00   ` [PATCH 1/2] mtd: nand: force NAND_CMD_READID onto 8-bit bus Brian Norris
2014-01-30 19:17 ` Gupta, Pekon
2014-01-30 19:51   ` Ezequiel Garcia
2014-01-30 20:18     ` Gupta, Pekon
2014-01-30 20:47       ` Brian Norris
2014-01-31  6:55         ` Gupta, Pekon
2014-01-31 18:04           ` Brian Norris
2014-01-30 20:39     ` 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=20140130121704.GA11285@localhost \
    --to=ezequiel.garcia@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=pekon@ti.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /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.