[PATCH v3] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND addresses
charvey at matrox.com
Thu Nov 15 10:38:14 EST 2012
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. ;)
More information about the linux-mtd