1. 08 2月, 2013 1 次提交
  2. 07 2月, 2013 1 次提交
    • D
      drm/udl: make usage as a console safer · bcb39af4
      Dave Airlie 提交于
      Okay you don't really want to use udl devices as your console, but if
      you are unlucky enough to do so, you run into a lot of schedule while atomic
      due to printk being called from all sorts of funky places. So check if we
      are in an atomic context, and queue the damage for later, the next printk
      should cause it to appear. This isn't ideal, but it is simple, and seems to
      work okay in my testing here.
      
      (dirty area idea came from xenfb)
      
      fixes a bunch of sleeping while atomic issues running fbcon on udl devices.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      bcb39af4
  3. 21 1月, 2013 1 次提交
    • D
      drm: revamp framebuffer cleanup interfaces · 36206361
      Daniel Vetter 提交于
      We have two classes of framebuffer
      - Created by the driver (atm only for fbdev), and the driver holds
        onto the last reference count until destruction.
      - Created by userspace and associated with a given fd. These
        framebuffers will be reaped when their assoiciated fb is closed.
      
      Now these two cases are set up differently, the framebuffers are on
      different lists and hence destruction needs to clean up different
      things. Also, for userspace framebuffers we remove them from any
      current usage, whereas for internal framebuffers it is assumed that
      the driver has done this already.
      
      Long story short, we need two different ways to cleanup such drivers.
      Three functions are involved in total:
      - drm_framebuffer_remove: Convenience function which removes the fb
        from all active usage and then drops the passed-in reference.
      - drm_framebuffer_unregister_private: Will remove driver-private
        framebuffers from relevant lists and drop the corresponding
        references. Should be called for driver-private framebuffers before
        dropping the last reference (or like for a lot of the drivers where
        the fbdev is embedded someplace else, before doing the cleanup
        manually).
      - drm_framebuffer_cleanup: Final cleanup for both classes of fbs,
        should be called by the driver's ->destroy callback once the last
        reference is gone.
      
      This patch just rolls out the new interfaces and updates all drivers
      (by adding calls to drm_framebuffer_unregister_private at all the
      right places)- no functional changes yet. Follow-on patches will move
      drm core code around and update the lifetime management for
      framebuffers, so that we are no longer required to keep framebuffers
      alive by locking mode_config.mutex.
      
      I've also updated the kerneldoc already.
      
      vmwgfx seems to again be a bit special, at least I haven't figured out
      how the fbdev support in that driver works. It smells like it's
      external though.
      
      v2: The i915 driver creates another private framebuffer in the
      load-detect code. Adjust its cleanup code, too.
      Reviewed-by: NRob Clark <rob@ti.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      36206361
  4. 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
  5. 02 11月, 2012 1 次提交
    • D
      drm/udl: fix stride issues scanning out stride != width*bpp · 3916e1d7
      Dave Airlie 提交于
      When buffer sharing with the i915 and using a 1680x1050 monitor,
      the i915 gives is a 6912 buffer for the 6720 width, the code doesn't
      render this properly as it uses one value to set the base address for
      reading from the vmap and for where to start on the device.
      
      This fixes it by calculating the values correctly for the device and
      for the pixmap. No idea how I haven't seen this before now.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      3916e1d7
  6. 09 10月, 2012 1 次提交
    • K
      mm: kill vma flag VM_RESERVED and mm->reserved_vm counter · 314e51b9
      Konstantin Khlebnikov 提交于
      A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
      currently it lost original meaning but still has some effects:
      
       | effect                 | alternative flags
      -+------------------------+---------------------------------------------
      1| account as reserved_vm | VM_IO
      2| skip in core dump      | VM_IO, VM_DONTDUMP
      3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      4| do not mlock           | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      
      This patch removes reserved_vm counter from mm_struct.  Seems like nobody
      cares about it, it does not exported into userspace directly, it only
      reduces total_vm showed in proc.
      
      Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.
      
      remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
      remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.
      
      [akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
      Cc: Matt Helsley <matthltc@us.ibm.com>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      314e51b9
  7. 03 10月, 2012 2 次提交
  8. 02 10月, 2012 1 次提交
  9. 17 8月, 2012 1 次提交
  10. 31 5月, 2012 1 次提交
  11. 23 5月, 2012 1 次提交
  12. 15 3月, 2012 1 次提交
    • D
      drm/udl: initial UDL driver (v4) · 5320918b
      Dave Airlie 提交于
      This is an initial drm/kms driver for the displaylink devices.
      
      Supports fb_defio,
      supports KMS dumb interface
      supports 24bpp via conversion to 16bpp, hw can do this better.
      supports hot unplug using new drm core features.
      
      On an unplug, it disables connector polling, unplugs connectors
      from sysfs, unplugs fbdev layer (using Kay's API), drops all the
      USB device URBs, and call the drm core to unplug the device.
      
      This driver is based in large parts on udlfb.c so I've licensed
      it under GPLv2.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      5320918b