1. 09 1月, 2006 3 次提交
    • B
      [PATCH] powerpc: Remove device_node addrs/n_addr · cc5d0189
      Benjamin Herrenschmidt 提交于
      The pre-parsed addrs/n_addrs fields in struct device_node are finally
      gone. Remove the dodgy heuristics that did that parsing at boot and
      remove the fields themselves since we now have a good replacement with
      the new OF parsing code. This patch also fixes a bunch of drivers to use
      the new code instead, so that at least pmac32, pseries, iseries and g5
      defconfigs build.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cc5d0189
    • B
      [PATCH] powerpc: udbg updates · bb6b9b28
      Benjamin Herrenschmidt 提交于
      The udbg low level io layer has an issue with udbg_getc() returning a
      char (unsigned on ppc) instead of an int, thus the -1 if you had no
      available input device could end up turned into 0xff, filling your
      display with bogus characters. This fixes it, along with adding a little
      blob to xmon to do a delay before exiting when getting an EOF and fixing
      the detection of ADB keyboards in udbg_adb.c
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      bb6b9b28
    • B
      [PATCH] powerpc: Unify udbg (#2) · 51d3082f
      Benjamin Herrenschmidt 提交于
      This patch unifies udbg for both ppc32 and ppc64 when building the
      merged achitecture. xmon now has a single "back end". The powermac udbg
      stuff gets enriched with some ADB capabilities and btext output. In
      addition, the early_init callback is now called on ppc32 as well,
      approx. in the same order as ppc64 regarding device-tree manipulations.
      The init sequences of ppc32 and ppc64 are getting closer, I'll unify
      them in a later patch.
      
      For now, you can force udbg to the scc using "sccdbg" or to btext using
      "btextdbg" on powermacs. I'll implement a cleaner way of forcing udbg
      output to something else than the autodetected OF output device in a
      later patch.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      51d3082f
  2. 08 11月, 2005 2 次提交
  3. 02 11月, 2005 1 次提交
  4. 20 10月, 2005 1 次提交
    • P
      powerpc: Merge time.c and asm/time.h. · f2783c15
      Paul Mackerras 提交于
      We now use the merged time.c for both 32-bit and 64-bit compilation
      with ARCH=powerpc, and for ARCH=ppc64, but not for ARCH=ppc32.
      This removes setup_default_decr (folds its function into time_init)
      and moves wakeup_decrementer into time.c.  This also makes an
      asm-powerpc/rtc.h.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f2783c15
  5. 26 9月, 2005 1 次提交
    • P
      powerpc: Merge enough to start building in arch/powerpc. · 14cf11af
      Paul Mackerras 提交于
      This creates the directory structure under arch/powerpc and a bunch
      of Kconfig files.  It does a first-cut merge of arch/powerpc/mm,
      arch/powerpc/lib and arch/powerpc/platforms/powermac.  This is enough
      to build a 32-bit powermac kernel with ARCH=powerpc.
      
      For now we are getting some unmerged files from arch/ppc/kernel and
      arch/ppc/syslib, or arch/ppc64/kernel.  This makes some minor changes
      to files in those directories and files outside arch/powerpc.
      
      The boot directory is still not merged.  That's going to be interesting.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      14cf11af
  6. 19 9月, 2005 1 次提交
  7. 05 9月, 2005 1 次提交
  8. 28 6月, 2005 2 次提交
  9. 10 6月, 2005 1 次提交
    • B
      [PATCH] ppc32: Fix nasty sleep/wakeup problem · 0086b5ec
      Benjamin Herrenschmidt 提交于
      Despite all the care lately in making the powermac sleep/wakeup as
      robust as possible, there is still a nasty related to the use of cpufreq
      on PMU based machines.  Unfortunately, it affects paulus old powerbook
      so I have to fix it :)
      
      We didn't manage to understand what is precisely going on, it leads to
      memory corruption and might have to do with RAM not beeing properly
      refreshed when a cpufreq transition is done right before the sleep.
      
      The best workaround (and less intrusive at this point) we could come up
      with is included in this patch.  We basically do _not_ force a switch to
      high speed on suspend anymore (that is what is causing the problem) on
      those machines.  We still force a speed switch on wakeup (since we don't
      know what speed we are coming back from sleep at, and that seems to work
      fine).
      
      Since, during this short interval, the actual CPU speed might be
      incorrect, we also hack around by multiplying loops_per_jiffy by 2 (max
      speed factor on those machines) during early wakeup stage to make sure
      udelay's during that time aren't too short.
      
      For after 2.6.12, we'll change udelay implementation to use the CPU
      timebase (which is always constant) instead like we do on ppc64 and thus
      get rid of all those problems.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0086b5ec
  10. 29 5月, 2005 1 次提交
    • B
      [PATCH] ppc32: Fix cpufreq vs. sleep issue · b16eeb47
      Benjamin Herrenschmidt 提交于
      Recent kernels occasionally trigger a PMU timeout on some mac laptops,
      typically on wakeup from sleep.  This seem to be caused by either a too big
      latency caused by the cpufreq switch on wakeup from sleep or by an
      interrupt beeing lost due to the reset of the interrupt controller done
      during wakeup.
      
      This patch makes that code more robust by stopping PMU auto poll activity
      around cpufreq changes on machines that use the PMU for such changes (long
      latency switching involving a CPU hard reset and flush of all caches) and
      by removing the reset of the open pic interrupt controller on wakeup (that
      can cause the loss of an interrupt and Darwin doesn't do it, so it must not
      be necessary).
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b16eeb47
  11. 02 5月, 2005 1 次提交
  12. 17 4月, 2005 3 次提交