1. 10 Feb, 2006 1 commit
  2. 08 Nov, 2005 2 commits
  3. 19 Oct, 2005 1 commit
    • Paul Mackerras's avatar
      powerpc: Merge time.c and asm/time.h. · f2783c15
      Paul Mackerras authored
      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
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
  4. 12 Oct, 2005 1 commit
  5. 10 Oct, 2005 1 commit
  6. 26 Sep, 2005 1 commit
    • Paul Mackerras's avatar
      powerpc: Merge enough to start building in arch/powerpc. · 14cf11af
      Paul Mackerras authored
      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: default avatarPaul Mackerras <paulus@samba.org>
  7. 18 Sep, 2005 1 commit
  8. 08 Jul, 2005 1 commit
  9. 10 Jun, 2005 1 commit
    • Benjamin Herrenschmidt's avatar
      [PATCH] ppc32: Fix nasty sleep/wakeup problem · 0086b5ec
      Benjamin Herrenschmidt authored
      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
      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: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  10. 28 May, 2005 2 commits
  11. 16 Apr, 2005 2 commits
    • Benjamin Herrenschmidt's avatar
      [PATCH] ppc32: Fix cpufreq problems · 7a648b9e
      Benjamin Herrenschmidt authored
      This patch updates the PowerMac cpufreq driver.  It depends on the addition
      of the suspend() method (my previous patch) and on the new flag I defined
      to silence some warnings that are normal for us.
      It fixes various issues related to cpufreq on pmac, including some crashes
      on some models when sleeping the machine while in low speed, proper voltage
      control on some newer machines, and adds voltage control on 750FX based G3
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!