[PATCH] mtd: OneNAND: Fix wrong subpage_sft at 4KiB pagesize

[Kyungmin Park]

2011/6/7  <roman.tereshonkov at nokia.com>:
>
>
>>-----Original Message-----
>>From: kyungmin78 at gmail.com [mailto:kyungmin78 at gmail.com] On
>>Behalf Of ext Kyungmin Park
>>Sent: 07 June, 2011 02:56
>>To: dedekind1 at gmail.com
>>Cc: Tereshonkov Roman (Nokia-SD/Helsinki);
>>linux-mtd at lists.infradead.org; dwmw2 at infradead.org;
>>m.szyprowski at samsung.com
>>Subject: Re: [PATCH] mtd: OneNAND: Fix wrong subpage_sft at
>>4KiB pagesize
>>
>>On Mon, Jun 6, 2011 at 7:06 PM, Artem Bityutskiy
>><dedekind1 at gmail.com> wrote:
>>> On Mon, 2011-06-06 at 13:02 +0300, Artem Bityutskiy wrote:
>>>> On Mon, 2011-06-06 at 09:42 +0000,
>>roman.tereshonkov at nokia.com wrote:
>>>> > What do mean by "no case to use the subpage"?
>>>> >
>>>> > According to the spec KFM4G16Q4M-xEBx the Number of
>>Partial Program Cycles in the page (NOP)
>>>> > is equal to 4 -> subpage_sft=2.
>>
>>It's really strange. Two OneNAND spec which has 4KiB pagesize
>>say it has 1 NOP.
>>
>>Number of Partial Program Cycles in the page (Including main and spare
>>area) NOP - - 1 cycles
>>(KFM4G16Q5M-xEBx)
>>
>>that's reason I first set subpage_sft = 0 at original code.
>>
>>The different thing between you and me is the page architecture
>>number. yes 4 is the correct number but 5 also has the 4KiB pagesize.
>>I think it's mean the manufacturing difference. can you check the
>>which XXnm manufacturing for your devices?
>>In our case. it's 3Xnm. and previous is 4Xnm.
>
>
>
> It seems the spec does not specify the nm-technology used.
>
> Can we somehow use the DeviceID and VersionID registers to differ
> our chips?
> For my case KFM4G16Q4M DeviceID=0x0050, VersionID=0x0131,
> and KFM8G16Q4M DeviceID=0x0068, VersionID=0x0131.
>
> BTW. Another spec KFM4G16Q4B also tells about NOP=4 cycles.

Here's my device register values.
005000ec 0800013e 01010200 00000000
DeviceID=0x0050, VersionID=0x013e

The lower 4 bits of VersionID is different. even though VersionID is
different. it's dangerous to detect the NOP 4 or not.

I sent the email to OneNAND person and share the result soon. (he's on
business trip and return at June 9).

Thank you,
Kyungmin Park


>
>
>
>>
>>>>
>>>> I thought this means "not supported by HW". But if this is
>>supported,
>>>> then I'm very surprised why would we remove it. I'm
>>dropping this patch
>>>> from my tree.
>>>
>>> OK, I actually did not put it to the l2 tree. And AFAICS this patch
>>> basically reverts commit
>>99b17c08bca2810f5910b3027f1b9d82edf7a576, but
>>> still leaves the data structures like onenand_oob_128.
>>>
>>> So NACK for this patch - poor commit message, weird changes. I'm
>>> surprised to see this from kmpark.
>>
>>since we got some different OneNAND Spec. even though it has
>>same 4KiB pagesize.
>>
>>Thank you,
>>Kyungmin Park
>>>
>>> --
>>> Best Regards,
>>> Artem Bityutskiy (Артём Битюцкий)
>>>
>>>
>>