1. 30 12月, 2016 3 次提交
  2. 11 12月, 2016 1 次提交
    • D
      drm: Add fake controlD* symlinks for backwards compat · 6449b088
      Daniel Vetter 提交于
      We thought that no userspace is using them, but oops libdrm is using
      them to figure out whether a driver supports modesetting. Check out
      drmCheckModesettingSupported but maybe don't because it's horrible and
      totally runs counter to where we want to go with libdrm device
      handling. The function looks in the device hierarchy for whether
      controlD* exist using the following format string:
      
      /sys/bus/pci/devices/%04x:%02x:%02x.%d/drm/controlD%d
      
      The "/drm" subdirectory is the glue directory from the sysfs class
      stuff, and the only way to get at it seems to through
      kdev->kobj.parent (when kdev is represents e.g. the card0 chardev
      instance in sysfs). Git grep says we're not the only ones touching
      that, so I hope it's ok we dig into such internals - I couldn't find a
      proper interface for getting at the glue directory.
      
      Quick git grep shows that at least -amdgpu, -ati are using this.
      -modesetting do not, and on -intel it's only about the 4th fallback
      path for device lookup, which is why this didn't blow up earlier.
      
      Oh well, we need to keep it working, and the simplest way is to add a
      symlink at the right place in sysfs from controlD* to card*.
      
      v2:
      - Fix error path handling by adding if (!minor) return checks (David)
      - Fix the controlD* numbers to match what's been there (David)
      - Add a comment what exactly userspace minimally needs.
      - Correct the analysis for -intel (Chris).
      
      Fixes: 8a357d10 ("drm: Nerf DRM_CONTROL nodes")
      Cc: Dave Airlie <airlied@gmail.com>
      Reported-and-tested-by: NAlex Deucher <alexander.deucher@amd.com>
      Acked-by: NEmil Velikov <emil.l.velikov@gmail.com>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161209135656.14881-1-daniel.vetter@ffwll.ch
      6449b088
  3. 08 12月, 2016 1 次提交
  4. 17 11月, 2016 1 次提交
    • D
      drm: Nerf DRM_CONTROL nodes · 8a357d10
      Daniel Vetter 提交于
      Looking at the ioctl permission checks I noticed that it's impossible
      to import gem buffers into a control nodes, and fd2handle/handle2fd
      also don't work, so no joy with dma-bufs.
      
      The only way to do anything with a control node is by drawing stuff
      into a dumb buffer and displaying that. I suspect control nodes are an
      entirely unused thing, and a cursory check shows that there does not
      seem to be any callers of drmOpenControl nor of the other drmOpen
      functions using DRM_MODE_CONTROL.
      
      Since I don't like dead uabi, let's remove it. But since this would be
      a really big change I think it's better to start out small by simply
      not registering anything. We can garbage-collect the dead code later
      on, once we're sure it's really not used anywhere.
      Acked-by: NDave Airlie <airlied@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161028081050.1042-1-daniel.vetter@ffwll.ch
      8a357d10
  5. 15 11月, 2016 2 次提交
  6. 11 11月, 2016 1 次提交
  7. 04 10月, 2016 1 次提交
  8. 22 9月, 2016 2 次提交
  9. 19 9月, 2016 2 次提交
    • D
      drm: cleanup drm_core_{init,exit}() · 2cc107dc
      David Herrmann 提交于
      Various cleanups to the DRM core initialization and exit handlers:
      
       - Register chrdev last: Once register_chrdev() returns, open() will
         succeed on the given chrdevs. This is usually not an issue, as no
         chardevs are registered, yet. However, nodes can be created by
         user-space via mknod(2), even though such major/minor combinations are
         unknown to the kernel. Avoid calling into drm_stub_open() in those
         cases.
         Again, drm_stub_open() would just bail out as the inode is unknown,
         but it's really non-obvious if you hack on drm_stub_open().
      
       - Unify error-paths into just one label. All the error-path helpers can
         be called even though the constructors were not called yet, or failed.
         Hence, just call all cleanups unconditionally.
      
       - Call into drm_global_release(). This is a no-op, but provides
         debugging helpers in case there're GLOBALS left on module unload. This
         function was unused until now.
      
       - Use DRM_ERROR() instead of printk(), and also print the error-code on
         failure (even if it is static!).
      
       - Don't throw away error-codes of register_chrdev()!
      
       - Don't hardcode -1 as errno. This is just plain wrong.
      
       - Order exit-handlers in the exact reverse order of initialization
         (except if the order actually matters for syncing-reasons, which is
         not the case here, though).
      
      v2:
       - Call drm_core_exit() directly from the init-error-handler. Requires to
         drop __exit annotation, though.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20160901124837.680-7-dh.herrmann@gmail.com
      2cc107dc
    • D
      drm: drop obsolete drm_core.h · 82d5e73f
      David Herrmann 提交于
      The drm_core.h header contains a set of constants meant to be used
      throughout DRM. However, as it turns out, they're each used just once and
      don't bring any benefit. They're also grossly mis-named and lack
      name-spacing. This patch inlines them, or moves them into drm_internal.h
      as appropriate:
      
       - CORE_AUTHOR and CORE_DESC are inlined into corresponding MODULE_*()
         macros. It's just confusing having to follow 2 pointers when trying to
         find the definition of these fields. Grep'ping for MODULE_AUTHOR()
         should reveal the full information, if there's no strong reason not to.
      
       - CORE_NAME, CORE_DATE, CORE_MAJOR, CORE_MINOR, and CORE_PATCHLEVEL are
         inlined into the sysfs 'version' attribute. They're stripped
         everywhere else (which is just some printk() statements). CORE_NAME
         just doesn't make *any* sense, as we hard-code it in many places,
         anyway. The other constants are outdated and just serve
         binary-compatibility purposes. Hence, inline them in 'version' sysfs
         attribute (we might even try dropping it..).
      
       - DRM_IF_MAJOR and DRM_IF_MINOR are moved into drm_internal.h as they're
         only used by the global ioctl handlers. Furthermore, versioning
         interfaces breaks backports and as such is deprecated, anyway. We just
         keep them for historic reasons. I doubt anyone will ever modify them
         again.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20160901124837.680-6-dh.herrmann@gmail.com
      82d5e73f
  10. 23 8月, 2016 1 次提交
  11. 19 8月, 2016 1 次提交
  12. 08 8月, 2016 1 次提交
  13. 12 7月, 2016 1 次提交
  14. 22 6月, 2016 4 次提交
  15. 19 6月, 2016 1 次提交
    • C
      drm: Protect drm_connector_register_all() under DRIVER_MODESET · bee7fb15
      Chris Wilson 提交于
      0-day kbuilder found
      
      [    1.360244] BUG: unable to handle kernel NULL pointer dereference at   (null)
      [    1.360972] IP: [<c14db9ad>] mutex_lock_nested+0x11f/0x2c3
      [    1.361512] *pde = 00000000
      [    1.361827] Oops: 0002 [#1]
      [    1.362123] Modules linked in:
      [    1.362451] CPU: 0 PID: 1 Comm: swapper Not tainted 4.7.0-rc2-00564-ge28cd4d0 #1
      [    1.363202] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
      [    1.364105] task: c03d0000 ti: d28da000 task.ti: d28da000
      [    1.364636] EIP: 0060:[<c14db9ad>] EFLAGS: 00210096 CPU: 0
      [    1.365215] EIP is at mutex_lock_nested+0x11f/0x2c3
      [    1.365703] EAX: 00000000 EBX: d39e8ae8 ECX: d39e8b14 EDX: c1361cf9
      [    1.366351] ESI: c03d0000 EDI: d28dbed0 EBP: d28dbeec ESP: d28dbec0
      [    1.367010]  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      [    1.367534] CR0: 80050033 CR2: 00000000 CR3: 019a9000 CR4: 00000690
      [    1.368152] Stack:
      [    1.368356]  d39e8b14 d39e8b24 c1361cf9 00200246 d39e8b14 00000000 11111111 d28dbed0
      [    1.369235]  d39e8800 d39e8ae8 00000000 d28dbf08 c1361cf9 d28dbf0c c10b25be d39e8800
      [    1.370087]  00000000 00000000 d28dbf1c c135e37d fffffff4 ffffffff 00000000 d28dbf28
      [    1.371012] Call Trace:
      [    1.371272]  [<c1361cf9>] ? drm_connector_register_all+0x1a/0x92
      [    1.371847]  [<c1361cf9>] drm_connector_register_all+0x1a/0x92
      [    1.372421]  [<c10b25be>] ? kstrdup+0x25/0x3a
      [    1.372863]  [<c135e37d>] drm_dev_register+0x59/0x99
      [    1.373358]  [<c195ea3e>] vgem_init+0x34/0x49
      [    1.373770]  [<c195ea0a>] ? mipi_dsi_bus_init+0xf/0xf
      [    1.374257]  [<c100048f>] do_one_initcall+0x7c/0xfd
      [    1.374754]  [<c104b409>] ? parse_args+0x1fd/0x314
      [    1.375259]  [<c1939c10>] ? kernel_init_freeable+0xd0/0x179
      [    1.375837]  [<c1939c2c>] kernel_init_freeable+0xec/0x179
      [    1.376371]  [<c14d66ea>] kernel_init+0x8/0xcb
      [    1.376806]  [<c14debce>] ret_from_kernel_thread+0xe/0x30
      [    1.377322]  [<c14d66e2>] ? rest_init+0x10e/0x10e
      [    1.377754] Code: 89 fa e8 71 c5 b7 ff 8b 4e 04 89 fa 89 d8 e8 8e c6 b7 ff 8d 43 2c 89 45 d4 8b 43 30 8d 4b 2c 89 45 e8 89 7b 30 89 4d e4 8b 55 dc <89> 38 8d 43 3c 89 75 ec e8 c9 dd b7 ff eb 0c 31 c0 87 03 48
      +75
      [    1.380442] EIP: [<c14db9ad>] mutex_lock_nested+0x11f/0x2c3 SS:ESP 0068:d28dbec0
      [    1.381174] CR2: 0000000000000000
      
      when loading the non-modesetting vGEM module. To prevent use of the
      uninitialised dev->mode_config from drm_dev_register() we move the
      drm_connector_register_all() under a DRIVER_MODESET guard. Longer term,
      we probably want to initialise the embedded dev->mode_config automatically
      from drm_dev_init() for all DRIVER_MODESET drivers.
      
      v2: Also protect drm_dev_unregister.
      
      Fixes: e28cd4d0 ("drm: Automatically register/unregister all connectors")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Emil Velikov <emil.l.velikov@gmail.com>
      Cc: dri-devel@lists.freedesktop.org
      Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
      Testcase: igt/vgem_reload_basic
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1466257601-5656-1-git-send-email-chris@chris-wilson.co.uk
      bee7fb15
  16. 17 6月, 2016 2 次提交
  17. 16 6月, 2016 2 次提交
  18. 09 6月, 2016 1 次提交
    • L
      drm: Remove dev_pm_ops from drm_class · d14d2a84
      Lukas Wunner 提交于
      The PM core introduced the ability to keep devices runtime suspended
      during the entire system suspend/resume process with commit aae4518b
      ("PM / sleep: Mechanism to avoid resuming runtime-suspended devices
      unnecessarily"). Before this so-called "direct-complete" procedure was
      introduced, devices were always runtime resumed only to be immediately
      put to sleep again using their ->suspend hook. Direct-complete is
      enabled by returning a positive value from the ->prepare hook. The PCI
      core usually does this automatically.
      
      Direct-complete is only available for a device if all children use it as
      well. Currently we cannot support direct-complete for DRM drivers
      because the DRM core automatically registers multiple DRM minors which
      belong to device class drm_class, and drm_class uses a struct dev_pm_ops
      which lacks the ->prepare callback.
      
      While this could be solved by adding the missing ->prepare callback,
      closer inspection shows that there are no DRM drivers left which declare
      the legacy ->suspend and ->resume callbacks in their drm_driver struct.
      The last ones to remove them were i915 with commit 1751fcf9
      ("drm/i915: Fix module initialisation, v2.") and exynos with commit
      e7fefb1d ("drm/exynos: remove legacy ->suspend()/resume()").
      
      Consequently the struct dev_pm_ops of drm_class is now dead code. Remove
      it. If no dev_pm_ops is declared for a device, the PM core automatically
      enables direct-complete for it, thereby making that mechanism available
      to the parent DRM PCI devices.
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/da848fcd5ca72a35d9a722e644719977a47bb7ba.1465382836.git.lukas@wunner.de
      d14d2a84
  19. 27 4月, 2016 3 次提交
  20. 21 4月, 2016 1 次提交
  21. 20 4月, 2016 1 次提交
  22. 08 1月, 2016 1 次提交
  23. 15 12月, 2015 2 次提交
  24. 04 12月, 2015 1 次提交
  25. 16 10月, 2015 1 次提交
  26. 30 9月, 2015 1 次提交
    • D
      drm/doc: Update docs about device instance setup · 6e3f797c
      Daniel Vetter 提交于
      ->load is deprecated, bus functions are deprecated and everyone
      should use drm_dev_alloc&register.
      
      So update the .tmpl (and pull a bunch of the overview docs into the
      sourcecode to increase chances that it'll stay in sync in the future)
      and add notes to functions which are deprecated. I didn't bother to
      clean up and document the unload sequence similarly since that one is
      still a bit a mess: drm_dev_unregister does way too much,
      drm_unplug_dev does what _unregister should be doing but then has the
      complication of promising something it doesn't actually do (it doesn't
      unplug existing open fds for instance, only prevents new ones).
      
      Motivated since I don't want to hunt every new driver for usage of
      drm_platform_init any more ;-)
      
      v2: Reword the deprecation note for ->load a bit, using Laurent's
      suggestion as an example (but making the wording a bit stronger even).
      Fix spelling in commit message.
      
      v3: More spelling fixes from Laurent.
      
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Acked-by: David Herrmann <dh.herrmann@gmail.com> (v2)
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6e3f797c
  27. 09 9月, 2015 1 次提交
    • D
      drm: move drm_class into drm_sysfs.c · fcc90213
      David Herrmann 提交于
      Right now, drm_sysfs_create() returns the newly allocated "struct class"
      to the caller (which is drm_core_init()), which then has to set the
      global variable 'drm_class'. During cleanup, though, we call
      drm_sysfs_destroy() which implicitly uses the global 'drm_class'. This is
      confusing, as ownership of the global 'drm_class' is non-obvious.
      
      This patch changes drm_sysfs_create() to drm_sysfs_init() and makes it
      initialize the 'drm_class' object directly, rather than returning it.
      This way, both drm_sysfs_init() and drm_sysfs_destroy() work in a similar
      fashion and manage the global drm class.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      fcc90213