All of lore.kernel.org
 help / color / mirror / Atom feed
* Question about CFI allocation
@ 2011-01-26 11:09 Mitsutaka Amano
  2011-01-26 14:43 ` Josh Boyer
  0 siblings, 1 reply; 5+ messages in thread
From: Mitsutaka Amano @ 2011-01-26 11:09 UTC (permalink / raw)
  To: linux-mtd

Hi all, I'm a newbie about mtd.

I'm trying to use the cfi on the mpc85xx board. Part of mtdblock is
used by rootfs. So I have questions.

Why does CFI(or other flash memory) have to alloc to the vmalloc
area(such as PHYSMAP or PHYSMAP_OF)?
Is there way to alloc mtd partitions except vmalloc mapping?

Thanks,
Mitsutaka

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Question about CFI allocation
  2011-01-26 11:09 Question about CFI allocation Mitsutaka Amano
@ 2011-01-26 14:43 ` Josh Boyer
  2011-01-31  5:48   ` Mitsutaka Amano
  0 siblings, 1 reply; 5+ messages in thread
From: Josh Boyer @ 2011-01-26 14:43 UTC (permalink / raw)
  To: Mitsutaka Amano; +Cc: linux-mtd

On Wed, Jan 26, 2011 at 6:09 AM, Mitsutaka Amano
<mitsutaka.amano@gmail.com> wrote:
> Hi all, I'm a newbie about mtd.
>
> I'm trying to use the cfi on the mpc85xx board. Part of mtdblock is
> used by rootfs. So I have questions.
>
> Why does CFI(or other flash memory) have to alloc to the vmalloc
> area(such as PHYSMAP or PHYSMAP_OF)?

The CFI code is not calling vmalloc explicitly.  It's calling ioremap,
which happens to come from vmalloc space on most (all?) architectures.
 It has to do that because otherwise the CFI driver can't get access
to the physical flash because of the MMU.

The mtdblock driver does call vmalloc explicitly and that is because
it creates a DRAM cache of the current eraseblock being written to.
If it didn't do that, every write to the block device would generate a
read/modify/erase/write cycle, which is fairly suboptimal.  So it will
cache the writes to that block until it moves onto the next block, at
which point it will flush the whole buffer back.  That helps with
performance and flash lifetime (somewhat), but it does mean that usage
of mtdblock can be prone to data loss in the event of a power failure,
panic, or some other reset.

It uses vmalloc because getting physically contiguous pages to cover a
whole eraseblock (often 128KiB in size), is both unnecessary and will
quite often fail after the board has been running for a bit due to
page fragmentation.

josh

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Question about CFI allocation
  2011-01-26 14:43 ` Josh Boyer
@ 2011-01-31  5:48   ` Mitsutaka Amano
  2011-01-31 20:23     ` Josh Boyer
  0 siblings, 1 reply; 5+ messages in thread
From: Mitsutaka Amano @ 2011-01-31  5:48 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linux-mtd

On Wed, Jan 26, 2011 at 11:43 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Wed, Jan 26, 2011 at 6:09 AM, Mitsutaka Amano
> <mitsutaka.amano@gmail.com> wrote:
>> Hi all, I'm a newbie about mtd.
>>
>> I'm trying to use the cfi on the mpc85xx board. Part of mtdblock is
>> used by rootfs. So I have questions.
>>
>> Why does CFI(or other flash memory) have to alloc to the vmalloc
>> area(such as PHYSMAP or PHYSMAP_OF)?
>
> The CFI code is not calling vmalloc explicitly.  It's calling ioremap,
> which happens to come from vmalloc space on most (all?) architectures.
>  It has to do that because otherwise the CFI driver can't get access
> to the physical flash because of the MMU.
I understand that CFI needs ioremap() -> vmalloc space for accessing
to the physical flash via MMU.

Why allocate amount of flash memory size? my board has 256MB flash
memory and be allocated 256MB over by of_flash_probe.
# cat /proc/vmallocinfo
0xc1000000-0xc1002000    8192 _mpic_map_mmio+0x1c/0x40 ioremap
0xc1004000-0xc1007000   12288 _mpic_map_mmio+0x1c/0x40 ioremap
0xc1008000-0xc100a000    8192 _mpic_map_mmio+0x1c/0x40 ioremap
0xc100c000-0xc100e000    8192 _mpic_map_mmio+0x1c/0x40 ioremap
0xc1010000-0xc1012000    8192 of_iomap+0x34/0x44 ioremap
0xc101c000-0xc101e000    8192 serial_dev_init+0x114/0x16c ioremap
0xc1020000-0xc1022000    8192 serial_dev_init+0x114/0x16c ioremap
0xc1023000-0xc102f000   49152 cramfs_uncompress_init+0x5c/0xa8 pages=11 vmalloc
0xc1030000-0xc1073000  274432 jffs2_zlib_init+0x18/0xc0 pages=66 vmalloc
0xc1074000-0xc1080000   49152 jffs2_zlib_init+0x54/0xc0 pages=11 vmalloc
0xc1082000-0xc1084000    8192 of_iomap+0x34/0x44 ioremap
0xc1086000-0xc1088000    8192 of_iomap+0x34/0x44 ioremap
0xc108a000-0xc108c000    8192 of_iomap+0x34/0x44 ioremap
0xc108e000-0xc1090000    8192 fsl_pq_mdio_probe+0xf4/0x474 ioremap
0xc1092000-0xc1094000    8192 fsl_pq_mdio_probe+0xf4/0x474 ioremap
0xc1096000-0xc1098000    8192 fsl_pq_mdio_probe+0xf4/0x474 ioremap
0xc109a000-0xc109c000    8192 usb_hcd_pci_probe+0x2c4/0x3a4 ioremap
0xc1100000-0xd1101000 268439552 of_flash_probe+0x290/0x814 ioremap

Thanks,
Mitsutaka

>
> The mtdblock driver does call vmalloc explicitly and that is because
> it creates a DRAM cache of the current eraseblock being written to.
> If it didn't do that, every write to the block device would generate a
> read/modify/erase/write cycle, which is fairly suboptimal.  So it will
> cache the writes to that block until it moves onto the next block, at
> which point it will flush the whole buffer back.  That helps with
> performance and flash lifetime (somewhat), but it does mean that usage
> of mtdblock can be prone to data loss in the event of a power failure,
> panic, or some other reset.
>
> It uses vmalloc because getting physically contiguous pages to cover a
> whole eraseblock (often 128KiB in size), is both unnecessary and will
> quite often fail after the board has been running for a bit due to
> page fragmentation.
>
> josh
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Question about CFI allocation
  2011-01-31  5:48   ` Mitsutaka Amano
@ 2011-01-31 20:23     ` Josh Boyer
  2011-02-03  2:50       ` Mitsutaka Amano
  0 siblings, 1 reply; 5+ messages in thread
From: Josh Boyer @ 2011-01-31 20:23 UTC (permalink / raw)
  To: Mitsutaka Amano; +Cc: linux-mtd

On Mon, Jan 31, 2011 at 12:48 AM, Mitsutaka Amano
<mitsutaka.amano@gmail.com> wrote:
> On Wed, Jan 26, 2011 at 11:43 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>> On Wed, Jan 26, 2011 at 6:09 AM, Mitsutaka Amano
>> <mitsutaka.amano@gmail.com> wrote:
>>> Hi all, I'm a newbie about mtd.
>>>
>>> I'm trying to use the cfi on the mpc85xx board. Part of mtdblock is
>>> used by rootfs. So I have questions.
>>>
>>> Why does CFI(or other flash memory) have to alloc to the vmalloc
>>> area(such as PHYSMAP or PHYSMAP_OF)?
>>
>> The CFI code is not calling vmalloc explicitly.  It's calling ioremap,
>> which happens to come from vmalloc space on most (all?) architectures.
>>  It has to do that because otherwise the CFI driver can't get access
>> to the physical flash because of the MMU.
> I understand that CFI needs ioremap() -> vmalloc space for accessing
> to the physical flash via MMU.
>
> Why allocate amount of flash memory size? my board has 256MB flash
> memory and be allocated 256MB over by of_flash_probe.

It's either do that so you can address the whole flash space, or
implement a sliding window in the mapping driver.  That can be rather
complicated when you consider concurrent access to the flash, and
doing repeated ioremap/iounmap calls so I would guess simplicity is
why.

That is mostly applicable for NOR flash directly accessible.  If there
is a controller in front of the flash that only needs a small area
ioremapped, then it shouldn't use physmap_of.c and should write a
proper driver for it.  The NDFC driver is an example of something like
that.

josh

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Question about CFI allocation
  2011-01-31 20:23     ` Josh Boyer
@ 2011-02-03  2:50       ` Mitsutaka Amano
  0 siblings, 0 replies; 5+ messages in thread
From: Mitsutaka Amano @ 2011-02-03  2:50 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linux-mtd

On 15:23 Mon 31 Jan     , Josh Boyer wrote:
> On Mon, Jan 31, 2011 at 12:48 AM, Mitsutaka Amano
> <mitsutaka.amano@gmail.com> wrote:
> > On Wed, Jan 26, 2011 at 11:43 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> >> On Wed, Jan 26, 2011 at 6:09 AM, Mitsutaka Amano
> >> <mitsutaka.amano@gmail.com> wrote:
> >>> Hi all, I'm a newbie about mtd.
> >>>
> >>> I'm trying to use the cfi on the mpc85xx board. Part of mtdblock is
> >>> used by rootfs. So I have questions.
> >>>
> >>> Why does CFI(or other flash memory) have to alloc to the vmalloc
> >>> area(such as PHYSMAP or PHYSMAP_OF)?
> >>
> >> The CFI code is not calling vmalloc explicitly.  It's calling ioremap,
> >> which happens to come from vmalloc space on most (all?) architectures.
> >>  It has to do that because otherwise the CFI driver can't get access
> >> to the physical flash because of the MMU.
> > I understand that CFI needs ioremap() -> vmalloc space for accessing
> > to the physical flash via MMU.
> >
> > Why allocate amount of flash memory size? my board has 256MB flash
> > memory and be allocated 256MB over by of_flash_probe.
> 
> It's either do that so you can address the whole flash space, or
> implement a sliding window in the mapping driver.  That can be rather
> complicated when you consider concurrent access to the flash, and
> doing repeated ioremap/iounmap calls so I would guess simplicity is
> why.

Yeah. If possible, I want to implement a sliding window in the mapping driver for reducing the allocated size.

But I wondered other devices seems to not allocating(e.g, most NAND flash, flash on ARM, MIPS and so on). I don't know difference between my board and other. Doesn't other devices need to allocate to vmalloc?

Mitsutaka

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-02-03  2:51 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-26 11:09 Question about CFI allocation Mitsutaka Amano
2011-01-26 14:43 ` Josh Boyer
2011-01-31  5:48   ` Mitsutaka Amano
2011-01-31 20:23     ` Josh Boyer
2011-02-03  2:50       ` Mitsutaka Amano

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.