1. 13 9月, 2006 6 次提交
  2. 31 8月, 2006 25 次提交
  3. 30 8月, 2006 9 次提交
    • S
      [POWERPC] iseries: Define insw et al. so libata/ide will compile · e7498656
      Stephen Rothwell 提交于
      These are build fixes that enable (for example) libata and the ide
      code to actually build on iSeries.  The associated hardware will never
      be supported on legacy iSeries, so the code paths don't actually need
      to work, but it is useful (especially for a combined kernel) if the
      code can build.
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e7498656
    • P
      [POWERPC] Fix irq enable/disable in smp_generic_take_timebase · 467c3780
      Paul Mackerras 提交于
      Eran Ben-Avi <eranpublic@yahoo.com> pointed out that the arch/ppc version
      of smp_generic_take_timebase disables interrupts on entry but exits without
      restoring them.  However, both it and the arch/powerpc version have another
      problem, which is that they use local_irq_disable/enable rather than
      local_irq_save/restore, and they are called with interrupts disabled.
      
      This fixes both problems; it changes a return to a break in the arch/ppc
      version, and changes both versions to use local_irq_save/restore.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      467c3780
    • P
      [POWERPC] Fix problem with time not advancing on 32-bit platforms · e0d872d5
      Paul Mackerras 提交于
      This fixes a problem introduced in 5db9fa95.
      The last_jiffy per-cpu variable is only 32 bits on 32-bit machines, but it
      was being compared with a 64-bit quantity (tb_next_jiffy), which resulted in
      time not advancing.
      
      This fixes it by changing last_jiffy to be 64 bits on all platforms.  With
      this, we no longer need tb_last_stamp as a 32-bit version of tb_last_jiffy,
      so this gets rid of tb_last_stamp and we just use tb_last_jiffy instead.
      This also fixes a bug when the boot cpu is not online, because using
      tb_last_stamp could have caused the wrong timebase origin value to be used
      when calculating the time of day.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e0d872d5
    • P
      [POWERPC] Restore copyright notice in arch/powerpc/kernel/fpu.S · fea23bfe
      Paul Mackerras 提交于
      This code got moved from head.S but the copyright notice on head.S didn't
      get transferred with it.  Noticed by Cort Dougan <cort@fsmlabs.com>.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      fea23bfe
    • W
      [POWERPC] Fix up ibm_architecture_vec definition · 11e9ed43
      Will Schmidt 提交于
      This problem was noticed by one of the Phyp firmware folks.
      Our ibm,client-architecture-support call was failing.
      This corrects the vector length parameters being passed in.
      Signed-off-by: NWill Schmidt <will_schmidt@vnet.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      11e9ed43
    • B
      [POWERPC] Make OF irq map code detect more error cases · 006b64de
      Benjamin Herrenschmidt 提交于
      Device-tree bugs on js20 with some versions of SLOF were causing the
      interrupt for IDE to not be parsed correctly and fail to boot. This
      patch adds a bit more sanity checking to the parser to detect some of
      those errors and fail instead of returning bogus information.  The
      powerpc PCI code can then trigger a fallback that works on those
      machines.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      006b64de
    • Z
      [POWERPC] Support for "weird" MPICs and fixup mpc7448_hpc2 · 7233593b
      Zang Roy-r61911 提交于
      This adds a new hardware information table for mpic. This enables
      the mpic code to deal with mpic controllers with different register
      layouts and hardware behaviours.
      
      This introduces CONFIG_MPIC_WEIRD.  For boards with non standard mpic
      controllers, select CONFIG_MPIC_WEIRD and add its hardware information
      in the mpic_infos[] array.
      
      TSI108/109 PIC takes the first index of weird hardware information
      table.  :)  The table can be extended. The Tsi108/109 PIC looks like
      standard OpenPIC but, in fact, is different in register mapping and
      behavior.
      
      The patch does not affect the behavior of standard mpic.  If
      CONFIG_MPIC_WEIRD is not defined, the code is essentially identical to
      the current code.
      
      [benh@kernel.crashing.org:
      This patch is a slightly cleaned up version of Zang Roy's support for
      the TSI108 MPIC variant. It also fixes up MPC7448_hpc2 to use the new
      version of the type macros and changes the way MPIC is selected in
      Kconfig to better match what is done for other system devices.
      ]
      Signed-off-by: NRoy Zang <tie-fei.zang@freescale.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      7233593b
    • K
      [SUNLANCE]: Fix probing problem. · 404dda85
      Krzysztof Helt 提交于
      The current probe table causes ledma and lebuffer
      "le" devices to get probed twice which is not what
      we want.
      
      Match just "le" and look directly at the parent to get the correct
      top-level node information.
      Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      404dda85
    • D
      [SPARC64]: Fix X server hangs due to large pages. · 47f2c360
      David S. Miller 提交于
      This problem was introduced by changeset
      14778d90
      
      Unlike the hugetlb code paths, the normal fault code is not setup to
      propagate PTE changes for large page sizes correctly like the ones we
      make for I/O mappings in io_remap_pfn_range().
      
      It is absolutely necessary to update all sub-ptes of a largepage
      mapping on a fault.  Adding special handling for this would add
      considerably complexity to tlb_batch_add().  So let's just side-step
      the issue and forcefully dirty any writable PTEs created by
      io_remap_pfn_range().
      
      The only other real option would be to disable to large PTE code of
      io_remap_pfn_range() and we really don't want to do that.
      
      Much thanks to Mikael Pettersson for tracking down this problem and
      testing debug patches.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      47f2c360