[PATCH v3] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND addresses

[Christopher Harvey]

On Thu, Nov 15, 2012 at 05:18:44PM +0200, Artem Bityutskiy wrote:
> On Thu, 2012-11-15 at 09:48 -0500, Christopher Harvey wrote:
> > On Thu, Nov 15, 2012 at 01:02:09PM +0200, Artem Bityutskiy wrote:
> > > On Mon, 2012-10-29 at 15:51 -0400, Christopher Harvey wrote:
> > > > In 16bit NAND mode the GPMC would send the address 0xNN as 0xFFNN
> > > > instead of 0x00NN on the bus. The 0xFFs were actually uninitialized
> > > > bits that were left unset in the GPMC command output register. The
> > > > reason they weren't initialized in 16bit mode is that if the same code
> > > > that writes to this register was used in 8bit mode then 2 commands
> > > > would be output in 8bit mode. One for the low byte, and an extra 0x0
> > > > command for the high byte. This commit uses writew if we're using
> > > > 16bit NAND. This commit also changes the high byte in the command
> > > > output register, but they are ignored by NAND chips anyway.
> > > > 
> > > > Most chips seem fine with the extra 0xFFs, but the ONFI spec says
> > > > otherwise.
> > > > 
> > > > Signed-off-by: Christopher Harvey <charvey at matrox.com>
> > > 
> > > Pushed to l2-mtd.git, thanks!
> > 
> > !!! Did anybody get around to testing this? I thought this patch had
> >     been abandoned. Will testing get done on an omap chip now that it
> >     is in a tree?
> > 
> > I should have prefixed it with RFC.
> 
> I assume _you_ tested it, and Ivan was happy. But if it is untested, I
> am dropping it.
> 

I'm running a slight variation of it on another version of the
kernel. I'm glad you're dropping it though...I have a reputation to
maintain as well as a kernel. ;)

-C