| Message ID | 20110602064832.GA7319@july |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, 2011-06-02 at 15:48 +0900, Kyungmin Park wrote: > From: Kyungmin Park <kyungmin.park@samsung.com> > > There's no case to use the subpage for 4KiB pagesize. > > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> > --- > diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c > index ac9e959..337be7c 100644 > --- a/drivers/mtd/onenand/onenand_base.c > +++ b/drivers/mtd/onenand/onenand_base.c > @@ -4047,13 +4047,11 @@ int onenand_scan(struct mtd_info *mtd, int maxchips) > */ > switch (mtd->oobsize) { > case 128: > - if (FLEXONENAND(this)) { > + if (FLEXONENAND(this)) > this->ecclayout = &flexonenand_oob_128; > - mtd->subpage_sft = 0; > - } else { > + else > this->ecclayout = &onenand_oob_128; > - mtd->subpage_sft = 2; > - } > + mtd->subpage_sft = 0; > break; > case 64: > this->ecclayout = &onenand_oob_64; Roman, are you happy with this change?
On Thu, 2011-06-02 at 15:48 +0900, Kyungmin Park wrote: > From: Kyungmin Park <kyungmin.park@samsung.com> > > There's no case to use the subpage for 4KiB pagesize. > > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> I think Roman was testing subpage support with 4KiB pages and it worked, but I'm not sure and I did not read the specs. Let's ask Roman.
>-----Original Message----- >From: ext Artem Bityutskiy [mailto:dedekind1@gmail.com] >Sent: 03 June, 2011 18:42 >To: Kyungmin Park; Tereshonkov Roman (Nokia-SD/Helsinki) >Cc: linux-mtd@lists.infradead.org; dwmw2@infradead.org; >m.szyprowski@samsung.com >Subject: Re: [PATCH] mtd: OneNAND: Fix wrong subpage_sft at >4KiB pagesize > >On Thu, 2011-06-02 at 15:48 +0900, Kyungmin Park wrote: >> From: Kyungmin Park <kyungmin.park@samsung.com> >> >> There's no case to use the subpage for 4KiB pagesize. >> >> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> >> --- >> diff --git a/drivers/mtd/onenand/onenand_base.c >b/drivers/mtd/onenand/onenand_base.c >> index ac9e959..337be7c 100644 >> --- a/drivers/mtd/onenand/onenand_base.c >> +++ b/drivers/mtd/onenand/onenand_base.c >> @@ -4047,13 +4047,11 @@ int onenand_scan(struct mtd_info >*mtd, int maxchips) >> */ >> switch (mtd->oobsize) { >> case 128: >> - if (FLEXONENAND(this)) { >> + if (FLEXONENAND(this)) >> this->ecclayout = &flexonenand_oob_128; >> - mtd->subpage_sft = 0; >> - } else { >> + else >> this->ecclayout = &onenand_oob_128; >> - mtd->subpage_sft = 2; >> - } >> + mtd->subpage_sft = 0; >> break; >> case 64: >> this->ecclayout = &onenand_oob_64; > >Roman, are you happy with this change? > 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. Regards Roman Tereshonkov >-- >Best Regards, >Artem Bityutskiy (Артём Битюцкий) > >
On Mon, 2011-06-06 at 09:42 +0000, roman.tereshonkov@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. 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.
On Mon, 2011-06-06 at 13:02 +0300, Artem Bityutskiy wrote: > On Mon, 2011-06-06 at 09:42 +0000, roman.tereshonkov@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. > > 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.
On Mon, Jun 6, 2011 at 7:06 PM, Artem Bityutskiy <dedekind1@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@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. >> >> 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 (Артём Битюцкий) > >
>-----Original Message----- >From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >Behalf Of ext Kyungmin Park >Sent: 07 June, 2011 02:56 >To: dedekind1@gmail.com >Cc: Tereshonkov Roman (Nokia-SD/Helsinki); >linux-mtd@lists.infradead.org; dwmw2@infradead.org; >m.szyprowski@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@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@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 (Артём Битюцкий) >> >> >
2011/6/7 <roman.tereshonkov@nokia.com>: > > >>-----Original Message----- >>From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >>Behalf Of ext Kyungmin Park >>Sent: 07 June, 2011 02:56 >>To: dedekind1@gmail.com >>Cc: Tereshonkov Roman (Nokia-SD/Helsinki); >>linux-mtd@lists.infradead.org; dwmw2@infradead.org; >>m.szyprowski@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@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@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 (Артём Битюцкий) >>> >>> >>
2011/6/7 Kyungmin Park <kmpark@infradead.org>: > 2011/6/7 <roman.tereshonkov@nokia.com>: >> >> >>>-----Original Message----- >>>From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >>>Behalf Of ext Kyungmin Park >>>Sent: 07 June, 2011 02:56 >>>To: dedekind1@gmail.com >>>Cc: Tereshonkov Roman (Nokia-SD/Helsinki); >>>linux-mtd@lists.infradead.org; dwmw2@infradead.org; >>>m.szyprowski@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@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@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). BOTH are right. Now you have the NOP 4. but my chip has NOP 1. Memory division splits the chip for each customer. then how to detect the NOP for similar chip? Using VersionID? or simply the minimum value? Please give your opinions. Thank you, Kyungmin Park > > 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 (Артём Битюцкий) >>>> >>>> >>> >
>-----Original Message----- >From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >Behalf Of ext Kyungmin Park >Sent: 07 June, 2011 13:10 >To: Tereshonkov Roman (Nokia-SD/Helsinki) >Cc: dedekind1@gmail.com; linux-mtd@lists.infradead.org; >dwmw2@infradead.org; m.szyprowski@samsung.com >Subject: Re: [PATCH] mtd: OneNAND: Fix wrong subpage_sft at >4KiB pagesize > >2011/6/7 <roman.tereshonkov@nokia.com>: >> >> >>>-----Original Message----- >>>From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >>>Behalf Of ext Kyungmin Park >>>Sent: 07 June, 2011 02:56 >>>To: dedekind1@gmail.com >>>Cc: Tereshonkov Roman (Nokia-SD/Helsinki); >>>linux-mtd@lists.infradead.org; dwmw2@infradead.org; >>>m.szyprowski@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@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@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 (Артём Битюцкий) >>>> >>>> >>> >
2011/6/8 <roman.tereshonkov@nokia.com>: > > >>-----Original Message----- >>From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >>Behalf Of ext Kyungmin Park >>Sent: 07 June, 2011 13:10 >>To: Tereshonkov Roman (Nokia-SD/Helsinki) >>Cc: dedekind1@gmail.com; linux-mtd@lists.infradead.org; >>dwmw2@infradead.org; m.szyprowski@samsung.com >>Subject: Re: [PATCH] mtd: OneNAND: Fix wrong subpage_sft at >>4KiB pagesize >> >>2011/6/7 <roman.tereshonkov@nokia.com>: >>> >>> >>>>-----Original Message----- >>>>From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >>>>Behalf Of ext Kyungmin Park >>>>Sent: 07 June, 2011 02:56 >>>>To: dedekind1@gmail.com >>>>Cc: Tereshonkov Roman (Nokia-SD/Helsinki); >>>>linux-mtd@lists.infradead.org; dwmw2@infradead.org; >>>>m.szyprowski@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@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@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. 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 (Артём Битюцкий) >>>>> >>>>> >>>> >>
>-----Original Message----- >From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >Behalf Of ext Kyungmin Park >Sent: 08 June, 2011 13:04 >To: Tereshonkov Roman (Nokia-SD/Helsinki) >Cc: dedekind1@gmail.com; linux-mtd@lists.infradead.org; >dwmw2@infradead.org; m.szyprowski@samsung.com >Subject: Re: [PATCH] mtd: OneNAND: Fix wrong subpage_sft at >4KiB pagesize > >2011/6/8 <roman.tereshonkov@nokia.com>: >> >> >>>-----Original Message----- >>>From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >>>Behalf Of ext Kyungmin Park >>>Sent: 07 June, 2011 13:10 >>>To: Tereshonkov Roman (Nokia-SD/Helsinki) >>>Cc: dedekind1@gmail.com; linux-mtd@lists.infradead.org; >>>dwmw2@infradead.org; m.szyprowski@samsung.com >>>Subject: Re: [PATCH] mtd: OneNAND: Fix wrong subpage_sft at >>>4KiB pagesize >>> >>>2011/6/7 <roman.tereshonkov@nokia.com>: >>>> >>>> >>>>>-----Original Message----- >>>>>From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >>>>>Behalf Of ext Kyungmin Park >>>>>Sent: 07 June, 2011 02:56 >>>>>To: dedekind1@gmail.com >>>>>Cc: Tereshonkov Roman (Nokia-SD/Helsinki); >>>>>linux-mtd@lists.infradead.org; dwmw2@infradead.org; >>>>>m.szyprowski@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@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@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 (Артём Битюцкий) >>>>>> >>>>>> >>>>> >>> >
2011/6/8 <roman.tereshonkov@nokia.com>: > > >>-----Original Message----- >>From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >>Behalf Of ext Kyungmin Park >>Sent: 08 June, 2011 13:04 >>To: Tereshonkov Roman (Nokia-SD/Helsinki) >>Cc: dedekind1@gmail.com; linux-mtd@lists.infradead.org; >>dwmw2@infradead.org; m.szyprowski@samsung.com >>Subject: Re: [PATCH] mtd: OneNAND: Fix wrong subpage_sft at >>4KiB pagesize >> >>2011/6/8 <roman.tereshonkov@nokia.com>: >>> >>> >>>>-----Original Message----- >>>>From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >>>>Behalf Of ext Kyungmin Park >>>>Sent: 07 June, 2011 13:10 >>>>To: Tereshonkov Roman (Nokia-SD/Helsinki) >>>>Cc: dedekind1@gmail.com; linux-mtd@lists.infradead.org; >>>>dwmw2@infradead.org; m.szyprowski@samsung.com >>>>Subject: Re: [PATCH] mtd: OneNAND: Fix wrong subpage_sft at >>>>4KiB pagesize >>>> >>>>2011/6/7 <roman.tereshonkov@nokia.com>: >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >>>>>>Behalf Of ext Kyungmin Park >>>>>>Sent: 07 June, 2011 02:56 >>>>>>To: dedekind1@gmail.com >>>>>>Cc: Tereshonkov Roman (Nokia-SD/Helsinki); >>>>>>linux-mtd@lists.infradead.org; dwmw2@infradead.org; >>>>>>m.szyprowski@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@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@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. 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 (Артём Битюцкий) >>>>>>> >>>>>>> >>>>>> >>>> >>
>-----Original Message----- >From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >Behalf Of ext Kyungmin Park >Sent: 08 June, 2011 13:27 >To: Tereshonkov Roman (Nokia-SD/Helsinki) >Cc: dedekind1@gmail.com; linux-mtd@lists.infradead.org; >dwmw2@infradead.org; m.szyprowski@samsung.com >Subject: Re: [PATCH] mtd: OneNAND: Fix wrong subpage_sft at >4KiB pagesize > >2011/6/8 <roman.tereshonkov@nokia.com>: >> >> >>>-----Original Message----- >>>From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >>>Behalf Of ext Kyungmin Park >>>Sent: 08 June, 2011 13:04 >>>To: Tereshonkov Roman (Nokia-SD/Helsinki) >>>Cc: dedekind1@gmail.com; linux-mtd@lists.infradead.org; >>>dwmw2@infradead.org; m.szyprowski@samsung.com >>>Subject: Re: [PATCH] mtd: OneNAND: Fix wrong subpage_sft at >>>4KiB pagesize >>> >>>2011/6/8 <roman.tereshonkov@nokia.com>: >>>> >>>> >>>>>-----Original Message----- >>>>>From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >>>>>Behalf Of ext Kyungmin Park >>>>>Sent: 07 June, 2011 13:10 >>>>>To: Tereshonkov Roman (Nokia-SD/Helsinki) >>>>>Cc: dedekind1@gmail.com; linux-mtd@lists.infradead.org; >>>>>dwmw2@infradead.org; m.szyprowski@samsung.com >>>>>Subject: Re: [PATCH] mtd: OneNAND: Fix wrong subpage_sft at >>>>>4KiB pagesize >>>>> >>>>>2011/6/7 <roman.tereshonkov@nokia.com>: >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: kyungmin78@gmail.com [mailto:kyungmin78@gmail.com] On >>>>>>>Behalf Of ext Kyungmin Park >>>>>>>Sent: 07 June, 2011 02:56 >>>>>>>To: dedekind1@gmail.com >>>>>>>Cc: Tereshonkov Roman (Nokia-SD/Helsinki); >>>>>>>linux-mtd@lists.infradead.org; dwmw2@infradead.org; >>>>>>>m.szyprowski@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@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@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 (Артём Битюцкий) >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >
Hi, On Wed, 2011-06-08 at 09:59 +0900, Kyungmin Park wrote: > then how to detect the NOP for similar chip? Using VersionID? or > simply the minimum value? You are from Samsung, could you use your channels and ask your HW guys how to detect NOP? What is the proper way?
On Wed, Jun 8, 2011 at 7:53 PM, Artem Bityutskiy <dedekind1@gmail.com> wrote: > Hi, > > On Wed, 2011-06-08 at 09:59 +0900, Kyungmin Park wrote: >> then how to detect the NOP for similar chip? Using VersionID? or >> simply the minimum value? > > You are from Samsung, could you use your channels and ask your HW guys > how to detect NOP? What is the proper way? I really surprised when talk with H/W guy. He don't understand why the same codes are used for Samsung mobile and Nokia. He said it can be distinguished from printed chip number at cover. not S/W. That's reason. don't make a different version ID or others. P.S., I'm working for Samsung Mobile. > > -- > Best Regards, > Artem Bityutskiy (Артём Битюцкий) > > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ >
diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c index ac9e959..337be7c 100644 --- a/drivers/mtd/onenand/onenand_base.c +++ b/drivers/mtd/onenand/onenand_base.c @@ -4047,13 +4047,11 @@ int onenand_scan(struct mtd_info *mtd, int maxchips) */ switch (mtd->oobsize) { case 128: - if (FLEXONENAND(this)) { + if (FLEXONENAND(this)) this->ecclayout = &flexonenand_oob_128; - mtd->subpage_sft = 0; - } else { + else this->ecclayout = &onenand_oob_128; - mtd->subpage_sft = 2; - } + mtd->subpage_sft = 0; break; case 64: this->ecclayout = &onenand_oob_64;