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

[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.



>
>>>
>>> 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 (Артём Битюцкий)
>>
>>
>