1. 18 5月, 2018 1 次提交
    • M
      powerpc/io: Add __raw_writeq_be() __raw_rm_writeq_be() · 8056fe28
      Michael Ellerman 提交于
      Add byte-swapping versions of __raw_writeq() and __raw_rm_writeq().
      
      This allows us to avoid sparse warnings caused by passing __be64 to
      __raw_writeq(), which takes unsigned long:
      
        arch/powerpc/platforms/powernv/pci-ioda.c:1981:38:
        warning: incorrect type in argument 1 (different base types)
            expected unsigned long [unsigned] v
            got restricted __be64 [usertype] <noident>
      
      It's also generally preferable to use a byte-swapping accessor rather
      than doing it by hand in the code, which is more bug prone.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: NSamuel Mendoza-Jonas <sam@mendozajonas.com>
      8056fe28
  2. 05 4月, 2018 1 次提交
  3. 21 4月, 2017 1 次提交
  4. 13 4月, 2017 1 次提交
    • M
      powerpc: Drop include of linux/io.h from asm/io.h · 590c369e
      Michael Ellerman 提交于
      Currently powerpc's asm/io.h includes linux/io.h, and linux/io.h
      includes asm/io.h.
      
      This can cause problems because depending on which is included first the
      order of definitions between the two files will change.
      
      The include of linux/io.h was added back in 2008 in commit b41e5fff
      ("[POWERPC] devres: Add devm_ioremap_prot()"). It's not entirely clear
      it was needed then, but devm_ioremap_prot() has since been removed
      entirely as unused, in dedd24a1 ("powerpc: Remove unused
      devm_ioremap_prot()").
      
      So it seems to be unnecessary and can potentially cause problems, so
      remove the include of linux/io.h from asm/io.h
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      590c369e
  5. 10 4月, 2017 1 次提交
  6. 14 11月, 2016 1 次提交
  7. 09 9月, 2016 1 次提交
  8. 01 3月, 2016 1 次提交
  9. 17 12月, 2015 1 次提交
  10. 29 7月, 2015 1 次提交
    • L
      arch/*/io.h: Add ioremap_uc() to all architectures · 4c73e892
      Luis R. Rodriguez 提交于
      This adds ioremap_uc() only for architectures that do not
      include asm-generic.h/io.h as that already provides a default
      definition for them for both cases where you have CONFIG_MMU
      and you do not, and because of this, the number of architectures
      this patch address is less than the architectures that the
      ioremap_wt() patch addressed, "arch/*/io.h: Add ioremap_wt() to
      all architectures").
      
      In order to reduce the number of architectures we have to
      modify by adding new architecture IO APIs we'll have to review
      the architectures in this patch, see why they can't add
      asm-generic.h/io.h or issues that would be created by doing
      so and then spread a consistent inclusion of this header
      towards the end of their own header. For instance arch/metag
      includes the asm-generic/io.h *before* the ioremap*()
      definitions, this should be the other way around but only
      once we have guard wrappers for the non-MMU case also for
      asm-generic/io.h.
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Cc: Abhilash Kesavan <a.kesavan@samsung.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      Cc: Kyle McMartin <kyle@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-am33-list@redhat.com
      Cc: linux-arch@vger.kernel.org
      Cc: linux-m68k@lists.linux-m68k.org
      Cc: linux-sh@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lkml.kernel.org/r/20150728181713.GB30479@wotan.suse.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      4c73e892
  11. 10 11月, 2014 1 次提交
  12. 21 10月, 2014 1 次提交
    • W
      powerpc: io: implement dummy relaxed accessor macros for writes · 5da59057
      Will Deacon 提交于
      write{b,w,l,q}_relaxed are implemented by some architectures in order to
      permit memory-mapped I/O accesses with weaker barrier semantics than the
      non-relaxed variants.
      
      This patch adds dummy macros for the write accessors to powerpc, in the
      same vein as the dummy definitions for the relaxed read accessors.
      
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      5da59057
  13. 05 12月, 2013 1 次提交
  14. 11 10月, 2013 2 次提交
    • B
      powerpc: Enable /dev/port when isa_io_special is set · ac237b65
      Benjamin Herrenschmidt 提交于
      isa_io_special is set when the platform provides a "special"
      implementation of inX/outX via some FW interface for example.
      
      Such a platform doesn't need an ISA bridge on PCI, and so /dev/port
      should be made available even if one isn't present.
      
      This makes the LPC bus IOs accessible via /dev/port on PowerNV Power8
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ac237b65
    • I
      powerpc: Support endian agnostic MMIO · 15cba23e
      Ian Munsie 提交于
      This patch maps the MMIO functions for 32bit PowerPC to their
      appropriate instructions depending on CPU endianness.
      
      The macros used to create the corresponding inline functions are also
      renamed by this patch. Previously they had BE or LE in their names which
      was misleading - they had nothing to do with endianness, but actually
      created different instruction forms so their new names reflect the
      instruction form they are creating (D-Form and X-Form).
      
      Little endian 64bit PowerPC is not supported, so the lack of mappings
      (and corresponding breakage) for that case is intentional to bring the
      attention of anyone doing a 64bit little endian port. 64bit big endian
      is unaffected.
      
      [ Added 64 bit versions - Anton ]
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      15cba23e
  15. 14 8月, 2013 2 次提交
  16. 18 4月, 2013 1 次提交
  17. 11 7月, 2012 1 次提交
  18. 02 12月, 2011 1 次提交
  19. 19 5月, 2011 2 次提交
  20. 27 4月, 2011 1 次提交
  21. 11 3月, 2009 1 次提交
  22. 16 12月, 2008 1 次提交
  23. 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
  24. 04 8月, 2008 1 次提交
  25. 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
  26. 30 6月, 2008 1 次提交
  27. 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
  28. 31 5月, 2008 1 次提交
  29. 05 5月, 2008 1 次提交
  30. 24 4月, 2008 1 次提交
  31. 11 12月, 2007 1 次提交
  32. 20 10月, 2007 1 次提交
  33. 17 10月, 2007 1 次提交
  34. 15 10月, 2007 1 次提交
  35. 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
  36. 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
  37. 22 8月, 2007 1 次提交