1. 12 9月, 2014 4 次提交
  2. 11 9月, 2014 2 次提交
  3. 10 9月, 2014 18 次提交
  4. 11 8月, 2014 1 次提交
    • D
      drm/irq: Implement a generic vblank_wait function · e8450f51
      Daniel Vetter 提交于
      As usual in both a crtc index and a struct drm_crtc * version.
      
      The function assumes that no one drivers their display below 10Hz, and
      it will complain if the vblank wait takes longer than that.
      
      v2: Also check dev->max_vblank_counter since some drivers register a
      fake get_vblank_counter function.
      
      v3: Use drm_vblank_count instead of calling the low-level
      ->get_vblank_counter callback. That way we'll get the sw-cooked
      counter for platforms without proper vblank support and so can ditch
      the max_vblank_counter check again.
      
      v4: Review from Michel Dänzer:
      - Restore lost notes about v3:
      - Spelling in kerneldoc.
      - Inline wait_event condition.
      - s/vblank_wait/wait_one_vblank/
      
      Cc: Michel Dänzer <michel@daenzer.net>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
      Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e8450f51
  5. 08 8月, 2014 2 次提交
  6. 07 8月, 2014 2 次提交
  7. 06 8月, 2014 1 次提交
  8. 05 8月, 2014 5 次提交
    • D
      drm: make sysfs device always available for minors · e1728075
      David Herrmann 提交于
      For each minor we allocate a sysfs device as minor->kdev. Currently, this
      is allocated and registered in drm_minor_register(). This makes it
      impossible to add sysfs-attributes to the device before it is registered.
      Therefore, they are not added atomically, nor can we move device_add()
      *after* ->load() is called.
      
      This patch makes minor->kdev available early, but only adds the device
      during minor-registration. Note that the registration is still called
      before ->load() as debugfs needs to be split, too. This will be fixed in
      follow-ups.
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      e1728075
    • D
      drm: move module initialization to drm_stub.c · 1b7199fe
      David Herrmann 提交于
      Most of the new DRM management functions are nowadays in drm_stub.c. By
      moving the core module initialization to drm_stub.c we can make several
      global variables static and keep the stub-open helper local.
      
      The core files now look like this:
        drm_stub.c: Core management
         drm_drv.c: Ioctl dispatcher
       drm_ioctl.c: Actual ioctl backends
        drm_fops.c: Char-dev file-operations
      
      A follow-up patch will move what is left from drm_drv.c into drm_ioctl.c.
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      1b7199fe
    • D
      drm: don't de-authenticate clients on master-close · 3cb01a98
      David Herrmann 提交于
      If an active DRM-Master closes its device, we deauthenticate all clients
      on that master. However, if an inactive DRM-Master closes its device, we
      do nothing. This is quite inconsistent and breaks several scenarios:
      
       1) If this was used as security mechanism, it fails horribly if a master
          closes a device while VT switched away. Furthermore, none of the few
          drivers using ->master_*() callbacks seems to require it, anyway.
      
       2) If you spawn weston (or any other non-UMS compositor) in background
          while another compositor is active, both will get assigned to the
          same "drm_master" object. If the foreground compositor now exits, all
          clients of both the foreground AND background compositor will be
          de-authenticated leading to unexpected behavior.
      
      Stop this non-sense and keep clients authenticated. We don't do this when
      dropping DRM-Master (i.e., switching VTs) so don't do it on active-close
      either!
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      3cb01a98
    • D
      drm: drop redundant drm_file->is_master · 48ba8137
      David Herrmann 提交于
      The drm_file->is_master field is redundant as it's equivalent to:
          drm_file->master && drm_file->master == drm_file->minor->master
      
      1) "=>"
        Whenever we set drm_file->is_master, we also set:
            drm_file->minor->master = drm_file->master;
      
        Whenever we clear drm_file->is_master, we also call:
            drm_master_put(&drm_file->minor->master);
        which implicitly clears it to NULL.
      
      2) "<="
        minor->master cannot be set if it is non-NULL. Therefore, it stays as
        is unless a file drops it.
      
        If minor->master is NULL, it is only set by places that also adjust
        drm_file->is_master.
      
      Therefore, we can safely drop is_master and replace it by an inline helper
      that matches:
          drm_file->master && drm_file->master == drm_file->minor->master
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      48ba8137
    • D
      drm: extract legacy ctxbitmap flushing · 9f8d21ea
      David Herrmann 提交于
      The ctxbitmap code is only used by legacy drivers so lets try to keep it
      as separated as possible. Furthermore, the locking is non-obvious and
      kinda weird with ctxlist_mutex *and* struct_mutex. Keeping all ctxbitmap
      access in one file is much easier to review and makes drm_release() more
      readable.
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      9f8d21ea
  9. 02 8月, 2014 2 次提交
  10. 09 7月, 2014 1 次提交
  11. 08 7月, 2014 2 次提交