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

roman.tereshonkov at nokia.com roman.tereshonkov at nokia.com
Wed Jun 8 05:56:53 EDT 2011


 

>-----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?

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


More information about the linux-mtd mailing list