On Mon, 2010-08-23 at 14:48 -0700, Kevin Cernekee wrote:
> On Mon, Aug 23, 2010 at 1:22 AM, Matthieu CASTET
> <matthieu.castet at parrot.com> wrote:
> >> The NAND controllers on certain legacy SoCs are not able to read the
> >> ONFI parameter page, even if the flash device itself supports ONFI.
> >
> > Why ?
> > Are there controllers that doesn't allow to send custom command ?
>> Yes. The controllers I have here operate at a relatively high level
> (read page, write page, erase block). Part of the reason for this is
> because the controller is designed for XIP and DMA - operations where
> it is not practical to have the CPU involved in building command
> sequences or wiggling ALE/CLE.
>> Newer versions of the hardware do have the ability to issue custom
> commands and perform ONFI queries, but the versions in the field right
> now do not.
Sorry for my ignorance. Correct me if I'm wrong. I think this should
work as follows:
1. First we add the ONFI detection to MTD, and make it work.
2. If we have an ONFI device which nevertheless does not allow us
reading ONFI data, then we run a 'onfi_broken_devices_quirk()' or
something like this. And this quirk tries to use whatever heuristics.
So, I was thinking that adding strange heuristics and quirks to generic
code is bad. We should _first_ add proper ONFI code, and _then_ add
exception for strange devices like you have.
Do I miss something?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)