diff options
author | Masahiro Yamada <yamada.masahiro@socionext.com> | 2018-11-28 08:27:36 +0300 |
---|---|---|
committer | Miquel Raynal <miquel.raynal@bootlin.com> | 2018-12-07 12:38:28 +0300 |
commit | a2a05c2f530c663f6f23cee1e57dc6d45a11a9e9 (patch) | |
tree | 0b4764a99dbe13c500d06b49750e52882adc045f /drivers/mtd/bcm47xxpart.c | |
parent | 1b489effdb6dc16f63f254ee4c0d579929089e1d (diff) | |
download | linux-a2a05c2f530c663f6f23cee1e57dc6d45a11a9e9.tar.xz |
mtd: rawnand: denali: remove ->dev_ready() hook
The Denali NAND IP has no way to read out the current signal level
of the R/B# pin. Instead, denali_dev_ready() checks if the R/B#
transition has already happened. (The INTR__INT_ACT interrupt is
asserted at the rising edge of the R/B# pin.) It is not a correct
way to implement the ->dev_ready() hook.
In fact, it has a drawback; in the nand_scan_ident phase, the chip
detection iterates over maxchips until it fails to find a homogeneous
chip. For the last loop, nand_reset() fails if no chip is there.
If ->dev_ready hook exists, nand_command(_lp) calls nand_wait_ready()
after NAND_CMD_RESET. However, we know denali_dev_ready() never
returns 1 unless there exists a chip that toggles R/B# in that chip
select. Then, nand_wait_ready() just ends up with wasting 400 msec,
in the end, shows the "timeout while waiting for chip to become ready"
warning.
Let's remove the mis-implemented dev_ready hook, and fallback to
sending the NAND_CMD_STATUS and nand_wait_status_ready(), which
bails out more quickly.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Diffstat (limited to 'drivers/mtd/bcm47xxpart.c')
0 files changed, 0 insertions, 0 deletions