Re: [PATCH v2 0/5] Assorted OMAP2 NAND clean-ups

[Ezequiel Garcia <ezequiel.garcia@free-electrons.com>]

Hey Pekon,

On Fri, Oct 25, 2013 at 08:48:36AM -0300, Ezequiel Garcia wrote:
> Pekon,
> 
> On Fri, Oct 25, 2013 at 11:15:57AM +0000, Gupta, Pekon wrote:
> > Hi,
> > 
> > > -----Original Message-----
> > > From: Ezequiel Garcia [mailto:ezequiel.garcia@free-electrons.com]
> > [...]
> > 
> > > Pekon, Brian: Do you think this solution might work for 8-bit and 16-bit
> > > devices?
> > > 
> > I think NAND_BUSWIDTH_AUTO (without GPMC changes) would fail in
> > following scenarios..
> > 
> > Case-1: configuring gpmc,device-width=1 from DT when using x16 device.
> 
> ... which is wrong. That's why we have a DT property to configure that.
> The GPMC *must* be properly configured.
> 
> > As your NAND driver is using NAND_BUSWIDTH_AUTO, it should
> > ignore this DT config, and based on ONFI params it should work as x16
> > 
> 
> Hm.. I don't think so. The auto-stuff is just for the NAND driver, not
> for the memory controller. I don't know much about hardware, but in my mind
> I imagine them as different controllers.
> 
> > Case-2: configuring gpmc,device-width=2 from DT when using x8 device.
> 
> ... which is also wrong.
> 
> Once again, you're mis-configuring the GPMC. We cannot expect the NAND
> driver to work properly if the GPMC is not properly initialized, don't
> you think?
> 
> > Actually having NAND_BUSWIDTH_AUTO would require change in GPMC
> > driver also.. please refer my comments in.. 
> > http://lists.infradead.org/pipermail/linux-mtd/2013-October/049284.html
> > 
> 
> Well, I think the approach should be different and much simpler: GPMC
> *must* be properly configured and then NAND can do ONFI detection
> starting in 8-bit and then switching to 16-bit if needed.
> 
> This is what this patch is doing: it _fixes_ the NAND driver ONFI detection,
> _provided_ the GPMC is well-prepared.
> 
> You seem to think that GPMC + NAND should be able to automagically detect
> the device and work, but I don't think that's even physically possible, for
> the reasons you have just exposed.
> 

Sorry to insist: any comments about this?

If you have access to the AM335xEVM (which has an 8-bit NAND, as far as I know)
and also to the Beaglebone 16-bit NAND cape, then you can test this patchset
with all the different combinations: 8-bit vs. 16-bit and array-based vs.
ONFI-based detection.

If it works, then problem solved. If it doesn't, I'm sure we can find a
solution. The driver is currently buggy, so we need to address this sooner
or later.

In addition, the outcome of our discussion will probably be helpful for other
drivers/controllers, since this ONFI issue is likely to be common.

If you can do the testing, that would be great: keep in mind that the
GPMC must be correctly configured at all times. You can use my recent
GPMC patchset for that (which also need some testing).

Thanks in advance,
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html