1. 14 8月, 2013 3 次提交
    • B
      powerpc: Better split CONFIG_PPC_INDIRECT_PIO and CONFIG_PPC_INDIRECT_MMIO · ecd73cc5
      Benjamin Herrenschmidt 提交于
      Remove the generic PPC_INDIRECT_IO and ensure we only add overhead
      to the right accessors. IE. If only CONFIG_PPC_INDIRECT_PIO is set,
      we don't add overhead to all MMIO accessors.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ecd73cc5
    • B
      powerpc/pmac: Early debug output on screen on 64-bit macs · 7191b615
      Benjamin Herrenschmidt 提交于
      We have a bunch of CONFIG_PPC_EARLY_DEBUG_* options that are intended
      for bringup/debug only. They hard wire a machine specific udbg backend
      very early on (before we even probe the platform), and use whatever
      tricks are available on each machine/cpu to be able to get some kind
      of output out there early on.
      
      So far, on powermac with no serial ports, we have CONFIG_PPC_EARLY_DEBUG_BOOTX
      to use the low-level btext engine on the screen, but it doesn't do much, at
      least on 64-bit. It only really gets enabled after the platform has been
      probed and the MMU enabled.
      
      This adds a way to enable it much earlier. From prom_init.c (while still
      running with Open Firmware), we grab the screen details and set things up
      using the physical address of the frame buffer.
      
      Then btext itself uses the "rm_ci" feature of the 970 processor (Real
      Mode Cache Inhibited) to access it while in real mode.
      
      We need to do a little bit of reorg of the btext code to inline things
      better, in order to limit how much we touch memory while in this mode as
      the consequences might be ... interesting.
      
      This successfully allowed me to debug problems early on with the G5
      (related to gold being broken vs. ppc64 kernels).
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7191b615
    • A
      powerpc: Fix a number of sparse warnings · b0d436c7
      Anton Blanchard 提交于
      Address some of the trivial sparse warnings in arch/powerpc.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      b0d436c7
  2. 08 8月, 2013 1 次提交
  3. 01 7月, 2013 1 次提交
    • C
      powerpc/smp: Section mismatch from smp_release_cpus to __initdata spinning_secondaries · 8246aca7
      Chen Gang 提交于
      the smp_release_cpus is a normal funciton and called in normal environments,
        but it calls the __initdata spinning_secondaries.
        need modify spinning_secondaries to match smp_release_cpus.
      
      the related warning:
        (the linker report boot_paca.33377, but it should be spinning_secondaries)
      
      -----------------------------------------------------------------------------
      
      WARNING: arch/powerpc/kernel/built-in.o(.text+0x23176): Section mismatch in reference from the function .smp_release_cpus() to the variable .init.data:boot_paca.33377
      The function .smp_release_cpus() references
      the variable __initdata boot_paca.33377.
      This is often because .smp_release_cpus lacks a __initdata
      annotation or the annotation of boot_paca.33377 is wrong.
      
      WARNING: arch/powerpc/kernel/built-in.o(.text+0x231fe): Section mismatch in reference from the function .smp_release_cpus() to the variable .init.data:boot_paca.33377
      The function .smp_release_cpus() references
      the variable __initdata boot_paca.33377.
      This is often because .smp_release_cpus lacks a __initdata
      annotation or the annotation of boot_paca.33377 is wrong.
      
      -----------------------------------------------------------------------------
      Signed-off-by: NChen Gang <gang.chen@asianux.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8246aca7
  4. 30 4月, 2013 1 次提交
    • A
      powerpc: Reduce PTE table memory wastage · 5c1f6ee9
      Aneesh Kumar K.V 提交于
      We allocate one page for the last level of linux page table. With THP and
      large page size of 16MB, that would mean we are wasting large part
      of that page. To map 16MB area, we only need a PTE space of 2K with 64K
      page size. This patch reduce the space wastage by sharing the page
      allocated for the last level of linux page table with multiple pmd
      entries. We call these smaller chunks PTE page fragments and allocated
      page, PTE page.
      
      In order to support systems which doesn't have 64K HPTE support, we also
      add another 2K to PTE page fragment. The second half of the PTE fragments
      is used for storing slot and secondary bit information of an HPTE. With this
      we now have a 4K PTE fragment.
      
      We use a simple approach to share the PTE page. On allocation, we bump the
      PTE page refcount to 16 and share the PTE page with the next 16 pte alloc
      request. This should help in the node locality of the PTE page fragment,
      assuming that the immediate pte alloc request will mostly come from the
      same NUMA node. We don't try to reuse the freed PTE page fragment. Hence
      we could be waisting some space.
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5c1f6ee9
  5. 15 2月, 2013 2 次提交
  6. 15 11月, 2012 1 次提交
  7. 27 9月, 2012 1 次提交
  8. 29 3月, 2012 1 次提交
  9. 05 3月, 2012 1 次提交
  10. 07 12月, 2011 1 次提交
  11. 16 11月, 2011 1 次提交
  12. 01 11月, 2011 1 次提交
  13. 20 9月, 2011 2 次提交
  14. 12 7月, 2011 1 次提交
    • P
      KVM: PPC: Allocate RMAs (Real Mode Areas) at boot for use by guests · aa04b4cc
      Paul Mackerras 提交于
      This adds infrastructure which will be needed to allow book3s_hv KVM to
      run on older POWER processors, including PPC970, which don't support
      the Virtual Real Mode Area (VRMA) facility, but only the Real Mode
      Offset (RMO) facility.  These processors require a physically
      contiguous, aligned area of memory for each guest.  When the guest does
      an access in real mode (MMU off), the address is compared against a
      limit value, and if it is lower, the address is ORed with an offset
      value (from the Real Mode Offset Register (RMOR)) and the result becomes
      the real address for the access.  The size of the RMA has to be one of
      a set of supported values, which usually includes 64MB, 128MB, 256MB
      and some larger powers of 2.
      
      Since we are unlikely to be able to allocate 64MB or more of physically
      contiguous memory after the kernel has been running for a while, we
      allocate a pool of RMAs at boot time using the bootmem allocator.  The
      size and number of the RMAs can be set using the kvm_rma_size=xx and
      kvm_rma_count=xx kernel command line options.
      
      KVM exports a new capability, KVM_CAP_PPC_RMA, to signal the availability
      of the pool of preallocated RMAs.  The capability value is 1 if the
      processor can use an RMA but doesn't require one (because it supports
      the VRMA facility), or 2 if the processor requires an RMA for each guest.
      
      This adds a new ioctl, KVM_ALLOCATE_RMA, which allocates an RMA from the
      pool and returns a file descriptor which can be used to map the RMA.  It
      also returns the size of the RMA in the argument structure.
      
      Having an RMA means we will get multiple KMV_SET_USER_MEMORY_REGION
      ioctl calls from userspace.  To cope with this, we now preallocate the
      kvm->arch.ram_pginfo array when the VM is created with a size sufficient
      for up to 64GB of guest memory.  Subsequently we will get rid of this
      array and use memory associated with each memslot instead.
      
      This moves most of the code that translates the user addresses into
      host pfns (page frame numbers) out of kvmppc_prepare_vrma up one level
      to kvmppc_core_prepare_memory_region.  Also, instead of having to look
      up the VMA for each page in order to check the page size, we now check
      that the pages we get are compound pages of 16MB.  However, if we are
      adding memory that is mapped to an RMA, we don't bother with calling
      get_user_pages_fast and instead just offset from the base pfn for the
      RMA.
      
      Typically the RMA gets added after vcpus are created, which makes it
      inconvenient to have the LPCR (logical partition control register) value
      in the vcpu->arch struct, since the LPCR controls whether the processor
      uses RMA or VRMA for the guest.  This moves the LPCR value into the
      kvm->arch struct and arranges for the MER (mediated external request)
      bit, which is the only bit that varies between vcpus, to be set in
      assembly code when going into the guest if there is a pending external
      interrupt request.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      aa04b4cc
  15. 17 6月, 2011 1 次提交
  16. 19 5月, 2011 1 次提交
  17. 06 5月, 2011 1 次提交
  18. 27 4月, 2011 1 次提交
  19. 20 4月, 2011 1 次提交
  20. 09 12月, 2010 1 次提交
  21. 18 11月, 2010 1 次提交
  22. 24 8月, 2010 1 次提交
  23. 05 8月, 2010 1 次提交
    • B
      memblock: Remove rmo_size, burry it in arch/powerpc where it belongs · cd3db0c4
      Benjamin Herrenschmidt 提交于
      The RMA (RMO is a misnomer) is a concept specific to ppc64 (in fact
      server ppc64 though I hijack it on embedded ppc64 for similar purposes)
      and represents the area of memory that can be accessed in real mode
      (aka with MMU off), or on embedded, from the exception vectors (which
      is bolted in the TLB) which pretty much boils down to the same thing.
      
      We take that out of the generic MEMBLOCK data structure and move it into
      arch/powerpc where it belongs, renaming it to "RMA" while at it.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      cd3db0c4
  24. 31 7月, 2010 1 次提交
  25. 14 7月, 2010 1 次提交
  26. 09 7月, 2010 1 次提交
    • A
      powerpc: Optimise per cpu accesses on 64bit · ae01f84b
      Anton Blanchard 提交于
      Now we dynamically allocate the paca array, it takes an extra load
      whenever we want to access another cpu's paca. One place we do that a lot
      is per cpu variables. A simple example:
      
      DEFINE_PER_CPU(unsigned long, vara);
      unsigned long test4(int cpu)
      {
      	return per_cpu(vara, cpu);
      }
      
      This takes 4 loads, 5 if you include the actual load of the per cpu variable:
      
          ld r11,-32760(r30)  # load address of paca pointer
          ld r9,-32768(r30)   # load link address of percpu variable
          sldi r3,r29,9       # get offset into paca (each entry is 512 bytes)
          ld r0,0(r11)        # load paca pointer
          add r3,r0,r3        # paca + offset
          ld r11,64(r3)       # load paca[cpu].data_offset
      
          ldx r3,r9,r11       # load per cpu variable
      
      If we remove the ppc64 specific per_cpu_offset(), we get the generic one
      which indexes into a statically allocated array. This removes one load and
      one add:
      
          ld r11,-32760(r30)  # load address of __per_cpu_offset
          ld r9,-32768(r30)   # load link address of percpu variable
          sldi r3,r29,3       # get offset into __per_cpu_offset (each entry 8 bytes)
          ldx r11,r11,r3      # load __per_cpu_offset[cpu]
      
          ldx r3,r9,r11       # load per cpu variable
      
      Having all the offsets in one array also helps when iterating over a per cpu
      variable across a number of cpus, such as in the scheduler. Before we would
      need to load one paca cacheline when calculating each per cpu offset. Now we
      have 16 (128 / sizeof(long)) per cpu offsets in each cacheline.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ae01f84b
  27. 15 6月, 2010 1 次提交
  28. 21 5月, 2010 2 次提交
  29. 19 3月, 2010 1 次提交
  30. 09 3月, 2010 1 次提交
    • M
      powerpc: Dynamically allocate pacas · 1426d5a3
      Michael Ellerman 提交于
      On 64-bit kernels we currently have a 512 byte struct paca_struct for
      each cpu (usually just called "the paca"). Currently they are statically
      allocated, which means a kernel built for a large number of cpus will
      waste a lot of space if it's booted on a machine with few cpus.
      
      We can avoid that by only allocating the number of pacas we need at
      boot. However this is complicated by the fact that we need to access
      the paca before we know how many cpus there are in the system.
      
      The solution is to dynamically allocate enough space for NR_CPUS pacas,
      but then later in boot when we know how many cpus we have, we free any
      unused pacas.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1426d5a3
  31. 10 11月, 2009 1 次提交
    • F
      swiotlb: Defer swiotlb init printing, export swiotlb_print_info() · ad32e8cb
      FUJITA Tomonori 提交于
      This enables us to avoid printing swiotlb memory info when we
      initialize swiotlb. After swiotlb initialization, we could find
      that we don't need swiotlb.
      
      This patch removes the code to print swiotlb memory info in
      swiotlb_init() and exports the function to do that.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: chrisw@sous-sol.org
      Cc: dwmw2@infradead.org
      Cc: joerg.roedel@amd.com
      Cc: muli@il.ibm.com
      Cc: tony.luck@intel.com
      Cc: benh@kernel.crashing.org
      LKML-Reference: <1257849980-22640-9-git-send-email-fujita.tomonori@lab.ntt.co.jp>
      [ -v2: merge up conflict ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ad32e8cb
  32. 30 10月, 2009 1 次提交
  33. 27 10月, 2009 1 次提交
    • K
      powerpc: Fix compile errors found by new ppc64e_defconfig · ce7a35c7
      Kumar Gala 提交于
      Fix the following 3 issues:
      
      arch/powerpc/kernel/process.c: In function 'arch_randomize_brk':
      arch/powerpc/kernel/process.c:1183: error: 'mmu_highuser_ssize' undeclared (first use in this function)
      arch/powerpc/kernel/process.c:1183: error: (Each undeclared identifier is reported only once
      arch/powerpc/kernel/process.c:1183: error: for each function it appears in.)
      arch/powerpc/kernel/process.c:1183: error: 'MMU_SEGSIZE_1T' undeclared (first use in this function)
      
      In file included from arch/powerpc/kernel/setup_64.c:60:
      arch/powerpc/include/asm/mmu-hash64.h:132: error: redefinition of 'struct mmu_psize_def'
      arch/powerpc/include/asm/mmu-hash64.h:159: error: expected identifier or '(' before numeric constant
      arch/powerpc/include/asm/mmu-hash64.h:396: error: conflicting types for 'mm_context_t'
      arch/powerpc/include/asm/mmu-book3e.h:184: error: previous declaration of 'mm_context_t' was here
      
      cc1: warnings being treated as errors
      arch/powerpc/kernel/pci_64.c: In function 'pcibios_unmap_io_space':
      arch/powerpc/kernel/pci_64.c:100: error: unused variable 'res'
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ce7a35c7
  34. 20 8月, 2009 2 次提交