From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Fri, 4 Nov 2011 11:37:58 -0500 Subject: [U-Boot] [PATCH 4/4 V3] PXA: Adapt Voipac PXA270 to OneNAND SPL In-Reply-To: <201111040155.22901.marek.vasut@gmail.com> References: <1320188094-6654-1-git-send-email-marek.vasut@gmail.com> <201111032252.18260.marek.vasut@gmail.com> <4EB313A2.6080400@freescale.com> <201111040155.22901.marek.vasut@gmail.com> Message-ID: <4EB414E6.8010204@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 11/03/2011 07:55 PM, Marek Vasut wrote: >> On 11/03/2011 04:52 PM, Marek Vasut wrote: >> Why do we want to separate them? What is the fundamental difference >> between OneNAND, and a high-level NAND controller such as fsl_elbc? > > Honestly, I'm not the author of the subsystem, but please check the > documentation. The way we retrieve data from onenand is different to NAND. What documentation? How is it different? There are substantial differences in how we "retrieve data" between drivers that use the NAND subsystem. Surely you've seen that in the mxs_nand driver. :-) >> Maybe there would be some differences on init if we can't produce >> "normal" ID data, but that doesn't justify duplicating the whole subsystem. > > Where do you see such duplication? cmd_onenand ? cmd_onenand and env_onenand are the most irritating, since they're at a layer that really shouldn't care about the differences -- we should probably have a plain "mtd" command instead, for most of the functionality. There's also onenand_bbt.c -- what are the hardware-based differences in how the bad block table is managed? nand_base.c/onenand_base.c are less clear. Obviously much of what is in onenand_base.c would be in the controller driver if it used the NAND subsystem. But it looks like some of it is duplication. >> Why should the code that just wants to use an API to move data around >> need to care which it is? Why should there be behavioral differences >> that aren't rooted in the actual hardware? Another approach might be to >> use MTD as the common interface, but factor out common code into >> libraries that drivers can use, and avoid the main nand_base.c code even >> for things like fsl_elbc. > > I think you're mistaken here. OneNAND != NAND. Well, last I tried I couldn't find any public documentation, so all I have to go on is the code, some marketing-type info, and asking questions of people that appear to know more about OneNAND than I do. :-)