1. 14 8月, 2013 2 次提交
  2. 18 4月, 2013 1 次提交
  3. 11 7月, 2012 1 次提交
  4. 02 12月, 2011 1 次提交
  5. 19 5月, 2011 2 次提交
  6. 27 4月, 2011 1 次提交
  7. 11 3月, 2009 1 次提交
  8. 16 12月, 2008 1 次提交
  9. 25 9月, 2008 1 次提交
    • B
      POWERPC: Allow 32-bit hashed pgtable code to support 36-bit physical · 4ee7084e
      Becky Bruce 提交于
      This rearranges a bit of code, and adds support for
      36-bit physical addressing for configs that use a
      hashed page table.  The 36b physical support is not
      enabled by default on any config - it must be
      explicitly enabled via the config system.
      
      This patch *only* expands the page table code to accomodate
      large physical addresses on 32-bit systems and enables the
      PHYS_64BIT config option for 86xx.  It does *not*
      allow you to boot a board with more than about 3.5GB of
      RAM - for that, SWIOTLB support is also required (and
      coming soon).
      Signed-off-by: NBecky Bruce <becky.bruce@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      4ee7084e
  10. 04 8月, 2008 1 次提交
  11. 25 7月, 2008 1 次提交
    • B
      powerpc ioremap_prot · a1f242ff
      Benjamin Herrenschmidt 提交于
      This adds ioremap_prot and pte_pgprot() so that one can extract protection
      bits from a PTE and use them to ioremap_prot() (in order to support ptrace
      of VM_IO | VM_PFNMAP as per Rik's patch).
      
      This moves a couple of flag checks around in the ioremap implementations
      of arch/powerpc.  There's a side effect of allowing non-cacheable and
      non-guarded mappings on ppc32 which before would always have _PAGE_GUARDED
      set whenever _PAGE_NO_CACHE is.
      
      (standard ioremap will still set _PAGE_GUARDED, but ioremap_prot will be
      capable of setting such a non guarded mapping).
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NRik van Riel <riel@redhat.com>
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a1f242ff
  12. 30 6月, 2008 1 次提交
  13. 09 6月, 2008 1 次提交
    • T
      powerpc: Improve (in|out)_[bl]eXX() asm code · 0f3d6bcd
      Trent Piepho 提交于
      Since commit 4cb3cee0 the code generated
      for the in_beXX() and out_beXX() mmio functions has been sub-optimal.
      
      The out_leXX() family of functions are created with the macro
      DEF_MMIO_OUT_LE() while the out_beXX() family are created with
      DEF_MMIO_OUT_BE().  In what was perhaps a bit too much macro use, both of
      these macros are in turn created via the macro DEF_MMIO_OUT().
      
      For the LE versions, eventually they boil down to an asm that will look
      something like this:
      asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
      
      The issue is that the "stwbrx" instruction only comes in an indexed, or
      'x', version, in which the address is represented by the sum of two
      registers (the "0,%2").  Unfortunately, gcc doesn't have a constraint for
      an indexed memory reference.  The "m" constraint allows both indexed and
      offset, i.e. register plus constant, memory references and there is no
      "stwbr" version for offset references.  "m" also allows updating addresses
      and there is no 'u' version of "stwbrx" like there is with "stwux".
      
      The unused first operand to the asm is just to tell gcc that *addr is an
      output of the asm.  The address used is passed in a single register via the
      third asm operand, and the index register is just hard coded as 0.  This
      means gcc is forced to put the address in a single register and can't use
      index addressing, e.g. if one has the data in register 9, a base address in
      register 3 and an index in register 4, gcc must emit code like "add 11,4,3;
      stwbrx 9,0,11" instead of just "stwbrx 9,4,3".  This costs an extra add
      instruction and another register.
      
      For gcc 4.0 and older, there doesn't appear to be anything that can be
      done.  But for 4.1 and newer, there is a 'Z' constraint.  It does not allow
      "updating" addresses, but does allow both indexed and offset addresses.
      However, the only allowed constant offset is 0.  We can then use the
      undocumented 'y' operand modifier, which causes gcc to convert "0(reg)"
      into the equivilient "0,reg" format that can be used with stwbrx.
      
      This brings us the to problem with the BE version.  In this case, the "stw"
      instruction does have both indexed and non-indexed versions.  The final asm
      ends up looking like this:
      asm("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" (val), "r" (addr));
      
      The undocumented codes "%U0" and "%0X" will generate a 'u' if the memory
      reference should be an auto-updating one, and an 'x' if the memory
      reference is indexed, respectively.  The third operand is unused, it's just
      there because asm the code is reused from the LE version.  However, gcc
      does not know this, and generates unnecessary code to stick addr in a
      register!  To use the example from the LE version, gcc will generate "add
      11,4,3; stwx 9,4,3".  It is able to use the indexed address "4,3" for the
      "stwx", but still thinks it needs to put 4+3 into register 11, which will
      never be used.
      
      This also ends up happening a lot for the offset addressing mode, where
      common code like this:  out_be32(&device_registers->some_register, data);
      uses an instruction like "stw 9, 42(3)", where register 3 has the pointer
      device_registers and 42 is the offset of some_register in that structure.
      gcc will be forced to generate the unnecessary instruction "addi 11, 3, 42"
      to put the address into a single (unused) register.
      
      The in_* versions end up having these exact same problems as well.
      Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
      CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: Andreas Schwab <schwab@suse.de>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      0f3d6bcd
  14. 31 5月, 2008 1 次提交
  15. 05 5月, 2008 1 次提交
  16. 24 4月, 2008 1 次提交
  17. 11 12月, 2007 1 次提交
  18. 20 10月, 2007 1 次提交
  19. 17 10月, 2007 1 次提交
  20. 15 10月, 2007 1 次提交
  21. 03 10月, 2007 1 次提交
    • H
      [POWERPC] ppc64: support CONFIG_DEBUG_PREEMPT · 048c8bc9
      Hugh Dickins 提交于
      Add CONFIG_DEBUG_PREEMPT support to ppc64: it was useful for testing
      get_paca() preemption.  Cheat a little, just use debug_smp_processor_id()
      in the debug version of get_paca(): it contains all the right checks and
      reporting, though get_paca() doesn't really use smp_processor_id().
      
      Use local_paca for what might have been called __raw_get_paca().
      Silence harmless warnings from io.h and lparcfg.c with local_paca -
      it is okay for iseries_lparcfg_data to be referencing shared_proc
      with preemption enabled: all cpus should show the same value for
      shared_proc.
      
      Why do other architectures need TRACE_IRQFLAGS_SUPPORT for DEBUG_PREEMPT?
      I don't know, ppc64 appears to get along fine without it.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      048c8bc9
  22. 14 9月, 2007 1 次提交
    • T
      [POWERPC] add clrsetbits macros · dc967d7f
      Timur Tabi 提交于
      This patch adds the clrsetbits_xxx() macros, which are used to set and clear
      multiple bits in a single read-modify-write operation.  Specify the bits to
      clear in the 'clear' parameter and the bits to set in the 'set' parameter.
      These macros can also be used to set a multiple-bit bit pattern using a mask,
      by specifying the mask in the 'clear' parameter and the new bit pattern in the
      'set' parameter.  There are big-endian and little-endian versions for 8, 16,
      32, and 64 bits.
      Signed-off-by: NTimur Tabi <timur@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      dc967d7f
  23. 22 8月, 2007 1 次提交
  24. 14 6月, 2007 2 次提交
    • D
      [POWERPC] Abolish iopa(), mm_ptov(), io_block_mapping() from arch/powerpc · 90ac19a8
      David Gibson 提交于
      These old-fashioned IO mapping functions no longer have any callers in
      code which remains relevant on arch/powerpc.  Therefore, this removes
      them from arch/powerpc.
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      90ac19a8
    • B
      [POWERPC] Rewrite IO allocation & mapping on powerpc64 · 3d5134ee
      Benjamin Herrenschmidt 提交于
      This rewrites pretty much from scratch the handling of MMIO and PIO
      space allocations on powerpc64.  The main goals are:
      
       - Get rid of imalloc and use more common code where possible
       - Simplify the current mess so that PIO space is allocated and
         mapped in a single place for PCI bridges
       - Handle allocation constraints of PIO for all bridges including
         hot plugged ones within the 2GB space reserved for IO ports,
         so that devices on hotplugged busses will now work with drivers
         that assume IO ports fit in an int.
       - Cleanup and separate tracking of the ISA space in the reserved
         low 64K of IO space. No ISA -> Nothing mapped there.
      
      I booted a cell blade with IDE on PIO and MMIO and a dual G5 so
      far, that's it :-)
      
      With this patch, all allocations are done using the code in
      mm/vmalloc.c, though we use the low level __get_vm_area with
      explicit start/stop constraints in order to manage separate
      areas for vmalloc/vmap, ioremap, and PCI IOs.
      
      This greatly simplifies a lot of things, as you can see in the
      diffstat of that patch :-)
      
      A new pair of functions pcibios_map/unmap_io_space() now replace
      all of the previous code that used to manipulate PCI IOs space.
      The allocation is done at mapping time, which is now called from
      scan_phb's, just before the devices are probed (instead of after,
      which is by itself a bug fix). The only other caller is the PCI
      hotplug code for hot adding PCI-PCI bridges (slots).
      
      imalloc is gone, as is the "sub-allocation" thing, but I do beleive
      that hotplug should still work in the sense that the space allocation
      is always done by the PHB, but if you unmap a child bus of this PHB
      (which seems to be possible), then the code should properly tear
      down all the HPTE mappings for that area of the PHB allocated IO space.
      
      I now always reserve the first 64K of IO space for the bridge with
      the ISA bus on it. I have moved the code for tracking ISA in a separate
      file which should also make it smarter if we ever are capable of
      hot unplugging or re-plugging an ISA bridge.
      
      This should have a side effect on platforms like powermac where VGA IOs
      will no longer work. This is done on purpose though as they would have
      worked semi-randomly before. The idea at this point is to isolate drivers
      that might need to access those and fix them by providing a proper
      function to obtain an offset to the legacy IOs of a given bus.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      3d5134ee
  25. 27 4月, 2007 1 次提交
  26. 07 2月, 2007 1 次提交
    • V
      [POWERPC] Fix kernel build errors for mpc8272ads and mpc8560ads · 5427828e
      Vitaly Bordug 提交于
      Recent update of asm-powerpc/io.h caused cpm-related stuff to break in the
      current kernel. Current patch fixes it, as well as other inconsistencies
      expressed, that do not permit targets from working properly:
      
      - Updated dts with a chosen node with interrupt controller,
      - fixed messed device IDs among CPM2 SoC devices,
      - corrected odd header name and fixed type in defines,
      - Added 82xx subdir to the powerpc/platforms Makefile, missed during
        initial commit,
      - new solely-powerpc header file for 8260 family (was using one from
        arch/ppc, this one cleaned up from the extra stuff), in fact for now
        a placeholder to get the board-specific includes for stuff not yet
        capable to live with devicetree peeks only
      - Fixed couple of misprints in reference mpc8272 dts.
      Signed-off-by: NVitaly Bordug <vbordug@ru.mvista.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      5427828e
  27. 04 12月, 2006 4 次提交
    • A
      [POWERPC] include/asm-powerpc/: "extern inline" -> "static inline" · 4cfbdfff
      Adrian Bunk 提交于
      "extern inline" generates a warning with -Wmissing-prototypes and I'm
      currently working on getting the kernel cleaned up for adding this to
      the CFLAGS since it will help us to avoid a nasty class of runtime
      errors.
      
      If there are places that really need a forced inline, __always_inline
      would be the correct solution.
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      4cfbdfff
    • B
      [POWERPC] Fix __raw* accessors · 757db1ed
      Benjamin Herrenschmidt 提交于
      The new IO accessor code allows to stick a token in the top bit of MMIO
      addresses which gets masked out during actual accesses. However, the
      __raw_* accessors forgot to mask it out. This fixes it.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      757db1ed
    • B
      [POWERPC] Merge 32 and 64 bits asm-powerpc/io.h · 68a64357
      Benjamin Herrenschmidt 提交于
      powerpc: Merge 32 and 64 bits asm-powerpc/io.h
      
      The rework on io.h done for the new hookable accessors made it easier,
      so I just finished the work and merged 32 and 64 bits io.h for arch/powerpc.
      
      arch/ppc still uses the old version in asm-ppc, there is just too much gunk
      in there that I really can't be bothered trying to cleanup.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      68a64357
    • B
      [POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits · 4cb3cee0
      Benjamin Herrenschmidt 提交于
      This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
      and PIO) and provides a generic way for other platforms to do so (we
      have need to do that for various other platforms).
      
      While reworking the IO ops, I ended up doing some spring cleaning in
      io.h and eeh.h which I might want to split into 2 or 3 patches (among
      others, eeh.h had a lot of useless stuff in it).
      
      A side effect is that EEH for PIO should work now (it used to pass IO
      ports down to the eeh address check functions which is bogus).
      
      Also, new are MMIO "repeat" ops, which other archs like ARM already had,
      and that we have too now: readsb, readsw, readsl, writesb, writesw,
      writesl.
      
      In the long run, I might also make EEH use the hooks instead
      of wrapping at the toplevel, which would make things even cleaner and
      relegate EEH completely in platforms/iseries, but we have to measure the
      performance impact there (though it's really only on MMIO reads)
      
      Since I also need to hook on ioremap, I shuffled the functions a bit
      there. I introduced ioremap_flags() to use by drivers who want to pass
      explicit flags to ioremap (and it can be hooked). The old __ioremap() is
      still there as a low level and cannot be hooked, thus drivers who use it
      should migrate unless they know they want the low level version.
      
      The patch "arch provides generic iomap missing accessors" (should be
      number 4 in this series) is a pre-requisite to provide full iomap
      API support with this patch.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      4cb3cee0
  28. 01 11月, 2006 1 次提交
    • H
      [POWERPC] Make mmiowb's io_sync preempt safe · 292f86f0
      Hugh Dickins 提交于
      If mmiowb() is always used prior to releasing spinlock as Doc suggests,
      then it's safe against preemption; but I'm not convinced that's always
      the case.  If preemption occurs between sync and get_paca()->io_sync = 0,
      I believe there's no problem.  But in the unlikely event that gcc does
      the store relative to another register than r13 (as it did with current),
      then there's a small danger of setting another cpu's io_sync to 0, after
      it had just set it to 1.  Rewrite ppc64 mmiowb to prevent that.
      
      The remaining io_sync assignments in io.h all get_paca()->io_sync = 1,
      which is harmless even if preempted to the wrong cpu (the context switch
      itself syncs); and those in spinlock.h are while preemption is disabled.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      292f86f0
  29. 12 10月, 2006 1 次提交
  30. 03 10月, 2006 1 次提交
    • O
      [PATCH] restore parport_pc probing on powermac · 873ef76b
      Olaf Hering 提交于
      The last change for partport_pc did fix the common case for all PowerMacs,
      but it broke the case for PCI multiport IO cards.  In fact, the config
      option CONFIG_PARPORT_PC_SUPERIO=y lead to a hard crash when cups probed
      the parport driver.  It enables the winbond and smsc probing.
      
      Remove the PARPORT_BASE check again, parport_pc_find_nonpci_ports() will
      take care of it.  All powerpc configs should have
      CONFIG_PARPORT_PC_SUPERIO=n, the code did not find anything on the chrp
      boards we tested it on.
      
      Tested on a G4/466 with a PCI card:
      
      0001:10:13.0 Serial controller: Timedia Technology Co Ltd PCI2S550 (Dual 16550 UART) (rev 01) (prog-if 02 [16550])
              Subsystem: Timedia Technology Co Ltd Unknown device 5079
              Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
              Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
              Interrupt: pin A routed to IRQ 53
              Region 0: I/O ports at f2000800 [size=32]
              Region 2: I/O ports at f2000870 [size=8]
              Region 3: I/O ports at f2000860 [size=8]
      Signed-off-by: NOlaf Hering <olaf@aepfle.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Adam Belay <ambx1@neo.rr.com>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      873ef76b
  31. 01 10月, 2006 1 次提交
    • O
      [PATCH] update legacy io handling for pmac · 30cbc222
      Olaf Hering 提交于
      ppc can boot one single binary on prep, chrp and pmac boards.  ppc64 can
      boot one single binary on pseries and G5 boards.  pmac has no legacy io,
      probing for PC style legacy hardware (or accessing the legacy io area
      regulary) may lead to a hard crash:
      
      * add check for parport_pc, exit on pmac.  32bit chrp has no
        ->check_legacy_ioport, the probe is always called.  64bit chrp has
        check_legacy_ioport, check for a "parallel" node
      
      * add check for isapnp, only PReP boards may have real ISA slots.  32bit
        PReP will have no ->check_legacy_ioport, the probe is always called.
      
      * update code in i8042_platform_init.  Run ->check_legacy_ioport first,
        always call request_region.  No functional change.  Remove whitespace
        before i8042_reset init.
      Signed-off-by: NOlaf Hering <olaf@aepfle.de>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Adam Belay <ambx1@neo.rr.com>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      30cbc222
  32. 22 9月, 2006 1 次提交
  33. 20 9月, 2006 2 次提交