[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:27
>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: 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.
>Me(?) or Artem(?).
>I heard the H/W engineer and there's no difference between Q4M and Q5M
>except the NOP.
>and there's no way to detect. So uses the version ID as workaround.


If it is so what if we move the NOP definition to board specific domain.
The board configuration should know what chip is used.
And if NOP is set there then use it otherwise some safe default value.


The last word I meant for Artem.


Thanks
Roman Tereshonkov

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