1. 08 Dec, 2011 7 commits
    • Finn Thain's avatar
      pmac_zilog: Fix unexpected irq · 7cf82b1b
      Finn Thain authored
      On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
      masked. This can be a problem when pmac_zilog starts up.
      
      For example, the serial debugging code in arch/m68k/kernel/head.S may be
      used beforehand. It disables the SCC interrupts at the chip but doesn't
      ack them. Then when a pmac_zilog port is used, the machine locks up with
      "unexpected interrupt".
      
      This can happen in pmz_shutdown() since the irq is freed before the
      channel interrupts are disabled.
      
      Fix this by clearing interrupt enable bits before the handler is
      uninstalled. Also move the interrupt control bit flipping into a separate
      pmz_interrupt_control() routine. Replace all instances of these operations
      with calls to this routine. Omit the zssync() calls that seem to serve no
      purpose.
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7cf82b1b
    • Paul Mackerras's avatar
      powerpc: Provide a way for KVM to indicate that NV GPR values are lost · 2fde6d20
      Paul Mackerras authored
      This fixes a problem where a CPU thread coming out of nap mode can
      think it has valid values in the nonvolatile GPRs (r14 - r31) as saved
      away in power7_idle, but in fact the values have been trashed because
      the thread was used for KVM in the mean time.  The result is that the
      thread crashes because code that called power7_idle (e.g.,
      pnv_smp_cpu_kill_self()) goes to use values in registers that have
      been trashed.
      
      The bit field in SRR1 that tells whether state was lost only reflects
      the most recent nap, which may not have been the nap instruction in
      power7_idle.  So we need an extra PACA field to indicate that state
      has been lost even if SRR1 indicates that the most recent nap didn't
      lose state.  We clear this field when saving the state in power7_idle,
      we set it to a non-zero value when we use the thread for KVM, and we
      test it in power7_wakeup_noloss.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2fde6d20
    • Paul Mackerras's avatar
      powerpc/powernv: Fix problems in onlining CPUs · cba313da
      Paul Mackerras authored
      At present, on the powernv platform, if you off-line a CPU that was
      online, and then try to on-line it again, the kernel generates a
      warning message "OPAL Error -1 starting CPU n".  Furthermore, if the
      CPU is a secondary thread that was used by KVM while it was off-line,
      the CPU fails to come online.
      
      The first problem is fixed by only calling OPAL to start the CPU the
      first time it is on-lined, as indicated by the cpu_start field of its
      PACA being zero.  The second problem is fixed by restoring the
      cpu_start field to 1 instead of 0 when using the CPU within KVM.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      cba313da
    • Anton Blanchard's avatar
      powerpc/pseries: Increase minimum RMO size from 64MB to 256MB · 33392640
      Anton Blanchard authored
      The minimum RMO size field in ibm,client-architecture is currently
      ignored, but a future firmware version will rectify that. Since we
      always get at least 128MB of RMO right now, asking for 64MB is
      likely to result in boot failures.
      
      We should bump it to at least 128MB, but considering all the boot
      issues we have on 128MB RMO boxes and all new machines have virtual
      RMO, we may as well set our minimum to 256MB.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      33392640
    • sukadev@linux.vnet.ibm.com's avatar
      powerpc: Punch a hole in /dev/mem for librtas · 8a3e3d31
      sukadev@linux.vnet.ibm.com authored
      With CONFIG_STRICT_DEVMEM=y, user space cannot read any part of /dev/mem.
      Since this breaks librtas, punch a hole in /dev/mem to allow access to the
      rmo_buffer that librtas needs.
      
      Anton Blanchard reported the problem and helped with the fix.
      
      A quick test for this patch:
      
             # cat /proc/rtas/rmo_buffer
             000000000f190000 10000
      
             # python -c "print 0x000000000f190000 / 0x10000"
             3865
      
             # dd if=/dev/mem of=/tmp/foo count=1 bs=64k skip=3865
             1+0 records in
             1+0 records out
             65536 bytes (66 kB) copied, 0.000205235 s, 319 MB/s
      
             # dd if=/dev/mem of=/tmp/foo
             dd: reading `/dev/mem': Operation not permitted
             0+0 records in
             0+0 records out
             0 bytes (0 B) copied, 0.00022519 s, 0.0 kB/s
      Signed-off-by: default avatarSukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8a3e3d31
    • Benjamin Herrenschmidt's avatar
      powerpc: Add support for OpenBlockS 600 · 11eab297
      Benjamin Herrenschmidt authored
      So I've had one of these for a while and it looks like the vendor never
      bothered submitting the support upstream.
      
      This adds it using ppc40x_simple and provides a device-tree.
      
      There are some changes to the boot wrapper because the way u-boot works
      on this thing, it seems to expect a multipart image with the kernel,
      initrd and dtb in it.
      
      The USB support is missing as it needs the yet unmerged driver for
      the DWC OTG part and the GPIOs may need further definition in the dts.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      11eab297
    • Benjamin Herrenschmidt's avatar
      faa8bf88
  2. 07 Dec, 2011 28 commits
  3. 28 Nov, 2011 5 commits