1. 13 8月, 2008 3 次提交
    • J
      matroxfb: i2c structure templates clean-up · 73b7d92f
      Jean Delvare 提交于
      Clean up the use of structure templates in i2c-matroxfb. In this case
      it's more efficient to initialize the few fields we need individually.
      This makes i2c-matroxfb.ko 16% smaller on my system.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      73b7d92f
    • J
      matrox maven: fix a broken error path · 5ede40f8
      Jean Delvare 提交于
      I broke an error path with d03c21ec,
      sorry about that.
      
      The machine will crash if the i2c_attach_client() or maven_init_client()
      calls fail, although nobody has yet reported this happening.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz>
      Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5ede40f8
    • D
      radeonfb: fix accel engine hangs · 969830b2
      David Miller 提交于
      Some chips appear to have the 2D engine hang during screen redraw,
      typically in a sequence of copyarea operations. This appear to be
      solved by adding a flush of the engine destination pixel cache
      and waiting for the engine to be idle before issuing the accel
      operation. The performance impact seems to be fairly small.
      
      Here is a trace on an RV370 (PCI device ID 0x5b64), it records the
      RBBM_STATUS register, then the source x/y, destination x/y, and
      width/height used for the copy:
      
      ----------------------------------------
      radeonfb_prim_copyarea: STATUS[00000140] src[210:70] dst[210:60] wh[a0:10]
      radeonfb_prim_copyarea: STATUS[00000140] src[2b8:70] dst[2b8:60] wh[88:10]
      radeonfb_prim_copyarea: STATUS[00000140] src[348:70] dst[348:60] wh[40:10]
      radeonfb_prim_copyarea: STATUS[80020140] src[390:70] dst[390:60] wh[88:10]
      radeonfb_prim_copyarea: STATUS[8002613f] src[40:80] dst[40:70] wh[28:10]
      radeonfb_prim_copyarea: STATUS[80026139] src[a8:80] dst[a8:70] wh[38:10]
      radeonfb_prim_copyarea: STATUS[80026133] src[e8:80] dst[e8:70] wh[80:10]
      radeonfb_prim_copyarea: STATUS[8002612d] src[170:80] dst[170:70] wh[30:10]
      radeonfb_prim_copyarea: STATUS[80026127] src[1a8:80] dst[1a8:70] wh[8:10]
      radeonfb_prim_copyarea: STATUS[80026121] src[1b8:80] dst[1b8:70] wh[88:10]
      radeonfb_prim_copyarea: STATUS[8002611b] src[248:80] dst[248:70] wh[68:10]
      ----------------------------------------
      
      When things are going fine the copies complete before the next ROP is
      even issued, but all of a sudden the 2D unit becomes active (bit 17 in
      RBBM_STATUS) and the FIFO retry (bit 13) and FIFO pipeline busy (bit
      14) are set as well.  The FIFO begins to backup until it becomes full.
      
      What happens next is the radeon_fifo_wait() times out, and we access
      the chip illegally leading to a bus error which usually wedges the
      box.  None of this makes it to the console screen, of course :-)
      radeon_fifo_wait() should be modified to reset the accelerator when
      this timeout happens instead of programming the chip anyways.
      
      ----------------------------------------
      radeonfb: FIFO Timeout !
      ERROR(0): Cheetah error trap taken afsr[0010080005000000] afar[000007f900800e40] TL1(0)
      ERROR(0): TPC[595114] TNPC[595118] O7[459788] TSTATE[11009601]
      ERROR(0): TPC<radeonfb_copyarea+0xfc/0x248>
      ERROR(0): M_SYND(0),  E_SYND(0), Privileged
      ERROR(0): Highest priority error (0000080000000000) "Bus error response from system bus"
      ERROR(0): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
      ERROR(0): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
      ERROR(0): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[00\
      
      ERROR(0): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
      ERROR(0): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
      ERROR(0): E-cache idx[800e40] tag[000000000e049f4c]
      ERROR(0): E-cache data0[fffff8127d300180] data1[00000000004b5384] data2[0000000000000000] data3[0000000000000000]
      Ker:xnel panic - not syncing: Irrecoverable deferred error trap.
      ----------------------------------------
      
      Another quirk is that these copyarea calls will not happen until the
      first drivers/char/vt.c:redraw_screen() occurs.  This will only happen
      if you 1) VC switch or 2) run "consolechars" or 3) unblank the screen.
      
      This seems to happen because until a redraw_screen() the screen scrolling
      method used by fbcon is not finalized yet.  I've seen this with other fb
      drivers too.
      
      So if all you do is boot straight into X you will never see this bug on
      the relevant chips.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      969830b2
  2. 12 8月, 2008 1 次提交
  3. 07 8月, 2008 3 次提交
  4. 06 8月, 2008 8 次提交
  5. 02 8月, 2008 1 次提交
  6. 31 7月, 2008 6 次提交
  7. 30 7月, 2008 1 次提交
  8. 29 7月, 2008 3 次提交
  9. 27 7月, 2008 6 次提交
  10. 25 7月, 2008 8 次提交