Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 08 12月, 2006 2 次提交
    • H
      [S390] Use add_active_range() and free_area_init_nodes(). · 39b742f9
      由 Heiko Carstens 提交于 
      Size zones and holes in an architecture independent manner for s390.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      39b742f9
    • H
      [S390] Virtual memmap for s390. · f4eb07c1
      由 Heiko Carstens 提交于 
      Virtual memmap support for s390. Inspired by the ia64 implementation.

Unlike ia64 we need a mechanism which allows us to dynamically attach
shared memory regions.
These memory regions are accessed via the dcss device driver. dcss
implements the 'direct_access' operation, which requires struct pages
for every single shared page.
Therefore this implementation provides an interface to attach/detach
shared memory:

int add_shared_memory(unsigned long start, unsigned long size);
int remove_shared_memory(unsigned long start, unsigned long size);

The purpose of the add_shared_memory function is to add the given
memory range to the 1:1 mapping and to make sure that the
corresponding range in the vmemmap is backed with physical pages.
It also initialises the new struct pages.

remove_shared_memory in turn only invalidates the page table
entries in the 1:1 mapping. The page tables and the memory used for
struct pages in the vmemmap are currently not freed. They will be
reused when the next segment will be attached.
Given that the maximum size of a shared memory region is 2GB and
in addition all regions must reside below 2GB this is not too much of
a restriction, but there is room for improvement.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      f4eb07c1
  3. 04 12月, 2006 4 次提交
  5. 06 11月, 2006 1 次提交
    • H
      [S390] revert add_active_range() usage patch. · bcc8bcb1
      由 Heiko Carstens 提交于 
      Commit 7676bef9 breaks DCSS support on
s390. DCSS needs initialized struct pages to work. With the usage of
add_active_range() only the struct pages for physically present pages
are initialized.
This could be fixed if the DCSS driver would initiliaze the struct pages
itself, but this doesn't work too. This is because the mem_map array
does not include holes after the last present memory area and therefore
there is nothing that could be initialized.
To fix this and to avoid some dirty hacks revert this patch for now.
Will be added later when we move to a virtual mem_map.

Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Adrian Bunk <bunk@stusta.de>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      bcc8bcb1
  7. 06 10月, 2006 1 次提交
  9. 05 10月, 2006 2 次提交
  11. 30 9月, 2006 1 次提交
  13. 28 9月, 2006 2 次提交
  15. 26 9月, 2006 2 次提交
  17. 20 9月, 2006 3 次提交
  19. 16 8月, 2006 1 次提交
  21. 12 7月, 2006 1 次提交
  23. 02 7月, 2006 1 次提交
  25. 01 7月, 2006 1 次提交
  27. 28 4月, 2006 1 次提交
  29. 24 3月, 2006 1 次提交
  31. 22 3月, 2006 1 次提交
  33. 08 2月, 2006 1 次提交
  35. 07 1月, 2006 1 次提交
  37. 09 11月, 2005 1 次提交
  39. 07 11月, 2005 2 次提交
  41. 30 10月, 2005 1 次提交
    • H
      [PATCH] mm: init_mm without ptlock · 872fec16
      由 Hugh Dickins 提交于 
      First step in pushing down the page_table_lock.  init_mm.page_table_lock has
been used throughout the architectures (usually for ioremap): not to serialize
kernel address space allocation (that's usually vmlist_lock), but because
pud_alloc,pmd_alloc,pte_alloc_kernel expect caller holds it.

Reverse that: don't lock or unlock init_mm.page_table_lock in any of the
architectures; instead rely on pud_alloc,pmd_alloc,pte_alloc_kernel to take
and drop it when allocating a new one, to check lest a racing task already
did.  Similarly no page_table_lock in vmalloc's map_vm_area.

Some temporary ugliness in __pud_alloc and __pmd_alloc: since they also handle
user mms, which are converted only by a later patch, for now they have to lock
differently according to whether or not it's init_mm.

If sources get muddled, there's a danger that an arch source taking
init_mm.page_table_lock will be mixed with common source also taking it (or
neither take it).  So break the rules and make another change, which should
break the build for such a mismatch: remove the redundant mm arg from
pte_alloc_kernel (ppc64 scrapped its distinct ioremap_mm in 2.6.13).

Exceptions: arm26 used pte_alloc_kernel on user mm, now pte_alloc_map; ia64
used pte_alloc_map on init_mm, now pte_alloc_kernel; parisc had bad args to
pmd_alloc and pte_alloc_kernel in unused USE_HPPA_IOREMAP code; ppc64
map_io_page forgot to unlock on failure; ppc mmu_mapin_ram and ppc64 im_free
took page_table_lock for no good reason.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      872fec16
  43. 05 9月, 2005 1 次提交
    • M
      [PATCH] s390: pfault interrupt race · b6d09449
      由 Martin Schwidefsky 提交于 
      There is a race in pfault_interrupt.  That function gets called two times for
each pfault notification.  Once with a subcode of 0 to indicate that a real
page is not available and once with a subcode of 0x80 to indicate that the
page is present again.

Since the two external interrupts can be delivered on two different cpus the
order in which the two calls are made is unpredictable.  It is possible that
the subcode 0x80 interrupt is completed before the subcode 0x00 interrupt has
done the wake_up() call.

To avoid calling wake_up() on an already removed task structure proper task
structure reference counting is needed.  Increase the reference counter in the
subcode 0x00 interrupt before setting pfault_wait to zero and return the
reference after the wake_up call.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b6d09449
  45. 26 6月, 2005 1 次提交
  47. 22 6月, 2005 1 次提交
  49. 05 6月, 2005 1 次提交
  51. 01 5月, 2005 2 次提交
  53. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus Torvalds 提交于 
      Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
      1da177e4