1. 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
  2. 07 8月, 2013 1 次提交
  3. 25 7月, 2013 1 次提交
    • D
      drm/ttm: convert to unified vma offset manager · 72525b3f
      David Herrmann 提交于
      Use the new vma-manager infrastructure. This doesn't change any
      implementation details as the vma-offset-manager is nearly copied 1-to-1
      from TTM.
      
      The vm_lock is moved into the offset manager so we can drop it from TTM.
      During lookup, we use the vma locking helpers to take a reference to the
      found object.
      In all other scenarios, locking stays the same as before. We always
      guarantee that drm_vma_offset_remove() is called only during destruction.
      Hence, helpers like drm_vma_node_offset_addr() are always safe as long as
      the node has a valid offset.
      
      This also drops the addr_space_offset member as it is a copy of vm_start
      in vma_node objects. Use the accessor functions instead.
      
      v4:
       - remove vm_lock
       - use drm_vma_offset_lock_lookup() to protect lookup (instead of vm_lock)
      
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Martin Peres <martin.peres@labri.fr>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Thomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@gmail.com>
      72525b3f
  4. 28 6月, 2013 1 次提交
  5. 17 6月, 2013 2 次提交
    • C
      drm/mgag200: Don't do full cleanup if mgag200_device_init fails · 27911977
      Christopher Harvey 提交于
      Running mgag200_driver_unload when the driver init fails early on
      causes functions like drm_mode_config_cleanup to be called. The
      problem is, drm_mode_config_cleanup crashes because the corresponding
      init hasn't happend yet. There really isn't anything to cleanup after
      mgag200_device_init, so we can just pass the error code upwards.
      Acked-by: NJulia Lemire <jlemire@matrox.com>
      Signed-off-by: NChristopher Harvey <charvey@matrox.com>
      Acked-by: NPaul Menzel <paulepanter@users.sourceforge.net>
      Signed-off-by: NDave Airlie <airlied@gmail.com>
      27911977
    • 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. 30 4月, 2013 1 次提交
  7. 12 4月, 2013 1 次提交
  8. 20 1月, 2013 2 次提交
    • D
      drm/<drivers>: Unified handling of unimplemented fb->create_handle · af26ef3b
      Daniel Vetter 提交于
      Some drivers don't have real ->create_handle callbacks.
      
      - cirrus/ast/mga200: Returns either 0 or -EINVAL.
      
      - udl: Didn't even bother with a callback, leading to a nice
        userspace-triggerable OOPS.
      
      - vmwgfx: This driver bothered with an implementation to return 0 as
        the handle (which is the canonical no-obj gem handle).
      
      All have in common that ->create_handle doesn't really make too much
      sense for them - that ioctl is used only for seamless fb takeover in
      the radeon/nouveau/i915 ddx drivers. So allow drivers to not implement
      this and return a consistent -ENODEV.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      af26ef3b
    • D
      drm/<drivers>: reorder framebuffer init sequence · c7d73f6a
      Daniel Vetter 提交于
      With more fine-grained locking we can no longer rely on the big
      mode_config lock to prevent concurrent access to mode resources
      like framebuffers. Instead a framebuffer becomes accessible to
      other threads as soon as it is added to the relevant lookup
      structures. Hence it needs to be fully set up by the time drivers
      call drm_framebuffer_init.
      
      This patch here is the drivers part of that reorg. Nothing really fancy
      going on safe for three special cases.
      
      - exynos needs to be careful to properly unref all handles.
      - nouveau gets a resource leak fixed for free: one of the error
        cases didn't cleanup the framebuffer, which is now moot since
        the framebuffer is only registered once it is fully set up.
      - vmwgfx requires a slight reordering of operations, I'm hoping I didn't
        break anything (but it's refcount management only, so should be safe).
      
      v2: Split out exynos, since it's a bit more hairy than expected.
      
      v3: Drop bogus cirrus hunk noticed by Richard Wilbur.
      
      v4: Split out vmwgfx since there's a small change in return values.
      
      Reviewed-by: Rob Clark <rob@ti.com> (core + omapdrm)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c7d73f6a
  9. 20 11月, 2012 3 次提交
  10. 03 10月, 2012 2 次提交
  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