1. 11 6月, 2005 1 次提交
  2. 10 6月, 2005 2 次提交
    • 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
    • E
      [PATCH] ppc32: add 405EP cpu_spec entry · 7fbdf1a2
      Eugene Surovegin 提交于
      Add a definition for PPC 405EP which was lost somehow during 2.4 -> 2.6
      transition.
      
      Recent change to arch/ppc/kernel/misc.S ("Fix incorrect CPU_FTR fixup usage
      for unified caches") triggered this bug and 405EP boards don't boot
      anymore.
      Signed-off-by: NEugene Surovegin <ebs@ebshome.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7fbdf1a2
  3. 09 6月, 2005 1 次提交
  4. 08 6月, 2005 1 次提交
  5. 07 6月, 2005 1 次提交
  6. 01 6月, 2005 1 次提交
  7. 29 5月, 2005 11 次提交
  8. 24 5月, 2005 1 次提交
  9. 21 5月, 2005 2 次提交
  10. 20 5月, 2005 4 次提交
  11. 18 5月, 2005 1 次提交
  12. 08 5月, 2005 1 次提交
  13. 07 5月, 2005 1 次提交
  14. 06 5月, 2005 3 次提交
  15. 04 5月, 2005 1 次提交
    • A
      [PATCH] ISA DMA Kconfig fixes - part 1 · 5cae841b
      Al Viro 提交于
      A bunch of drivers use ISA DMA helpers or their equivalents for
      platforms that have ISA with different DMA controller (a lot of ARM
      boxen).  Currently there is no way to put such dependency in Kconfig -
      CONFIG_ISA is not it (e.g.  it is not set on platforms that have no ISA
      slots, but have on-board devices that pretend to be ISA ones).
      
      New symbol added - ISA_DMA_API.  Set when we have functional
      enable_dma()/set_dma_mode()/etc.  set of helpers.  Next patches in the
      series will add missing dependencies for drivers that need them.
      
      I'm very carefully staying the hell out of the recurring flamefest on
      what exactly CONFIG_ISA would mean in ideal world - added symbol has a
      well-defined meaning and for now I really want to treat it as completely
      independent from the mess around CONFIG_ISA.
      Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5cae841b
  16. 02 5月, 2005 3 次提交
  17. 01 5月, 2005 5 次提交