Hi, > From: Ezequiel Garcia [mailto:ezequiel.garcia@xxxxxxxxxxxxxxxxxx] [...] > FWIW, I have a Beaglebone with a 16-bit bus NAND attached to it. > > Coincidentally, yesterday I was doing some tests as I'm ramping up the > NAND and I found that weird double nand_scan_ident() call. > The whole thing looks buggy to me, so I'm happy to help, review, test > and patches to take care of this. > Yes, thanks .. that would be of great help.. And may be your experience of Atmel drivers would help me here.. *Correct, should not be double calls to nand_scan_ident()..* But there is a constrain in nand_base.c, that it does not allow ONFI page reading in x16 mode.. So how to overcome that.. I see the similar implementation in your ATMEL driver, it does not use NAND_BUSWIDTH_AUTO so how do you perform ONFI read for x16 devices ? drivers/mtd/nand/atmel_nand.c @@atmel_nand_probe() /* here you move to x16 mode based on your DT or platform data */ if (host->board.bus_width_16) /* 16-bit bus width */ nand_chip->options |= NAND_BUSWIDTH_16; /* And then you call nand_scan_ident */ /* first scan to find the device and get the page size */ if (nand_scan_ident(mtd, 1, NULL)) { res = -ENXIO; goto err_scan_ident; } Wouldn't this fail, _unless_ your device is listed in nand_flash_id[] ? because it would not be able to read ONFI params.. Refer below commit.. commit 0ce82b7f7b7373b16ecf7b5725e21e2975204500 Author: Matthieu CASTET <matthieu.castet@xxxxxxxxxx> AuthorDate: 2013-01-16 Thanks for pitching in, this would help me to understand this better. > I'm using some TI SDK with some ancient v3.2.x (with no git history!), > but from this discussion it seems the issue is still present in > mainline. > Aah sorry, then you might have some problem here in rebasing the patches. But still if you can, thanks much .. with regards, pekon ��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
