public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Masahiro Yamada <yamada.m@jp.panasonic.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] mtd: nand: allow to skip BBT scanning during NAND inititialization
Date: Wed, 05 Nov 2014 12:39:45 +0900	[thread overview]
Message-ID: <20141105123945.CB20.AA925319@jp.panasonic.com> (raw)
In-Reply-To: <1415050859.23458.266.camel@snotra.buserror.net>

Hi Scott,


On Mon, 3 Nov 2014 15:40:59 -0600
Scott Wood <scottwood@freescale.com> wrote:

> On Thu, 2014-10-23 at 21:25 +0900, Masahiro Yamada wrote:
> > Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14),
> > chip->scan_bbt() is called at the end of nand_scan_tail().
> > It means the first read access happens immediately after the generic
> > NAND initialization process.
> > 
> > It causes a problem to some SoCs of UniPhier platform because some of
> > their register values need to be fixed up after the general
> > initialization procedure has been finished.  Otherwise, read asccess
> > fails.  Such a fix-up is SoC-specific enough to be written in a board
> > file rather than in driver code.
> > 
> > One of possible and clean enough ways to work around this issue is
> > postpone the BBT scanning until necessary fix-up is done in
> > board_late_init() or somewhere else.
> > 
> > CONFIG_MTD_NAND_SKIP_BBTSCAN, if enabled, allows to skip the BBT
> > scanning at the end of nand_scan_tail().
> > 
> > Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
> > Cc: Scott Wood <scottwood@freescale.com>
> > ---
> 
> Rotislav Lisovy already posted a patch to fix the regression, but I
> don't think you should be relying on this for your problem.

If you are willing to apply Rostislav's patch, I am fine.
There is no reason (at least) for me to insist on this patch any more.


>Why don't
> you want to put SoC-specific knowledge in the driver?


There are two reasons:

[1] This problem occurs on some of Panasonic UniPhier SoCs.
Denali driver (drivers/mtd/nand/denali.c) is used by SOCFPGA
as well as UniPhier.
I do not think it is a good idea to put dirty and SoC-specific
work around into the driver.

[2] There is no good place to insert a callback to an SoC file.
I need to write parameters such as page_size to hardware registers.
(You can see my code, nand_denali_fixup() in arch/arm/cpu/armv7/uniphier/board_late_init.c)

   The NAND init procedure of U-Boot is like this:

   (1) board_nand_init()   (drivers/mtd/nand/denali.c)
   (2) nand_scan_ident()   (drivers/mtd/nand/nand_base.c)
   (3) nand_scan_tail()    (drivers/mtd/nand/nand_base.c)



  (2) detects the device size and set mtd->write_size,
   mtd->erase_size, mtd->oob_size.
  I need to set these values to the Denali hardware, but
  the Denali driver code is called at (1) which is called
  before the detection of the device size.

   In Linux, nand_scan_ident() and nand_scan_tail() are called
   from each of NAND drivers, so we can use the values which
   have been set during nand_scan_ident().

   In U-Boot, I think it is impossible.




> At least make it
> a callback from the driver to an SoC file, rather than hoping the NAND
> won't be touched for a certain amount of time after the driver has told
> the subsystem "I'm here and ready to be used".
> 
> -Scott
> 

Best Regards
Masahiro Yamada

  parent reply	other threads:[~2014-11-05  3:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-23 12:25 [U-Boot] [PATCH v2] mtd: nand: allow to skip BBT scanning during NAND inititialization Masahiro Yamada
2014-11-03 21:40 ` Scott Wood
2014-11-03 21:47   ` Scott Wood
2014-11-05  3:39   ` Masahiro Yamada [this message]
2014-11-05  5:45     ` Scott Wood
2014-11-11 13:10       ` Masahiro Yamada

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=20141105123945.CB20.AA925319@jp.panasonic.com \
    --to=yamada.m@jp.panasonic.com \
    --cc=u-boot@lists.denx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox