diff for duplicates of <4ECE162D.7080408@freescale.com> diff --git a/a/1.txt b/N1/1.txt index 14a2db3..2322a97 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,28 +1,34 @@ -于 2011年11月24日 16:16, Artem Bityutskiy 写道: +=E4=BA=8E 2011=E5=B9=B411=E6=9C=8824=E6=97=A5 16:16, Artem Bityutskiy =E5= +=86=99=E9=81=93: > On Thu, 2011-11-24 at 07:49 +0000, Li Yang-R58472 wrote: ->>> Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support +>>> Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to s= +upport >>> large-page Nand chip >>> >>> On Thu, 2011-11-24 at 08:41 +0800, b35362@freescale.com wrote: >>>> + /* ->>>> + * Freescale FCM controller has a 2K size limitation of buffer ->>>> + * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize +>>>> + * Freescale FCM controller has a 2K size limitation= + of buffer +>>>> + * RAM, so elbc_fcm_ctrl->buffer have to be used if = +writesize >>>> + * of chip is greater than 2048. ->>>> + * We malloc a large enough buffer (maximum page size is +>>>> + * We malloc a large enough buffer (maximum page siz= +e is >>> 16K). >>>> + */ ->>>> + elbc_fcm_ctrl->buffer = kmalloc(1024 * 16 + 1024, +>>>> + elbc_fcm_ctrl->buffer =3D kmalloc(1024 * 16 + 1024, >>> GFP_KERNEL); >>> >>> Are there NANDs with 16KiB page size? ->> We are not sure, but are there possibility that chip with 16K page will appear? Or maybe we can add a MACRO for the maximum page size? +>> We are not sure, but are there possibility that chip with 16K page wil= +l appear? Or maybe we can add a MACRO for the maximum page size? > I do not know, but I know that allocating 32KiB of contiguous physical > RAM may cause unneeded memory pressure and even fail if the memory is > too fragmented. So I would not go for this unless this is necessary. What is your suggestion ? 8k is enough ? > Did you try to look how the NAND base interface could be changed to > avoid re-allocation altogether, BTW? -This buffer is a controller-wide resource( as Scott said), I only +This buffer is a controller-wide resource( as Scott said), I only=20 allocate buffer one time in this version. It should be a large enough buffer for all chips. diff --git a/a/content_digest b/N1/content_digest index dd0da15..851c767 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -17,34 +17,40 @@ " linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>\0" "\00:1\0" "b\0" - "\344\272\216 2011\345\271\26411\346\234\21024\346\227\245 16:16, Artem Bityutskiy \345\206\231\351\201\223:\n" + "=E4=BA=8E 2011=E5=B9=B411=E6=9C=8824=E6=97=A5 16:16, Artem Bityutskiy =E5=\n" + "=86=99=E9=81=93:\n" "> On Thu, 2011-11-24 at 07:49 +0000, Li Yang-R58472 wrote:\n" - ">>> Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support\n" + ">>> Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to s=\n" + "upport\n" ">>> large-page Nand chip\n" ">>>\n" ">>> On Thu, 2011-11-24 at 08:41 +0800, b35362@freescale.com wrote:\n" ">>>> + /*\n" - ">>>> + * Freescale FCM controller has a 2K size limitation of buffer\n" - ">>>> + * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize\n" + ">>>> + * Freescale FCM controller has a 2K size limitation=\n" + " of buffer\n" + ">>>> + * RAM, so elbc_fcm_ctrl->buffer have to be used if =\n" + "writesize\n" ">>>> + * of chip is greater than 2048.\n" - ">>>> + * We malloc a large enough buffer (maximum page size is\n" + ">>>> + * We malloc a large enough buffer (maximum page siz=\n" + "e is\n" ">>> 16K).\n" ">>>> + */\n" - ">>>> + elbc_fcm_ctrl->buffer = kmalloc(1024 * 16 + 1024,\n" + ">>>> + elbc_fcm_ctrl->buffer =3D kmalloc(1024 * 16 + 1024,\n" ">>> GFP_KERNEL);\n" ">>>\n" ">>> Are there NANDs with 16KiB page size?\n" - ">> We are not sure, but are there possibility that chip with 16K page will appear? Or maybe we can add a MACRO for the maximum page size?\n" + ">> We are not sure, but are there possibility that chip with 16K page wil=\n" + "l appear? Or maybe we can add a MACRO for the maximum page size?\n" "> I do not know, but I know that allocating 32KiB of contiguous physical\n" "> RAM may cause unneeded memory pressure and even fail if the memory is\n" "> too fragmented. So I would not go for this unless this is necessary.\n" "What is your suggestion ? 8k is enough ?\n" "> Did you try to look how the NAND base interface could be changed to\n" "> avoid re-allocation altogether, BTW?\n" - "This buffer is a controller-wide resource( as Scott said), I only \n" + "This buffer is a controller-wide resource( as Scott said), I only=20\n" "allocate buffer one time in this version.\n" "It should be a large enough buffer for all chips.\n" "\n" -Liu Shuo -919e902894848af71de7ed98809e64c43dc869e19b4cf92a57d87b91aff357a5 +a8757450d6b2a9b7b33b4694a4cf6d9489ea96d75af41c4e59a1b11f555a3458
diff --git a/a/content_digest b/N2/content_digest index dd0da15..5dd85f6 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -7,14 +7,14 @@ "Subject\0Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip\0" "Date\0Thu, 24 Nov 2011 18:02:21 +0800\0" "To\0<dedekind1@gmail.com>\0" - "Cc\0Artem.Bityutskiy@nokia.com <Artem.Bityutskiy@nokia.com>" - Li Yang-R58472 <r58472@freescale.com> - Wood Scott-B07421 <B07421@freescale.com> + "Cc\0Li Yang-R58472 <r58472@freescale.com>" dwmw2@infradead.org <dwmw2@infradead.org> - linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + Artem.Bityutskiy@nokia.com <Artem.Bityutskiy@nokia.com> + Wood Scott-B07421 <B07421@freescale.com> linux-mtd@lists.infradead.org <linux-mtd@lists.infradead.org> + linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> akpm@linux-foundation.org <akpm@linux-foundation.org> - " linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>\0" + " linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>\0" "\00:1\0" "b\0" "\344\272\216 2011\345\271\26411\346\234\21024\346\227\245 16:16, Artem Bityutskiy \345\206\231\351\201\223:\n" @@ -47,4 +47,4 @@ "\n" -Liu Shuo -919e902894848af71de7ed98809e64c43dc869e19b4cf92a57d87b91aff357a5 +2138176f325497ba41f60135ada6f185c90f8d6919bd8d6eeca86a01a2ada98b
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.