1. 17 10月, 2007 3 次提交
  2. 09 5月, 2007 1 次提交
  3. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  4. 13 2月, 2007 3 次提交
  5. 09 12月, 2006 1 次提交
  6. 11 7月, 2006 1 次提交
  7. 27 6月, 2006 3 次提交
  8. 28 3月, 2006 2 次提交
    • T
      [PATCH] drivers/video: Use ARRAY_SIZE macro · d1ae418e
      Tobias Klauser 提交于
      Use ARRAY_SIZE macro instead of sizeof(x)/sizeof(x[0]) and remove
      duplicates of ARRAY_SIZE.  Some coding style and trailing whitespaces are
      also fixed.
      
      Compile-tested where possible (some are other arch or BROKEN)
      Signed-off-by: NTobias Klauser <tklauser@nuerscht.ch>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d1ae418e
    • O
      [PATCH] fbdev: add modeline for 1680x1050@60 · b0c87978
      Olaf Hering 提交于
      Add a modeline for the Philips 200W display.  aty128fb does not do DDC, it
      picks 1920x1440 or similar.  It works ok with nvidiafb because it can ask
      for DDC data.
      
      mode "1680x1050-60"
          # D: 146.028 MHz, H: 65.191 kHz, V: 59.863 Hz
          geometry 1680 1050 1680 1050 16
          timings 6848 280 104 30 3 176 6
          hsync high
          vsync high
          rgba 5/11,6/5,5/0,0/0
      endmode
      
       hwinfo --monitor
      20: None 00.0: 10000 Monitor
        [Created at monitor.206]
        Unique ID: rdCR.pzUFTofo1S4
        Parent ID: 002j.bJRsY88eNSC
        Hardware Class: monitor
        Model: "PHILIPS Philips 200W"
        Vendor: PHL "PHILIPS"
        Device: eisa 0x0832 "Philips 200W"
        Serial ID: "VN  016596"
        Resolution: 720x400@70Hz
        Resolution: 640x480@60Hz
        Resolution: 640x480@67Hz
        Resolution: 640x480@72Hz
        Resolution: 640x480@75Hz
        Resolution: 800x600@56Hz
        Resolution: 800x600@60Hz
        Resolution: 800x600@72Hz
        Resolution: 800x600@75Hz
        Resolution: 832x624@75Hz
        Resolution: 1024x768@60Hz
        Resolution: 1024x768@70Hz
        Resolution: 1024x768@75Hz
        Resolution: 1280x1024@75Hz
        Resolution: 1152x864@70Hz
        Resolution: 1152x864@75Hz
        Resolution: 1280x960@60Hz
        Resolution: 1280x1024@60Hz
        Resolution: 1680x1050@60Hz
        Size: 433x271 mm
        Driver Info #0:
          Max. Resolution: 1680x1050
          Vert. Sync Range: 56-85 Hz
          Hor. Sync Range: 30-93 kHz
        Config Status: cfg=new, avail=yes, need=no, active=unknown
        Attached to: #5 (VGA compatible controller)
      Signed-off-by: NOlaf Hering <olh@suse.de>
      Acked-by: N"Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b0c87978
  9. 09 11月, 2005 1 次提交
  10. 07 11月, 2005 2 次提交
  11. 10 9月, 2005 1 次提交
    • A
      [PATCH] fbdev: Add VESA Coordinated Video Timings (CVT) support · 96fe6a21
      Antonino A. Daplas 提交于
      The Coordinated Video Timings (CVT) is the latest standard approved by VESA
      concerning video timings generation.  It addresses the limitation of GTF which
      is designed mainly for CRT displays.  CRT's have a high blanking requirement
      (as much as 25% of the horizontal frame length) which artificially increases
      the pixelclock.  Digital displays, on the other hand, needs to conserve the
      pixelclock as much as possible.  The GTF also does not take into account the
      different aspect ratios in its calculation.
      
      The new function added is fb_find_mode_cvt().  It is called by fb_find_mode()
      if it recognizes a mode option string formatted for CVT.  The format is:
      
      <xres>x<yres>[M][R][-<bpp>][<at-sign><refresh>][i][m]
      
      The 'M' tells the function to calculate using CVT.  On it's own, it will
      compute a timing for CRT displays at 60Hz.  If the 'R' is specified, 'reduced
      blanking' computation will be used, best for flatpanels.  The 'i' and the 'm'
      is for 'interlaced mode' and 'with margins' respectively.
      
      To determine if CVT was used, check for dmesg for something like this:
      
      CVT Mode - <pix>M<n>[-R], ie: .480M3-R  (800x600 reduced blanking)
      
      where: pix - product of xres and yres, in MB
          M   - is a CVT mode
          n   - the aspect ratio (3 - 4:3; 4 - 5:4; 9 - 16:9, 15:9; A - 16:10)
          -R   - reduced blanking
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      96fe6a21
  12. 09 8月, 2005 1 次提交
    • A
      [PATCH] nvidiafb: Fix initial display corruption on certain laptops · db6778db
      Antonino Daplas 提交于
      Reported by:Vincent Fortier (Bugzilla Bug 4768)
      
      "At boot time the screen appears moved to the mid right portion of the actual
      video pannel making the end of the line appears at the left edge...  It simply
      looks like moved half way to the right"
      
      His particular hardware has a display with an unusual dimension (1920x1200) but
      unfortunately has no EDID block. None of the entries in the global mode
      database is correct for this particular display, and it particularly has
      difficulty scaling up 640x480 (the default startup mode of nvidiafb) to
      1920x1200 which causes the above described problem.
      
      1, Add 1920x1200 to the global mode database.
      
      2. Let nvidiafb base the startup mode from the flatpanel dimensions only if the
        EDID block is absent, no boot mode parameter is specified by the user, and
        a flatpanel/LCD display is attached.
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      db6778db
  13. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4