On Mon, Mar 30, 2009 at 11:38:08PM +0100, Chris Jones wrote:
> Jonathan McDowell wrote:
> > On Thu, Mar 26, 2009 at 10:31:35PM +0000, Chris Jones wrote:
> >
> >> - are we currently trying to run NAND bus cycles too fast? This is
> >> moderately unlikely since we slowed it down hugely to make the minipug
> >> LCDs work over Samosa, unless Jim was running an old bootldr.
> >
> > As Jim has said, he wasn't running the new bootldr, so it's quite
> > possible that would have sorted things out.
>
> I had a look at the data sheet for the NAND chips and they seem to be
> able to cope with nRE and nWE pulse lengths of 15ns, compared with the
> 200+ns that the minipugs need, so I doubt we're at risk of running the
> bus too fast with them!
Pass. The cpufreq stuff does seem to be causing some weird issues in
general though.
> >> - do we want to observe NAND_RNB in hardware (thus locking up the bus
> >> while the NAND gets its act together) or in software? I'm not even
> >> sure that this is an appropriate question to ask, but someone else may
> >> have a quick answer before I go and grub around in data sheets and
> >> kernel source.
> >
> > Hooking up support for a NAND ready line in the kernel mtd driver is
> > easy; I hadn't realised we weren't already doing that. I can't actually
> > see where NAND_RNB gets mapped to for reading though?
>
> Again, my look at the data sheet shows that NAND_RNB really means 'this
> chip is doing something time-consuming internally' rather than 'hold the
> bus while I sort my registers out',
Yes, that's my understanding of how it should be used.
> so it should be observed in software, not VLIO hardware.
> At the moment, NAND_RNB goes precisely nowhere in the hardware,
> according to the VHDL I'm looking at. We can fix that. It appears that
> the CPLD/FPGA doesn't have a readable control register, so we'll have to
> give it one. This may be an opportunity to make some of the other
> control signals (NAND/IO parking and so on) read-back-able, too, though
> at the risk of introducing firmware version/kernel version nightmares.
As I say, making the kernel mtd stuff use a NAND ready line is easy;
we just need to provide a dev_ready function that checks it and then the
MTD code will use that function rather than a delay loop.
J.
(text/plain)