All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huang Shijie <b32955@freescale.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
	linux-mtd@lists.infradead.org,
	David Woodhouse <David.Woodhouse@intel.com>
Subject: Re: [PATCH] mtd/nand: don't use {read,write}_buf for 8-bit transfers
Date: Fri, 1 Mar 2013 11:34:27 +0800	[thread overview]
Message-ID: <513021C3.2000503@freescale.com> (raw)
In-Reply-To: <20130228104819.GH22886@pengutronix.de>

于 2013年02月28日 18:48, Uwe Kleine-König 写道:
> On Thu, Feb 28, 2013 at 10:47:43AM +0800, Huang Shijie wrote:
>> 于 2013年02月27日 23:10, Uwe Kleine-König 写道:
>>> According to the Open NAND Flash Interface Specification (ONFI) Revision
>>> 3.1 "Parameters are always transferred on the lower 8-bits of the data
>>> bus." for the Get Features and Set Features commands.
>>>
>> yes. the set/get features should works in 8-bit.
>>
>> I have never met a 16-bit onfi nand yet. :)
>>
>>> So using read_buf and write_buf is wrong for 16-bit wide nand chips as
>>> they use I/O[15:0]. The Get Features command is easily fixed using 4
>>> times the read_byte callback. For Set Features error out as there is no
>> yes. for get features, it's easy to fix it.
>>> write_byte callback.
>> Most of the time, the nand controller will overwrite the write_buf hook...
>> I also think we need a write_byte callback.
> a default implementation could be something like that:
>
> 	static void nand_write_byte(struct mtd_info *mtd, uint8_t byte)
> 	{
> 		struct nand_chip *chip = mtd->priv;
>
> 		if (chip->options&  NAND_BUSWIDTH_16)
> 			chip->write_buf(mtd, (uint8_t[]){ byte, 0 }, 2);
> 		else
> 			chip->write_buf(mtd,&byte, 1);
> 	}
>
> (Is this the correct order in the array? Or might that depend on
> endianess?)
>
> Does this look right?
>
IMHO, the nand_write_byte() should not call the chip->write_buf() again. 
Since the ->write_buf() could
be the nand_write_buf16(). it makes a little mess.

In my opinion, the default nand_write_byte() hook could use the 
nand_write_buf() to  write just one byte;
and the nand controller can overwrite the nand_write_byte() hook if it 
could.
Of course, it's just a suggest.

thanks
Huang Shijie



> Alternatively something could be done with chip->cmd_ctrl (but it seems
> not all drivers implement this, e.g. mxc_nand doesn't).
>
> Best regards
> Uwe
>

  reply	other threads:[~2013-03-01  3:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-27 15:10 [PATCH] mtd/nand: don't use {read,write}_buf for 8-bit transfers Uwe Kleine-König
2013-02-28  2:47 ` Huang Shijie
2013-02-28  9:30   ` Uwe Kleine-König
2013-02-28 10:48   ` Uwe Kleine-König
2013-03-01  3:34     ` Huang Shijie [this message]
2013-03-01  8:50       ` Uwe Kleine-König
2013-03-01  8:59         ` Huang Shijie
2013-03-01  9:20   ` Matthieu CASTET
2013-03-01  9:59     ` Uwe Kleine-König
2013-03-01 14:00       ` Matthieu CASTET
2013-02-28 10:33 ` Huang Shijie

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=513021C3.2000503@freescale.com \
    --to=b32955@freescale.com \
    --cc=David.Woodhouse@intel.com \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=linux-mtd@lists.infradead.org \
    --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.