[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: 08 June, 2011 13:04
>To: Tereshonkov Roman (Nokia-SD/Helsinki)
>Cc: dedekind1 at gmail.com; 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
>
>2011/6/8  <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 13:10
>>>To: Tereshonkov Roman (Nokia-SD/Helsinki)
>>>Cc: dedekind1 at gmail.com; 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
>>>
>>>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
>>
>>
>> Our difference is in Stepping field of the VersionId register:
>> 0xe means "Version 1.0 (initial)", and 0x1 means "CS version 1.0".
>>
>> Does anybody know what does "CS" mean in this context? Is it 
>Customer SoC or something else?
>Consumer Sample.
>
>but 0x013e is shipped widely. Nexus S also uses this chip. so it
>should be fixed at mainline.
>
>Please see another patch. there's no way to detect the version ID even
>though it's ugly.


Yes. I looked the patch and it is ok for me. 
But the last word is for maintainer.


Thanks
Roman Tereshonkov

>
>Thank you,
>Kyungmin Park
>>
>> How do different Stepping versions differ from each other?
>>
>>
>> Regards
>> Roman Tereshonkov
>>
>>
>>>
>>>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 (Артём Битюцкий)
>>>>>>
>>>>>>
>>>>>
>>>
>