[PATCH] mtd : add parsing code for one kind of Hynix's nand chip

[Brian Norris]

On Wed, Apr 11, 2012 at 7:43 PM, Huang Shijie <b32955 at freescale.com> wrote:
>> On Mon, Apr 9, 2012 at 7:56 PM, Huang Shijie<b32955 at freescale.com>  wrote:
>>>
>>>  drivers/mtd/nand/nand_base.c |   43
>>> ++++++++++++++++++++++++++++++++++++++++++
>>>  1 files changed, 43 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
>>> index 6315b94..8997023 100644
>>> --- a/drivers/mtd/nand/nand_base.c
>>> +++ b/drivers/mtd/nand/nand_base.c
>>> @@ -3028,6 +3028,49 @@ static struct nand_flash_dev
>>> *nand_get_flash_type(struct mtd_info *mtd,
>>>                        mtd->erasesize = (128 * 1024)<<
>>>                                (((extid>>  1)&  0x04) | (extid&  0x03));
>>>                        busw = 0;
>>> +               } else if (id_data[0] == NAND_MFR_HYNIX&&  id_data[1] ==
>>> 0xd7) {
>>>
>>> +                       /* Calc pagesize */
>>
>> I'm not sure this is the beset heuristic. Hynix could easily make a
>> larger chip that has the same decoding table, so we probably shouldn't
>> compare dev_id == 0xD7. It actually seems like the decoding table
>> might be intended for all Hynix MLC. What do you think about the
>> following condition?
>>
>> +       } else if ((chip->cellinfo&  NAND_CI_CELLTYPE_MSK)&&
>> id_data[0] == NAND_MFR_HYNIX) {
>
> I am afraid this can not solve the problem.
> The HY27UT088G2M whose id_data[2] is 0x14 DOES not follow your code.
> Please check the datasheet of HY27UT088G2M. ( I ever emailed to you.)
>
> The same issue exits in H627UW08CGFM too.

Ah yes, I overlooked this. My proposal was a bit off-the-cuff. Thanks
for the data sheets, BTW. I need to integrate them into my master
table (and submit them to mtd-www) so that I check them whenever I'm
looking at new Hynix support.

Now that I've given them all a second read, it really looks like this
new Hynix chip actually follows no discernible pattern, which seems to
suggest that we have to know all the chip parameters in order to know
which ID decode table to use...but if we know all the parameters, then
why do we need the table?? (Just being devil's advocate) If I had
samples of all the chips, perhaps I could test some to determine other
patterns, like ID wraparound behavior, but I doubt it...

So really, I'd be interested in asking Hynix (and Toshiba and probably
Samsung, for that matter): what do you expect software developers to
do when you provide datasheets with useless ID decode tables? Are we
supposed to read your mind to determine which chips are supposed to
follow a given decode table?

But seriously: let me know if you have better insight into how to
associate this table with a set of chip IDs. Otherwise, I might as
well finish adding an 8-byte ID table and adding this one chip
manually.

>> BTW, I actually have some patches queued up that I need to complete
>> properly, where I'm trying to clean up and update NAND detection a
>> little. So I basically have this same patch, but rebased on top of
>> some other changes I have ready... I don't mind taking a revised
>> version of yours, or I can try to clean up my series and send it out
>> soon.
>>
> I hope you send it out as soon as possible. :)

I'm trying, but I get very busy with other things :)

Anyway, I'm not very comfortable with the heuristics for this Hynix
decode method, so I don't want to post another patch for it yet. If it
helps, I can submit the other patches soon; they amount to mostly
cleanup (IMO). But at least that way, whoever works on NAND detection
in the near future has the same code base.

Brian