1. 22 7月, 2014 1 次提交
  2. 09 10月, 2013 1 次提交
    • D
      drm: kill ->gem_init_object() and friends · 16eb5f43
      David Herrmann 提交于
      All drivers embed gem-objects into their own buffer objects. There is no
      reason to keep drm_gem_object_alloc(), gem->driver_private and
      ->gem_init_object() anymore.
      
      New drivers are highly encouraged to do the same. There is no benefit in
      allocating gem-objects separately.
      
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Alex Deucher <alexdeucher@gmail.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Ben Skeggs <skeggsb@gmail.com>
      Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      16eb5f43
  3. 07 8月, 2013 1 次提交
  4. 28 6月, 2013 2 次提交
  5. 17 6月, 2013 1 次提交
    • C
      drm/mgag200: Hardware cursor support · a080db9f
      Christopher Harvey 提交于
      G200 cards support, at best, 16 colour palleted images for the cursor
      so we do a conversion in the cursor_set function, and reject cursors
      with more than 16 colours, or cursors with partial transparency. Xorg
      falls back gracefully to software cursors in this case.
      
      We can't disable/enable the cursor hardware without causing momentary
      corruption around the cursor. Instead, once the cursor is on we leave
      it on, and simulate turning the cursor off by moving it
      offscreen. This works well.
      
      Since we can't disable -> update -> enable the cursors, we double
      buffer cursor icons, then just move the base address that points to
      the old cursor, to the new. This also works well, but uses an extra
      page of memory.
      
      The cursor buffers are lazily-allocated on first cursor_set. This is
      to make sure they don't take priority over any framebuffers in case of
      limited memory.
      
      Here is a representation of how the bitmap for the cursor is mapped in G200 memory :
      
        Each line of color cursor use 6 Slices of 8 bytes. Slices 0 to 3
        are used for the 4bpp bitmap, slice 4 for XOR mask and slice 5 for
        AND mask. Each line has the following format:
      
            //      Byte 0  Byte 1  Byte 2  Byte 3  Byte 4  Byte 5  Byte 6 Byte 7
            //
            // S0:  P00-01  P02-03  P04-05  P06-07  P08-09  P10-11  P12-13 P14-15
            // S1:  P16-17  P18-19  P20-21  P22-23  P24-25  P26-27  P28-29 P30-31
            // S2:  P32-33  P34-35  P36-37  P38-39  P40-41  P42-43  P44-45 P46-47
            // S3:  P48-49  P50-51  P52-53  P54-55  P56-57  P58-59  P60-61 P62-63
            // S4:  X63-56  X55-48  X47-40  X39-32  X31-24  X23-16  X15-08 X07-00
            // S5:  A63-56  A55-48  A47-40  A39-32  A31-24  A23-16  A15-08 A07-00
            //
            //       S0 to S5      = Slices 0 to 5
            //       P00 to P63    = Bitmap - pixels 0 to 63
            //       X00 to X63    = always 0 - pixels 0 to 63
            //       A00 to A63    = transparent markers - pixels 0 to 63
            //                       1 means colour, 0 means transparent
      Signed-off-by: NChristopher Harvey <charvey@matrox.com>
      Signed-off-by: NMathieu Larouche <mathieu.larouche@matrox.com>
      Acked-by: NJulia Lemire <jlemire@matrox.com>
      Tested-by: NJulia Lemire <jlemire@matrox.com>
      Signed-off-by: NDave Airlie <airlied@gmail.com>
      a080db9f
  6. 02 5月, 2013 1 次提交
    • D
      drm/mgag200: deal with bo reserve fail in dirty update path · 64171959
      Dave Airlie 提交于
      On F19 testing, it was noticed we get a lot of errors in dmesg
      about being unable to reserve the buffer when plymouth starts,
      this is due to the buffer being in the process of migrating,
      so it makes sense we can't reserve it.
      
      In order to deal with it, this adds delayed updates for the dirty
      updates, when the bo is unreservable, in the normal console case
      this shouldn't ever happen, its just when plymouth or X is
      pushing the console bo to system memory.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      64171959
  7. 12 4月, 2013 1 次提交
  8. 08 3月, 2013 1 次提交
  9. 03 10月, 2012 1 次提交
  10. 24 8月, 2012 1 次提交
  11. 17 5月, 2012 1 次提交
    • D
      mgag200: initial g200se driver (v2) · 414c4531
      Dave Airlie 提交于
      This is a driver for the G200 server engines chips,
      it doesn't driver any of the Matrix G series desktop cards.
      
      It will bind to G200 SE A,B, G200EV, G200WB, G200EH and G200ER cards.
      
      Its based on previous work done my Matthew Garrett but remodelled
      to follow the same style and flow as the AST server driver. It also
      works along the same lines as the AST server driver wrt memory management.
      
      There is no userspace driver planned, xf86-video-modesetting should be used.
      It also appears these GPUs have no ARGB hw cursors.
      
      v2: add missing tagfifo reset + G200 SE memory bw setup pieces.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      414c4531