1. 02 Aug, 2006 33 commits
  2. 31 Jul, 2006 7 commits
    • Linus Torvalds's avatar
      Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc · 49b1e3ea
      Linus Torvalds authored
      * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
        [POWERPC] Minor comment fix for misc_64.S
        [POWERPC] Use H_CEDE on non-SMT
        [POWERPC] force 64bit mode in fwnmi handlers to workaround firmware bugs
        [POWERPC] PMAC_APM_EMU should depend on ADB_PMU
        [POWERPC] Fix new interrupt code (MPIC detection)
        [POWERPC] Fix new interrupt code (MPIC endianness)
        [POWERPC] Add cpufreq support for Xserve G5
        [POWERPC] Xserve G5 thermal control fixes
        [POWERPC] Fix mem= handling when the memory limit is > RMO size
        [POWERPC] More offb/bootx fixes
        [POWERPC] Fix legacy_serial.c error handling on 32 bits
        [POWERPC] Fix default clock for udbg_16550
        [POWERPC] Fix non-MPIC CHRPs with CONFIG_SMP set
        [POWERPC] Fix 32 bits warning in prom_init.c
        [POWERPC] Workaround Pegasos incorrect ISA "ranges"
        [POWERPC] fix up front-LED Kconfig
      49b1e3ea
    • Guido Guenther's avatar
      [PATCH] rivafb/nvidiafb: race between register_framebuffer and *_bl_init · ce38cac4
      Guido Guenther authored
      Since we now use the generic backlight infrastructure, I think we need to
      call rivafb_bl_init before calling register_framebuffer since otherwise
      rivafb_bl_init might race with the framebuffer layer already opening the
      device and setting up the video mode.  In this case we might end up with a
      not yet fully intialized backlight (info->bl_dev still NULL) when calling
      riva_bl_set_power via rivafb_set_par/rivafb_load_video_mode and the kernel
      dies without any further notice during boot.
      
      This fixes booting current git on a PB 6,1.  In this case radeonfb/atyfb
      would be affected too - I can fix that too but don't have any hardware to
      test this on.
      
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ce38cac4
    • Arthur Othieno's avatar
      [PATCH] nvidiafb: remove redundant CONFIG_PCI check · b1367d2a
      Arthur Othieno authored
      CONFIG_FB_NVIDIA already depends on CONFIG_PCI in drivers/video/Kconfig.
      Driver does an extra ``sanity check'' which is then redundant.
      Signed-off-by: default avatarArthur Othieno <apgo@patchbomb.org>
      Cc: Antonino Daplas <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b1367d2a
    • Michael Hanselmann's avatar
      [PATCH] powermac: More powermac backlight fixes · 4b755999
      Michael Hanselmann authored
      This patch fixes several problems:
      - The legacy backlight value might be set at interrupt time. Introduced
        a worker to prevent it from directly calling the backlight code.
      - via-pmu allows the backlight to be grabbed, in which case we need to
        prevent other kernel code from changing the brightness.
      - Don't send PMU requests in via-pmu-backlight when the machine is about
        to sleep or waking up.
      - More Kconfig fixes.
      Signed-off-by: default avatarMichael Hanselmann <linux-kernel@hansmi.ch>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4b755999
    • Volker Braun's avatar
      [PATCH] radeonfb sleep fixes · 994aad25
      Volker Braun authored
      Many IBM Thinkpad T4* models and some R* and X* with radeon video cards draw
      too much power when suspended to RAM, reducing drastically the battery
      lifetime.  The solution is to enable suspend-to-D2 on these machines.  They
      are whitelisted through their subsystem vendor/device ID.  This fixes
      http://bugzilla.kernel.org/show_bug.cgi?id=3022
      
      The patch introduces a framework to alter the pm_mode and reinit_func fields
      of the radeonfb_info structure based on a whitelist.  This should facilitate
      future hardware-dependent workarounds.  The workaround for the Samsung P35
      that is already in the radeonfb code has been rewritten using this framework.
      
      The behavior can be overridden with module options:
      
      i)  video=radeonfb:force_sleep=1
          enable suspend-to-D2 also on non-whitelisted machines (useful for
          testing new notebook models),
      
      ii) video=radeonfb:ignore_devlist=1
          Disable checking the whitelist and do not apply any workarounds.
      
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      994aad25
    • Antonino A. Daplas's avatar
      [PATCH] fbdev: statically link the framebuffer notification functions · 256154fb
      Antonino A. Daplas authored
      The backlight and lcd subsystems can be notified by the framebuffer layer
      of blanking events.  However, these subsystems, as a whole, can function
      independently from the framebuffer layer.  But in order to enable to the
      lcd and backlight subsystems, the framebuffer has to be compiled also,
      effectively sucking in a huge amount of unneeded code.
      
      To prevent dependency problems, separate out the framebuffer notification
      mechanism from the framebuffer layer and permanently link it to the kernel.
      Signed-off-by: default avatarAntonino Daplas <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      256154fb
    • Eric Van Hensbergen's avatar
      [PATCH] 9p: fix fid behavior on failed remove · 834a9b8c
      Eric Van Hensbergen authored
      Based on a bug report from Russ Ross <russruss@gmail.com>
      
      According to the spec:
      
      "The remove request asks the file server both to remove the file
       represented by fid and to clunk the fid, even if the remove fails."
      
      but the Linux client seems to expect the fid to be valid after a failed
      remove attempt.  Specifically, I'm getting this behavior when attempting to
      remove a non-empty directory.
      Signed-off-by: default avatarEric Van Hensbergen <ericvh@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      834a9b8c