1. 28 Jun, 2009 9 commits
  2. 27 Jun, 2009 1 commit
  3. 26 Jun, 2009 17 commits
  4. 25 Jun, 2009 13 commits
    • Benjamin Herrenschmidt's avatar
      powerpc/rtas: Turn rtas lock into a raw spinlock · f97bb36f
      Benjamin Herrenschmidt authored
      RTAS currently uses a normal spinlock. However it can be called from
      contexts where this is not necessarily a good idea. For example, it
      can be called while syncing timebases, with the core timebase being
      frozen. Unfortunately, that will deadlock in case of lock contention
      when spinlock debugging is enabled as the spin lock debugging code
      will try to use __delay() which ... relies on the timebase being
      Also RTAS can be used in some low level IRQ handling code path so it
      may as well be a raw spinlock for -rt sake.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Benjamin Herrenschmidt's avatar
      powerpc: Add irqtrace support for 32-bit powerpc · 5d38902c
      Benjamin Herrenschmidt authored
      Based on initial work from: Dale Farnsworth <dale@farnsworth.org>
      Add the low level irq tracing hooks for 32-bit powerpc needed
      to enable full lockdep functionality.
      The approach taken to deal with the code in entry_32.S is that
      we don't trace all the transitions of MSR:EE when we just turn
      it off to peek at TI_FLAGS without races. Only when we are
      calling into C code or returning from exceptions with a state
      that have changed from what lockdep thinks.
      There's a little bugger though: If we take an exception that
      keeps interrupts enabled (such as an alignment exception) while
      interrupts are enabled, we will call trace_hardirqs_on() on the
      way back spurriously. Not a big deal, but to get rid of it would
      require remembering in pt_regs that the exception was one of the
      type that kept interrupts enabled which we don't know at this
      stage. (Well, we could test all cases for regs->trap but that
      sucks too much).
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Tested-by: default avatarKumar Gala <galak@kernel.crashing.org>
    • Sonny Rao's avatar
      powerpc/BSR: Fix BSR to allow mmap of small BSR on 64k kernel · 04a85d12
      Sonny Rao authored
      On Mon, Nov 17, 2008 at 01:26:13AM -0600, Sonny Rao wrote:
      > On Fri, Nov 07, 2008 at 04:28:29PM +1100, Paul Mackerras wrote:
      > > Sonny Rao writes:
      > >
      > > > Fix the BSR driver to allow small BSR devices, which are limited to a
      > > > single 4k space, on a 64k page kernel.  Previously the driver would
      > > > reject the mmap since the size was smaller than PAGESIZE (or because
      > > > the size was greater than the size of the device).  Now, we check for
      > > > this case use remap_4k_pfn(). Also, take out code to set vm_flags,
      > > > as the remap_pfn functions will do this for us.
      > >
      > > Thanks.
      > >
      > > Do we know that the BSR size will always be 4k if it's not a multiple
      > > of 64k?  Is it possible that we could get 8k, 16k or 32k or BSRs?
      > > If it is possible, what does the user need to be able to do?  Do they
      > > just want to map 4k, or might then want to map the whole thing?
      > Hi Paul, I took a look at changing the driver to reject a request for
      > mapping more than a single 4k page, however the only indication we get
      > of the requested size in the mmap function is the vma size, and this
      > is always one page at minimum.  So, it's not possible to determine if
      > the user wants one 4k page or more.  As I noted in my first response,
      > there is only one case where this is even possible and I don't think
      > it is a significant concern.
      > I did notice that I left out the check to see if the user is trying to
      > map more than the device length, so I fixed that.  Here's the revised
      > patch.
      Alright, I've reworked this now so that if we get one of these cases
      where there's a bsr that's > 4k and < 64k on a 64k kernel we'll only
      advertise that it is a 4k BSR to userspace.  I think this is the best
      solution since user programs are only supposed to look at sysfs to
      determine how much can be mapped, and libbsr does this as well.
      Please consider for 2.6.31 as a fix, thanks.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Sonny Rao's avatar
      powerpc/BSR: add 4096 byte BSR size · e4031d52
      Sonny Rao authored
      Add a 4096 byte BSR size which will be used on new machines.  Also, remove
      the warning when we run into an unknown size, as this can spam the kernel
      log excessively.
      Signed-off-by: default avatarSonny Rao <sonnyrao@us.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Benjamin Herrenschmidt's avatar
      powerpc: Map more memory early on 601 processors · 4a5cbf17
      Benjamin Herrenschmidt authored
      The 32-bit kernel relies on some memory being mapped covering
      the kernel text,data and bss at least, early during boot before
      the full MMU setup is done. On 32-bit "classic" processors, this
      is done using BAT registers.
      On 601, the size of BATs is limited to 8M and we use 2 of them
      for that initial mapping. This can become quite tight when enabling
      features like lockdep, so let's use a 3rd one to bump that mapping
      from 16M to 24M. We keep the 4th BAT free as it can be useful for
      debugging early boot code to map things like serial ports.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Benjamin Herrenschmidt's avatar
      powerpc/pmac: Fix DMA ops for MacIO devices · 3514141a
      Benjamin Herrenschmidt authored
      The macio_dev's created to map devices inside the MacIO ASICs
      don't have proper dma_ops. This causes crashes on some machines
      since the SCSI code calls dma_map_* on our behalf using the
      device we hang from.
      This fixes it by copying the parent PCI device dma_ops into
      the macio_dev when creating it.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Benjamin Herrenschmidt's avatar
      powerpc/mm: Make k(un)map_atomic out of line · 850f6ac3
      Benjamin Herrenschmidt authored
      Those functions are way too big to be inline, besides, kmap_atomic()
      wants to call debug_kmap_atomic() which isn't exported for modules
      and causes module link failures.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Kumar Gala's avatar
      powerpc: Fix mpic alloc warning · 85355bb2
      Kumar Gala authored
      Since we can use kmalloc earlier we are getting the following since the
      mpic_alloc() code calls alloc_bootmem().  Move to using kzalloc() to
      remove the warning.
      ------------[ cut here ]------------
      Badness at c0583248 [verbose debug info unavailable]
      NIP: c0583248 LR: c0583210 CTR: 00000004
      REGS: c0741de0 TRAP: 0700   Not tainted  (2.6.30-06736-g12a31df)
      MSR: 00021000 <ME,CE>  CR: 22024024  XER: 00000000
      TASK = c070d3b8[0] 'swapper' THREAD: c0740000 CPU: 0
      <6>GPR00: 00000001 c0741e90 c070d3b8 00000001 00000210 00000020 3fffffff 00000000
      <6>GPR08: 00000000 c0c85700 c04f8c40 0000002d 22044022 1004a388 7ffd9400 00000000
      <6>GPR16: 00000000 7ffcd100 7ffcd100 7ffcd100 c04f8c40 00000000 c059f62c c075a0c0
      <6>GPR24: c059f648 00000000 0000000f 00000210 00000020 00000000 3fffffff 00000210
      NIP [c0583248] alloc_arch_preferred_bootmem+0x50/0x80
      LR [c0583210] alloc_arch_preferred_bootmem+0x18/0x80
      Call Trace:
      [c0741e90] [c07343b0] devtree_lock+0x0/0x24 (unreliable)
      [c0741ea0] [c0583b14] ___alloc_bootmem_nopanic+0x54/0x108
      [c0741ee0] [c0583e18] ___alloc_bootmem+0x18/0x50
      [c0741ef0] [c057b9cc] mpic_alloc+0x48/0x710
      [c0741f40] [c057ecf4] mpc85xx_ds_pic_init+0x190/0x1b8
      [c0741f90] [c057633c] init_IRQ+0x24/0x34
      [c0741fa0] [c05738b8] start_kernel+0x260/0x3dc
      [c0741ff0] [c00003c8] skpinv+0x2e0/0x31c
      Instruction dump:
      409e001c 7c030378 80010014 83e1000c 38210010 7c0803a6 4e800020 3d20c0c8
      39295700 80090004 7c000034 5400d97e <0f000000> 2f800000 409e001c 38800000
      BenH: Changed to use GFP_KERNEL, the allocator will do the right thing
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Kumar Gala's avatar
      powerpc: Fix output from show_regs · a2367194
      Kumar Gala authored
      For some reason we've had an explicit KERN_INFO for GPR dumps.  With
      recent changes we get output like:
      <6>GPR00: 00000000 ef855eb0 ef858000 00000001 000000d0 f1000000 ffbc8000 ffffffff
      The KERN_INFO is causing the <6>.  Don't see any reason to keep it
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Benjamin Herrenschmidt's avatar
      powerpc/pmac: Fix issues with PowerMac "PowerSurge" SMP · 7ccbe504
      Benjamin Herrenschmidt authored
      The old PowerSurge SMP (ie, dual or quad 604 machines) code has
      numerous issues in modern world.
      One is cpu_possible_map is set too late (the device-tree is bogus)
      so we fail to allocate the interrupt stacks and crash. Another
      problem is the fact the timebase is frozen by the bringup of the
      second CPU so the delays in the generic code will hang, we need
      to move some of the calling procedure to inside the powermac code.
      This makes it boot again for me
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Gerhard Pircher's avatar
      powerpc/amigaone: Limit ISA I/O range to 4k in the device tree · 6bb2ae53
      Gerhard Pircher authored
      The kernel reserves the I/O address space from 0x0 to 0xfff for legacy
      ISA devices. Change the ranges property for the PCI2ISA bridge to match
      the kernels behavior, even if the ranges property isn't used for now.
      Signed-off-by: default avatarGerhard Pircher <gerhard_pircher@gmx.net>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Sean MacLennan's avatar
      powerpc/warp: Platform fix for i2c change · 3984114f
      Sean MacLennan authored
      A change to the i2c subsystem breaks the warp platform code. The patch
      is cleaner anyway, the old way was a bit crufty.
      For those with keen eyes, the gratuitous change in the string from
      PIKA to Warp is just so the logs look a bit nicer. The following two
      lines tend to be printed one after another.
        Warp POST OK
        Warp DTM thread running.
      Yeah, this will be the third patch to warp.c submitted in this
      The i2c_client struct changed, breaking the code that looked for the ad7414
      chip. Use the new of_find_i2c_device_by_node function added in 2.6.29.
      Signed-off-by: default avatarSean MacLennan <smaclennan@pikatech.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Jon Smirl's avatar
      powerpc: Have git ignore generated files from dtc compile · b810c6ec
      Jon Smirl authored
      Have git ignore generated files from dtc compile
      Signed-off-by: default avatarJon Smirl <jonsmirl@gmail.com>
      Acked-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Acked-by: default avatarSean MacLennan <smaclennan@pikatech.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>