1. 11 1月, 2006 3 次提交
  2. 06 1月, 2006 1 次提交
    • L
      [ATYFB]: Fix onboard video on SPARC Blade 100 for 2.6.{13,14,15} · 5b373e10
      Luis F. Ortiz 提交于
      	I have recently been switching from using 2.4.32 on my trusty
      old Sparc Blade 100 to using 2.6.15 .  Some of the problems I ran into
      were distorted video when the console was active (missing first
      character, skipped dots) and when running X windows (colored snow,
      stripes, missing pixels).  A quick examination of the 2.6 versus 2.4
      source for the ATY driver revealed alot of changes.
      
               A closer look at the code/data for the 64GR/XL chip revealed
      two minor "typos" that the rewriter(s) of the code made.  The first is
      a incorrect clock value (230 .vs. 235) and the second is a missing
      flag (M64F_SDRAM_MAGIC_PLL).  Making both these changes seems to have
      fixed my problem.  I tend to think the 235 value is the correct one,
      as there is a 29.4 Mhz clock crystal close to the video chip and 235.2
      (29.4*8) is too close to 235 to make it a coincidence.
      
      	The flag for M64F_SDRAM_MAGIC_PLL was dropped during the
      changes made by adaplas in file revision 1.72 on the old bitkeeper
      repository.
      
      	The change relating to the clock rate has been there forever,
      at least in the 2.6 tree.  I'm not sure where to look for the old 2.5
      tree or if anyone cares when it happened.
      
      On SPARC Blades 100's, which use the ATY MACH64GR video chipset, the
      clock crystal frequency is 235.2 Mhz, not 230 Mhz.  The chipset also
      requires the use of M64F_SDRAM_MAGIC_PLL in order to setup the PLL
      properly for the DRAM.
      Signed-off-by: NLuis F. Ortiz <lfo@Polyad.Org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b373e10
  3. 07 11月, 2005 2 次提交
    • A
      [PATCH] atyfb: Get initial mode timings from LCD BIOS · 1013d266
      Antonino A. Daplas 提交于
      Reported by: Jean-Philippe Guérard (Bugzilla Bug 1782)
      
      "I've tried with video=atyfb:debug and video=atyfb:debug,mode:1280x600, \
      nomtrr.
      
      In both case, the screen stays black, but seems divided into 4 vertical bands.
       Some white lines pop up randomly on each vertical band."
      
      The problem is a combination of an incorrect xclk plus lack of timing
      information.  The adapter is attached to an LCD device that can do 1280x600
      (which is not a standard resolution).  The global mode database does not have
      an entry for it.  Fortunately, the Video BIOS contains the complete timing
      info for this display, however, atyfb is not making use of it.
      
      Add support to get the timing information from the BIOS, if available.
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1013d266
    • A
      [PATCH] fbcon/fbdev: Move softcursor out of fbdev to fbcon · c465e05a
      Antonino A. Daplas 提交于
      According to Jon Smirl, filling in the field fb_cursor with soft_cursor for
      drivers that do not support hardware cursors is redundant.  The soft_cursor
      function is usable by all drivers because it is just a wrapper around
      fb_imageblit.  And because soft_cursor is an fbcon-specific hook, the file is
      moved to the console directory.
      
      Thus, drivers that do not support hardware cursors can leave the fb_cursor
      field blank.  For drivers that do, they can fill up this field with their own
      version.
      
      The end result is a smaller code size.  And if the framebuffer console is not
      loaded, module/kernel size is also reduced because the soft_cursor module will
      also not be loaded.
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c465e05a
  4. 10 9月, 2005 1 次提交
  5. 05 9月, 2005 1 次提交
  6. 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