Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 03 11月, 2005 1 次提交
  3. 01 11月, 2005 1 次提交
    • D
      [PATCH] powerpc: Merge bitops.h · a0e60b20
      由 David Gibson 提交于 
      Here's a revised version.  This re-introduces the set_bits() function
from ppc64, which I removed because I thought it was unused (it exists
on no other arch).  In fact it is used in the powermac interrupt code
(but not on pSeries).

- We use LARXL/STCXL macros to generate the right (32 or 64 bit)
  instructions, similar to LDL/STL from ppc_asm.h, used in fpu.S

- ppc32 previously used a full "sync" barrier at the end of
  test_and_*_bit(), whereas ppc64 used an "isync".  The merged version
  uses "isync", since I believe that's sufficient.

- The ppc64 versions of then minix_*() bitmap functions have changed
  semantics.  Previously on ppc64, these functions were big-endian
  (that is bit 0 was the LSB in the first 64-bit, big-endian word).
  On ppc32 (and x86, for that matter, they were little-endian.  As far
  as I can tell, the big-endian usage was simply wrong - I guess
  no-one ever tried to use minixfs on ppc64.

- On ppc32 find_next_bit() and find_next_zero_bit() are no longer
  inline (they were already out-of-line on ppc64).

- For ppc64, sched_find_first_bit() has moved from mmu_context.h to
  the merged bitops.  What it was doing in mmu_context.h in the first
  place, I have no idea.

- The fls() function is now implemented using the cntlzw instruction
  on ppc64, instead of generic_fls(), as it already was on ppc32.

- For ARCH=ppc, this patch requires adding arch/powerpc/lib to the
  arch/ppc/Makefile.  This in turn requires some changes to
  arch/powerpc/lib/Makefile which didn't correctly handle ARCH=ppc.

Built and running on G5.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a0e60b20
  5. 31 10月, 2005 3 次提交
  7. 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
  9. 29 10月, 2005 2 次提交
  11. 28 10月, 2005 1 次提交
  13. 27 10月, 2005 1 次提交
    • D
      [PATCH] powerpc: Fix handling of fpscr on 64-bit · 25c8a78b
      由 David Gibson 提交于 
      The recent merge of fpu.S broken the handling of fpscr for
ARCH=powerpc and CONFIG_PPC64=y.  FP registers could be corrupted,
leading to strange random application crashes.

The confusion arises, because the thread_struct has (and requires) a
64-bit area to save the fpscr, because we use load/store double
instructions to get it in to/out of the FPU.  However, only the low
32-bits are actually used, so we want to treat it as a 32-bit quantity
when manipulating its bits to avoid extra load/stores on 32-bit.  This
patch replaces the current definition with a structure of two 32-bit
quantities (pad and val), to clarify things as much as is possible.
The 'val' field is used when manipulating bits, the structure itself
is used when obtaining the address for loading/unloading the value
from the FPU.

While we're at it, consolidate the 4 (!) almost identical versions of
cvt_fd() and cvt_df() (arch/ppc/kernel/misc.S,
arch/ppc64/kernel/misc.S, arch/powerpc/kernel/misc_32.S,
arch/powerpc/kernel/misc_64.S) into a single version in fpu.S.  The
new version takes a pointer to thread_struct and applies the correct
offset itself, rather than a pointer to the fpscr field itself, again
to avoid confusion as to which is the correct field to use.

Finally, this patch makes ARCH=ppc64 also use the consolidated fpu.S
code, which it previously did not.

Built for G5 (ARCH=ppc64 and ARCH=powerpc), 32-bit powermac (ARCH=ppc
and ARCH=powerpc) and Walnut (ARCH=ppc, CONFIG_MATH_EMULATION=y).
Booted on G5 (ARCH=powerpc) and things which previously fell over no
longer do.
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      25c8a78b
  15. 22 10月, 2005 1 次提交
  17. 21 10月, 2005 1 次提交
    • D
      [PATCH] powerpc: Merge thread_info.h · 6cb7bfeb
      由 David Gibson 提交于 
      Merge ppc32 and ppc64 versions of thread_info.h.  They were pretty
similar already, the chief changes are:

	- Instead of inline asm to implement current_thread_info(),
which needs to be different for ppc32 and ppc64, we use C with an
asm("r1") register variable.  gcc turns it into the same asm as we
used to have for both platforms.
	- We replace ppc32's 'local_flags' with the ppc64
'syscall_noerror' field.  The noerror flag was in fact the only thing
in the local_flags field anyway, so the ppc64 approach is simpler, and
means we only need a load-immediate/store instead of load/mask/store
when clearing the flag.
	- In readiness for 64k pages, when THREAD_SIZE will be less
than a page, ppc64 used kmalloc() rather than get_free_pages() to
allocate the kernel stack.  With this patch we do the same for ppc32,
since there's no strong reason not to.
	- For ppc64, we no longer export THREAD_SHIFT and THREAD_SIZE
via asm-offsets, thread_info.h can now be safely included in asm, as
on ppc32.

Built and booted on G4 Powerbook (ARCH=ppc and ARCH=powerpc) and
Power5 (ARCH=ppc64 and ARCH=powerpc).
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      6cb7bfeb
  19. 20 10月, 2005 5 次提交
  21. 19 10月, 2005 1 次提交
  23. 18 10月, 2005 2 次提交
  25. 17 10月, 2005 3 次提交
  27. 13 10月, 2005 2 次提交
  29. 12 10月, 2005 2 次提交
    • B
      [PATCH] ppc32: Tell userland about lack of standard TB · d8e998c5
      由 Benjamin Herrenschmidt 提交于 
      Glibc is about to get some new high precision timer stuff that relies on
the standard timebase of the PPC architecture.

However, some (rare & old) CPUs do not have such timebase and it is a
bit annoying to have your stuff just crash because you are running on
the wrong CPU...

This exposes to userland a CPU feature bit that tells that the current
processor doesn't have a standard timebase.  It's negative logic so that
glibc will still "just work" on older kernels (it will just be unhappy
on those old CPUs but that doesn't really matter as distro tend to
update glibc & kernel at the same time).
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d8e998c5
    • P
      [PATCH] ppc highmem fix · a0c111c6
      由 Paolo Galtieri 提交于 
      I've noticed that the calculations for seg_size and nr_segs in
__dma_sync_page_highmem() (arch/ppc/kernel/dma-mapping.c) are wrong.  The
incorrect calculations can result in either an oops or a panic when running
fsck depending on the size of the partition.

The problem with the seg_size calculation is that it can result in a
negative number if size is offset > size.  The problem with the nr_segs
caculation is returns the wrong number of segments, e.g.  it returns 1 when
size is 200 and offset is 4095, when it should return 2 or more.
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a0c111c6
  31. 11 10月, 2005 2 次提交
    • P
      ppc: Various minor compile fixes · fd582ec8
      由 Paul Mackerras 提交于 
      This fixes up a variety of minor problems in compiling with ARCH=ppc
arising from using the merged versions of various header files.
A lot of the changes are just adding #include <asm/machdep.h> to
files that use ppc_md or smp_ops_t.

This also arranges for us to use semaphore.c, vecemu.c, vector.S and
fpu.S from arch/powerpc/kernel when compiling with ARCH=ppc.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      fd582ec8
    • P
      ppc: Adapt to asm-powerpc/irq.h irq_canonicalize changes · 35d81a4b
      由 Paul Mackerras 提交于 
      Now instead of having a ppc_md function, we just have a variable
which says whether to do the i8259 irq canonicalization or not,
and set that variable on the platforms that need that.  It looks
to me that radstone_ppc7d was trying to use irq canonicalization
for something else in a broken kind of way - it will need to be
fixed properly.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      35d81a4b
  33. 10 10月, 2005 2 次提交
  35. 06 10月, 2005 1 次提交
  37. 04 10月, 2005 2 次提交
  39. 01 10月, 2005 1 次提交
  41. 30 9月, 2005 2 次提交
  43. 28 9月, 2005 3 次提交