1. 07 11月, 2005 9 次提交
  2. 05 11月, 2005 1 次提交
  3. 03 11月, 2005 5 次提交
  4. 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 5 次提交
  6. 30 10月, 2005 2 次提交
    • 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
    • R
      Create platform_device.h to contain all the platform device details. · d052d1be
      Russell King 提交于
      Convert everyone who uses platform_bus_type to include
      linux/platform_device.h.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d052d1be
  7. 29 10月, 2005 10 次提交
  8. 28 10月, 2005 3 次提交
  9. 27 10月, 2005 2 次提交
    • K
      4b24b01c
    • 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
  10. 26 10月, 2005 2 次提交
    • P
      powerpc: Fixes to get the Longtrail CHRP a bit further · c4988820
      Paul Mackerras 提交于
      Talk about buggy firmware...  the OF on the Longtrail returns 0
      from the claim client service rather than -1 when the claim fails.
      It also has no device_type on the /memory node and blows up if
      the output buffer for package-to-path is too big.
      
      This also fixes a bug with calling alloc_up with align == 0, where
      we did _ALIGN_UP(alloc_bottom, 0) which will end up as 0.
      
      Lastly, we now check the return value (in r3) from calling the
      prom, and return -1 from call_prom if we get a negative value back.
      That is supposed to indicate that the requested client service
      doesn't exist.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      c4988820
    • P
      powerpc: Merge i8259.c into arch/powerpc/sysdev · f9bd170a
      Paul Mackerras 提交于
      This changes the parameters for i8259_init so that it takes two
      parameters: a physical address for generating an interrupt
      acknowledge cycle, and an interrupt number offset.  i8259_init
      now sets the irq_desc[] for its interrupts; all the callers
      were doing this, and that code is gone now.  This also defines
      a CONFIG_PPC_I8259 symbol to select i8259.o for inclusion, and
      makes the platforms that need it select that symbol.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f9bd170a