Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 28 4月, 2009 1 次提交
  3. 04 4月, 2009 1 次提交
  5. 02 4月, 2009 1 次提交
  7. 29 3月, 2009 3 次提交
  9. 25 3月, 2009 1 次提交
  11. 23 3月, 2009 1 次提交
    • E
      [ARM] pxa: add base support for Marvell's PXA168 processor line · 49cbe786
      由 Eric Miao 提交于 
      """The Marvell® PXA168 processor is the first in a family of application
processors targeted at mass market opportunities in computing and consumer
devices. It balances high computing and multimedia performance with low
power consumption to support extended battery life, and includes a wealth
of integrated peripherals to reduce overall BOM cost .... """

See http://www.marvell.com/featured/pxa168.jsp for more information.

  1. Marvell Mohawk core is a hybrid of xscale3 and its own ARM core,
     there are many enhancements like instructions for flushing the
     whole D-cache, and so on

  2. Clock reuses Russell's common clkdev, and added the basic support
     for UART1/2.

  3. Devices are a bit different from the 'mach-pxa' way, the platform
     devices are now dynamically allocated only when necessary (i.e.
     when pxa_register_device() is called). Description for each device
     are stored in an array of 'struct pxa_device_desc'. Now that:

     a. this array of device description is marked with __initdata and
        can be freed up system is fully up

     b. which means board code has to add all needed devices early in
        his initializing function

     c. platform specific data can now be marked as __initdata since
        they are allocated and copied by platform_device_add_data()

  4. only the basic UART1/2/3 are added, more devices will come later.
Signed-off-by: NJason Chagas <chagas@marvell.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>
      49cbe786
  13. 16 3月, 2009 7 次提交
    • N
      [ARM] ignore high memory with VIPT aliasing caches · 3f973e22
      由 Nicolas Pitre 提交于 
      VIPT aliasing caches have issues of their own which are not yet handled.
Usage of discard_old_kernel_data() in copypage-v6.c is not highmem ready,
kmap/fixmap stuff doesn't take account of cache colouring, etc.
If/when those issues are handled then this could be reverted.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
      3f973e22
    • N
      [ARM] xsc3: add highmem support to L2 cache handling code · 3902a15e
      由 Nicolas Pitre 提交于 
      On xsc3, L2 cache ops are possible only on virtual addresses.  The code
is rearranged so to have a linear progression requiring the least amount
of pte setups in the highmem case.  To protect the virtual mapping so
created, interrupts must be disabled currently up to a page worth of
address range.

The interrupt disabling is done in a way to minimize the overhead within
the inner loop.  The alternative would consist in separate code for
the highmem and non highmem compilation which is less preferable.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
      3902a15e
    • N
      [ARM] Feroceon: add highmem support to L2 cache handling code · 1bb77267
      由 Nicolas Pitre 提交于 
      The choice is between looping over the physical range and performing
single cache line operations, or to map highmem pages somewhere, as
cache range ops are possible only on virtual addresses.

Because L2 range ops are much faster, we go with the later by factoring
the physical-to-virtual address conversion and use a fixmap entry for it
in the HIGHMEM case.

Possible future optimizations to avoid the pte setup cost:

 - do the pte setup for highmem pages only

 - determine a threshold for doing a line-by-line processing on physical
   addresses when the range is small
Signed-off-by: NNicolas Pitre <nico@marvell.com>
      1bb77267
    • N
      [ARM] introduce dma_cache_maint_page() · 43377453
      由 Nicolas Pitre 提交于 
      This is a helper to be used by the DMA mapping API to handle cache
maintenance for memory identified by a page structure instead of a
virtual address.  Those pages may or may not be highmem pages, and
when they're highmem pages, they may or may not be virtually mapped.
When they're not mapped then there is no L1 cache to worry about. But
even in that case the L2 cache must be processed since unmapped highmem
pages can still be L2 cached.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
      43377453
    • N
      [ARM] mem_init(): make highmem pages available for use · 3835f6cb
      由 Nicolas Pitre 提交于 
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      3835f6cb
    • N
      [ARM] kmap support · d73cd428
      由 Nicolas Pitre 提交于 
      The kmap virtual area borrows a 2MB range at the top of the 16MB area
below PAGE_OFFSET currently reserved for kernel modules and/or the
XIP kernel.  This 2MB corresponds to the range covered by 2 consecutive
second-level page tables, or a single pmd entry as seen by the Linux
page table abstraction.  Because XIP kernels are unlikely to be seen
on systems needing highmem support, there shouldn't be any shortage of
VM space for modules (14 MB for modules is still way more than twice the
typical usage).

Because the virtual mapping of highmem pages can go away at any moment
after kunmap() is called on them, we need to bypass the delayed cache
flushing provided by flush_dcache_page() in that case.

The atomic kmap versions are based on fixmaps, and
__cpuc_flush_dcache_page() is used directly in that case.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
      d73cd428
    • N
      [ARM] fixmap support · 5f0fbf9e
      由 Nicolas Pitre 提交于 
      This is the minimum fixmap interface expected to be implemented by
architectures supporting highmem.

We have a second level page table already allocated and covering
0xfff00000-0xffffffff because the exception vector page is located
at 0xffff0000, and various cache tricks already use some entries above
0xffff0000.  Therefore the PTEs covering 0xfff00000-0xfffeffff are free
to be used.

However the XScale cache flushing code already uses virtual addresses
between 0xfffe0000 and 0xfffeffff.

So this reserves the 0xfff00000-0xfffdffff range for fixmap stuff.

The Documentation/arm/memory.txt information is updated accordingly,
including the information about the actual top of DMA memory mapping
region which didn't match the code.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
      5f0fbf9e
  15. 13 3月, 2009 4 次提交
  17. 03 3月, 2009 1 次提交
  19. 19 2月, 2009 1 次提交
  21. 29 1月, 2009 1 次提交
    • N
      [ARM] 5366/1: fix shared memory coherency with VIVT L1 + L2 caches · 08e445bd
      由 Nicolas Pitre 提交于 
      When there are multiple L1-aliasing userland mappings of the same physical
page, we currently remap each of them uncached, to prevent VIVT cache
aliasing issues. (E.g. writes to one of the mappings not being immediately
visible via another mapping.)  However, when we do this remapping, there
could still be stale data in the L2 cache, and an uncached mapping might
bypass L2 and go straight to RAM.  This would cause reads from such
mappings to see old data (until the dirty L2 line is eventually evicted.)

This issue is solved by forcing a L2 cache flush whenever the shared page
is made L1 uncacheable.

Ideally, we would make L1 uncacheable and L2 cacheable as L2 is PIPT. But
Feroceon does not support that combination, and the TEX=5 C=0 B=0 encoding
for XSc3 doesn't appear to work in practice.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      08e445bd
  23. 26 1月, 2009 1 次提交
  25. 24 1月, 2009 1 次提交
  27. 12 1月, 2009 1 次提交
  29. 08 1月, 2009 1 次提交
    • D
      NOMMU: Rename ARM's struct vm_region · 9c93af1e
      由 David Howells 提交于 
      Rename ARM's struct vm_region so that I can introduce my own global version
for NOMMU.  It's feasible that the ARM version may wish to use my global one
instead.

The NOMMU vm_region struct defines areas of the physical memory map that are
under mmap.  This may include chunks of RAM or regions of memory mapped
devices, such as flash.  It is also used to retain copies of file content so
that shareable private memory mappings of files can be made.  As such, it may
be compatible with what is described in the banner comment for ARM's vm_region
struct.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
      9c93af1e
  31. 15 12月, 2008 1 次提交
  33. 14 12月, 2008 1 次提交
    • J
      [ARM] eliminate NULL test and memset after alloc_bootmem · 6ce1b871
      由 Julia Lawall 提交于 
      As noted by Akinobu Mita in patch b1fceac2,
alloc_bootmem and related functions never return NULL and always return a
zeroed region of memory.  Thus a NULL test or memset after calls to these
functions is unnecessary.

This was fixed using the following semantic patch.
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@@
expression E;
statement S;
@@

E = \(alloc_bootmem\|alloc_bootmem_low\|alloc_bootmem_pages\|alloc_bootmem_low_pages\|alloc_bootmem_node\|alloc_bootmem_low_pages_node\|alloc_bootmem_pages_node\)(...)
... when != E
(
- BUG_ON (E == NULL);
|
- if (E == NULL) S
)

@@
expression E,E1;
@@

E = \(alloc_bootmem\|alloc_bootmem_low\|alloc_bootmem_pages\|alloc_bootmem_low_pages\|alloc_bootmem_node\|alloc_bootmem_low_pages_node\|alloc_bootmem_pages_node\)(...)
... when != E
- memset(E,0,E1);
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6ce1b871
  35. 07 12月, 2008 1 次提交
  37. 02 12月, 2008 1 次提交
  39. 01 12月, 2008 2 次提交
  41. 30 11月, 2008 1 次提交
  43. 29 11月, 2008 1 次提交
  45. 28 11月, 2008 6 次提交