On 12/05/2011 12:47 AM, Artem Bityutskiy wrote:
> On Sun, 2011-12-04 at 12:31 +0800, shuo....@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
>> + * of chip is greater than 2048.
>> + * We malloc a large enough buffer (maximum page size is 16K).
>> + */
>> + elbc_fcm_ctrl->buffer = kmalloc(1024 * 16 + 1024, GFP_KERNEL);
>> + if (!elbc_fcm_ctrl->buffer) {
>> + dev_err(dev, "failed to allocate memory\n");
>> + mutex_unlock(&fsl_elbc_nand_mutex);
>> + ret = -ENOMEM;
>> + goto err;
>> + }
>
> Sorry for returning to this again and agian - I do not have time to dig
> suggest you the right solutions on the one hand, you do not provide me a
> good answer on the other hand (or I forgot?).
>
> 16KiB pages do not even exist I believe.
Googling turns up some hints of it, but nothing concrete such as a
datasheet. We can assume 8K max for now and adjust it later, as the
need becomes clear.
> And you kmalloc 33KiB or RAM
17KiB, or 9KiB if we forget about 16K-page NAND.
> although in most cases you need only 5KiB. I think this is wrong -
> what is the very strong reason of wasting RAM you have?
>
> Why you cannot allocate exactly the required amount of RAM after
> 'nand_scan_ident()' finishes and you know the page size?
Because this is a controller resource, shared by multiple NAND chips
that may be different page sizes (even if not, it's adding another point
of synchronization required between initialization of different chips).
I don't think it's worth the gymnastics to save a few KiB.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
