[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200706241951.37589.david-b@pacbell.net>
Date: Sun, 24 Jun 2007 19:51:36 -0700
From: David Brownell <david-b@...bell.net>
To: Hans-Jürgen Koch <hjk@...utronix.de>
Cc: dwmw2@...radead.org, Andrew Victor <andrew@...people.com>,
tglx@...utronix.de,
Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: drivers/mtd/devices/at91_dataflash26.c
On Thursday 10 May 2007, Hans-Jürgen Koch wrote:
> Am Donnerstag 10 Mai 2007 22:07 schrieb David Brownell:
> > On Friday 27 April 2007, David Brownell wrote:
> > > On Friday 27 April 2007, Hans-Jürgen Koch wrote:
> > >
> > > > > the m25p80 driver
> > > > > was pretty close to working with those Atmel devices too ...
> > > > > most of the commands are identical.
> > > >
> > > > Thanks for that hint, I'll have a look at the data sheet.
> >
> > Any progress on that? I looked again, and yes most commands
> > are identical.
Still true. :)
For that and a boatload of other SPI flash chips. I'm
wondering just what that JEDEC standard covers; either
it's got useful command coverage, or vendors of SPI flash
noticed that converging command sets is a Good Thing.
> > - That driver relies on an AT91-only SPI stack that's not
> > going upstream, instead of drivers/spi/atmel_spi.c;
> >
> > - Driver can't even be selected on kernel.org kernel (!!);
> >
> > - The m25p80 driver will need at most minor tweaks to
> > handle those AT26 (and AT25) series chips;
> >
> > So 340ea370c2ce89d1c15fbf785460f2f74314ce58 should be reverted.
Also still true...
> >
> > - Dave
> >
>
> Dave,
> sorry for not responding earlier, I was busy with lots of other
> stuff. At the moment, I'm working on this again. I had a bit
> of trouble getting a recent kernel working on my test system,
> but that seems to be OK now.
>
> You'll hear from me soon.
Ping? Have a look at
http://lists.infradead.org/pipermail/linux-mtd/2007-June/018706.html
which depends on the resent mutex conversion patch in the
"previous message" link of that patch.
That should highlight more reasons why at91_dataflash should
be reverted ASAP. I'd expect you would be able to just drop
that in and have it work ... unless you're seeing that nCS0
issue built out of at91rm9200 errata, in which case there's
an experiment I can forward to you. :)
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists