Re: DENALI: can't detect NAND chip

[Boris Brezillon <boris.brezillon@bootlin.com>]

On Mon, 4 Jun 2018 21:58:54 +0200
Richard Weinberger <richard.weinberger@gmail.com> wrote:

> On Tue, Mar 13, 2018 at 9:48 AM, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
> > 2018-03-12 23:29 GMT+09:00 Philipp Rosenberger <p.rosenberger@linutronix.de>:  
> >> Hi,
> >>
> >> I'm currently porting Linux 4.14 to a Altera Cyclone V based board. The
> >> Denali NAND Driver isn't able to detect the NAND chip Micron MT29F4G08) correctly.
> >>
> >> [    0.862242] nand: device found, Manufacturer ID: 0x00, Chip ID: 0x2c
> >> [    0.868604] nand: Unknown denali-nand
> >> [    0.872253] nand: bus width 8 instead of 16 bits
> >> [    0.876899] nand: No NAND device found
> >> [    0.880688] denali-nand-dt: probe of ff900000.nand failed with error -22
> >>
> >> The correct ManufID is 0x2c and the DevID is 0xdc. Currently we are
> >> running a 4.1 kernel with the "old" denali driver without this problem.
> >> While researching the issue I found the following Mail in the
> >> Rocketboards archive, which seems to be the same issue.
> >>
> >> https://lists.rocketboards.org/pipermail/rfi/2017-September/003627.html
> >>
> >>
> >> We also tested Linux 4.16-rc5 without any additional patches with the same behavior.
> >>  
> >
> >
> > I got a similar report before for SOCFPGA.
> >
> > The reporter found a problem in his clock setting:
> > http://linux-mtd.infradead.narkive.com/MMBF5wzm/nand-denali-issue-with-4-13  
> 
> I got access to that board and did initial debugging of the problem.
> 
> The problem seems to be that after your rework the NAND timings get
> derived from the NAND clock.
> When I make denali_setup_data_interface() a NOP, the NAND is being
> detected and works.
> 
> Can it be that the function does not calculate the timings correctly
> in all cases?
> Please see the following debug output for good and bad case.
> 
> bad case:
> [    0.946757] XXX: denali clk rate: 0x2faf080
> [    0.950932] XXX: denali clk phase: 0x0
> [    0.954671] XXX: denali clk accuracy: 0x0
> [    0.958920] denali-nand-dt ff900000.nand: clk_x_rate: 0x2faf080
> [    0.964846] denali-nand-dt ff900000.nand: Dump timing register values:
> [    0.964846] acc_clks: 2, re_2_we: 10, re_2_re: 10
> [    0.964846] we_2_re: 25, addr_2_data: 20, rdwr_en_lo_cnt: 4
> [    0.964846] rdwr_en_hi_cnt: 2, cs_setup_cnt: 3
> 
> good case:
> [    0.961061] XXX: denali clk rate: 0x2faf080
> [    0.965231] XXX: denali clk phase: 0x0
> [    0.968967] XXX: denali clk accuracy: 0x0
> [    0.973031] denali-nand-dt ff900000.nand: Dump timing register values:
> [    0.973031] acc_clks: 4, re_2_we: 20, re_2_re: 20
> [    0.973031] we_2_re: 12, addr_2_data: 14, rdwr_en_lo_cnt: 2
> [    0.973031] rdwr_en_hi_cnt: 2, cs_setup_cnt: 2
> 
> Does this ring a bell?
> 

Could it be that clk_get_rate() returns an invalid value? Looks like
all good timings are almost equal to bad timings multiplied by 2, so
maybe the ->recalc_rate() method of clk driver returns freq / 2 instead
of freq.