1. 30 Mar, 2017 2 commits
    • Lukas Wunner's avatar
      PCI: Recognize Thunderbolt devices · 8531e283
      Lukas Wunner authored
      Detect on probe whether a PCI device is part of a Thunderbolt controller.
      Intel uses a Vendor-Specific Extended Capability (VSEC) with ID 0x1234
      on such devices.  Detect presence of this VSEC and cache it in a newly
      added is_thunderbolt bit in struct pci_dev.
      
      Also, add a helper to check whether a given PCI device is situated on a
      Thunderbolt daisy chain (i.e., below a PCI device with is_thunderbolt
      set).
      
      The necessity arises from the following:
      
      * If an external Thunderbolt GPU is connected to a dual GPU laptop,
        that GPU is currently registered with vga_switcheroo even though it
        can neither drive the laptop's panel nor be powered off by the
        platform.  To vga_switcheroo it will appear as if two discrete
        GPUs are present.  As a result, when the external GPU is runtime
        suspended, vga_switcheroo will cut power to the internal discrete GPU
        which may not be runtime suspended at all at this moment.  The
        solution is to not register external GPUs with vga_switcheroo, which
        necessitates a way to recognize if they're on a Thunderbolt daisy
        chain.
      
      * Dual GPU MacBook Pros introduced 2011+ can no longer switch external
        DisplayPort ports between GPUs.  (They're no longer just used for DP
        but have become combined DP/Thunderbolt ports.)  The driver to switch
        the ports, drivers/platform/x86/apple-gmux.c, needs to detect presence
        of a Thunderbolt controller and, if found, keep external ports
        permanently switched to the discrete GPU.
      
      v2: Make kerneldoc for pci_is_thunderbolt_attached() more precise,
          drop portion of commit message pertaining to separate series.
          (Bjorn Helgaas)
      
      Cc: Andreas Noever <andreas.noever@gmail.com>
      Cc: Michael Jamet <michael.jamet@intel.com>
      Cc: Tomas Winkler <tomas.winkler@intel.com>
      Cc: Amir Levy <amir.jer.levy@intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Link: http://patchwork.freedesktop.org/patch/msgid/0ab165a4a35c0b60f29d4c306c653ead14fcd8f9.1489145162.git.lukas@wunner.de
      8531e283
    • Lukas Wunner's avatar
      MAINTAINERS: Add Lukas Wunner as reviewer for vga_switcheroo · 8ccd1e51
      Lukas Wunner authored
      I've been contributing to vga_switcheroo for the past two years and by
      now am fairly familiar with it, so danvet suggested that I add myself
      as reviewer.
      
      While at it, add missing file pattern for vga_switcheroo.h + vgaarb.h
      to the DRM and DRM-MISC sections such that get_maintainer.pl returns
      dri-devel@ and the drm-misc maintainers.
      Suggested-and-acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Link: http://patchwork.freedesktop.org/patch/msgid/ff2320a0790d039e714cf352cf32ec16fa370627.1490623913.git.lukas@wunner.de
      8ccd1e51
  2. 31 Mar, 2017 1 commit
  3. 30 Mar, 2017 7 commits
  4. 29 Mar, 2017 21 commits
  5. 28 Mar, 2017 1 commit
  6. 27 Mar, 2017 5 commits
    • Daniel Vetter's avatar
      drm/tegra: Don't use modeset_lock_crtc · 99612b27
      Daniel Vetter authored
      Yes the help text is unhelpful, but atomic drivers should never use
      this. Just grab the lock without context or anything.
      
      Also an aside: Checking ->active like this doesn't protect against
      nonblocking commits, this is rather bogus.
      
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Acked-by: default avatarThierry Reding <thierry.reding@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-8-daniel.vetter@ffwll.ch
      99612b27
    • Gabriel Krisman Bertazi's avatar
      drm: bochs: Prevent double-free of fb helper · c0411316
      Gabriel Krisman Bertazi authored
      If fbdev registration fails for whatever reason, the error path of
      bochs_fbdev_init() will call bochs_fbdev_fini(), but since an fbdev
      initialization error is not fatal to the probe function, a subsequent
      device removal will try to call bochs_fbdev_fini() again, hitting the
      Oops below.
      
      This was detected by 0-day with a failing framebuffer registration and
      CONFIG_DEBUG_TEST_DRIVER_REMOVE=y.  This reproduces the scenario I
      mentioned above at insmod time, because the test attempts to remove the
      device right after probing.
      
      root@debian:~# insmod bochs-drm.ko
      [   17.609635] [drm] Found bochs VGA, ID 0xb0c0.
      [   17.612974] [drm] Framebuffer size 16384 kB @ 0xfa000000, mmio @ 0xfebf2000.
      [   17.613938] [TTM] Zone  kernel: Available graphics memory: 1022244 kiB
      [   17.614701] [TTM] Initializing pool allocator
      [   17.615427] [TTM] Initializing DMA pool allocator
      [   17.619143] fbcon: bochsdrmfb (fb0) is primary device
      [   17.619428] Console: switching to colour frame buffer device 128x48
      [   17.621047] bochs-drm 0000:00:02.0: fb0: bochsdrmfb frame buffer device
      [   17.641111] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:02.0 on minor 0
      [   17.642380] general protection fault: 0000 [#1] SMP
      [   17.642985] Modules linked in: bochs_drm(+)
      [   17.643259] CPU: 4 PID: 3279 Comm: insmod Tainted: G        W       4.11.0-rc1+ #119
      [   17.643259] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
      [   17.643259] task: ffff88007af35e00 task.stack: ffffc90000d84000
      [   17.643259] RIP: 0010:drm_fb_helper_fini+0x8e/0x110
      [   17.643259] RSP: 0018:ffffc90000d87ad0 EFLAGS: 00010202
      [   17.643259] RAX: dead000000000200 RBX: ffff8800790d5770 RCX: 0000000000000000
      [   17.652101] RDX: dead000000000100 RSI: 000000007fffffff RDI: ffffffff81eaf820
      [   17.652101] RBP: ffffc90000d87ae0 R08: 0000000000000000 R09: ffff88007271d918
      [   17.652101] R10: ffffc90000d87a88 R11: 0000000000000000 R12: 0000000000000000
      [   17.652101] R13: ffff8800790d56d0 R14: 0000000000000000 R15: 0000000000000000
      [   17.652101] FS:  00007f9285995700(0000) GS:ffff88007cf00000(0000) knlGS:0000000000000000
      [   17.652101] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   17.652101] CR2: 0000564f1cf9f1e8 CR3: 0000000079686000 CR4: 00000000000006e0
      [   17.652101] Call Trace:
      [   17.652101]  bochs_fbdev_fini+0x24/0x90 [bochs_drm]
      [   17.652101]  bochs_unload+0x16/0x50 [bochs_drm]
      [   17.652101]  drm_dev_unregister+0x37/0xd0
      [   17.652101]  drm_put_dev+0x31/0x60
      [   17.652101]  bochs_pci_remove+0x10/0x20 [bochs_drm]
      [   17.652101]  pci_device_remove+0x34/0xb0
      [   17.652101]  driver_probe_device+0xd0/0x370
      [   17.652101]  __driver_attach+0x96/0xa0
      [   17.652101]  ? driver_probe_device+0x370/0x370
      [   17.652101]  bus_for_each_dev+0x5b/0x90
      [   17.652101]  driver_attach+0x19/0x20
      [   17.652101]  bus_add_driver+0x11c/0x220
      [   17.652101]  driver_register+0x5b/0xd0
      [   17.652101]  ? 0xffffffffa0006000
      [   17.652101]  __pci_register_driver+0x47/0x50
      [   17.652101]  drm_pci_init+0xe1/0xf0
      [   17.652101]  ? 0xffffffffa0006000
      [   17.652101]  bochs_init+0x3c/0x1000 [bochs_drm]
      [   17.652101]  do_one_initcall+0x3e/0x180
      [   17.652101]  ? kmem_cache_alloc_trace+0x33/0x150
      [   17.652101]  do_init_module+0x5a/0x1eb
      [   17.652101]  load_module+0x1ea0/0x2650
      [   17.652101]  ? __symbol_put+0x40/0x40
      [   17.652101]  ? kernel_read_file+0x19e/0x1c0
      [   17.652101]  ? kernel_read_file_from_fd+0x44/0x70
      [   17.652101]  SYSC_finit_module+0xba/0xc0
      [   17.652101]  SyS_finit_module+0x9/0x10
      [   17.652101]  entry_SYSCALL_64_fastpath+0x1a/0xa9
      [   17.652101] RIP: 0033:0x7f92854da119
      [   17.652101] RSP: 002b:00007ffcd0390498 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      [   17.652101] RAX: ffffffffffffffda RBX: 00007f928578eb58 RCX: 00007f92854da119
      [   17.652101] RDX: 0000000000000000 RSI: 0000564f1c8bd638 RDI: 0000000000000003
      [   17.652101] RBP: 000000000000270e R08: 0000000000000000 R09: 00007f9285790ea0
      [   17.652101] R10: 0000000000000003 R11: 0000000000000246 R12: 00007f928578eb58
      [   17.652101] R13: 0000000000001020 R14: 0000564f1cf9e1c0 R15: 00007f928578eb00
      [   17.652101] Code: c7 20 f8 ea 81 e8 b3 3e 50 00 48 8b 83 d0 00 00 00 48 8d 93 d0 00 00 00 48 39 c2 74 46 48 8b 83 d8 00 00 00 48 8b 93 d0 00 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 0000 ad de 48 89 83 d0
      [   17.652101] RIP: drm_fb_helper_fini+0x8e/0x110 RSP: ffffc90000d87ad0
      [   17.653331] ---[ end trace 542fd75a2e60a6a4 ]---
      Signed-off-by: default avatarGabriel Krisman Bertazi <krisman@collabora.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170324045444.11912-1-krisman@collabora.co.ukSigned-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      c0411316
    • Daniel Vetter's avatar
      drm/atomic: Introduce drm_atomic_helper_shutdown · 18dddadc
      Daniel Vetter authored
      The trouble here is that it does multiple atomic commits under one
      drm_modeset_lock_all, which breaks the behind-the-scenes acquire
      context magic that function pulls off. It's much better to have one
      overall atomic commit. That we still have multiple atomic commits
      prevents us from adding some pretty useful debug checks to the atomic
      machinery.
      
      Hence it is really a bad idea to call the legacy
      drm_crtc_force_disable_all() function. There's 2 atomic drivers using
      this still, nouveau and tinydrm. To fix this, introduce a new
      drm_atomic_helper_shutdown() by extracting the code from i915.
      
      While at it improve kernel-doc and catch future offenders by
      sprinkling a WARN_ON into the legacy function. We should probably move
      those into the legacy modeset helpers, too ...
      
      v2: Make it compile on arm drivers too (Noralf).
      
      v3: Correct kerneldoc to point at _disable_all().
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Acked-by: default avatarNoralf Trønnes <noralf@tronnes.org>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Noralf Trønnes <noralf@tronnes.org>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Tested-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170321164149.31531-1-daniel.vetter@ffwll.ch
      18dddadc
    • Noralf Trønnes's avatar
      drm/tinydrm: Fix drm_driver.fops.owner · 79b85d2b
      Noralf Trønnes authored
      drm_driver.fops can't be shared since the owner then becomes tinydrm.ko.
      Move the fops declaration to the driver.
      
      v2: Use DEFINE_DRM_GEM_CMA_FOPS
      Reported-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: default avatarNoralf Trønnes <noralf@tronnes.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170326142529.16938-1-noralf@tronnes.org
      79b85d2b
    • Romain Perier's avatar
      drm: dw_hdmi: Don't rely on the status of the bridge for updating HPD · 187697a4
      Romain Perier authored
      Currently, the irq handler that monitors changes for HPD and RX_SENSE
      relies on the status of the bridge for updating the status of the HPD.
      The update is done only when the bridge is enabled.
      
      However, on Rockchip platforms we have found use cases where it could be
      a problem. When HDMI is being used, turning off/on the screen or
      unplugging/re-plugging the cable, the following simplified code path
      will happen:
      
      - dw_hdmi_irq() will be triggered by an HPD event, as the bridge is on
      hdmi->disabled is false, then the handler will update the rxsense flag
      accordingly.
      - dw_hdmi_update_power() will be invoked with the mode
      DRM_FORCE_UNSPECIFIED and rxsense == 1, so dw_hdmi_poweroff() will be
      called and the PHY will be desactivated (its pixel clocks and TMDS)
      
      [...]
      
      - dw_hdmi_bridge_disable() will be invoked, the bridge will be marked as
      disabled.
      
      - dw_hdmi_irq() will be triggered by an HPD event, as the bridge is
      currently disabled the HPD status won't be updated, so hdmi->rxsense
      won't be changed. Even if the data part of the PHY is disabled, this
      information coming from the HDMI Transmitter is correct and should be
      saved.
      
      [...]
      
      - dw_hdmi_bridge_enable() will be invoked, the bridge will be marked as
      enabled.
      - dw_hdmi_update_power() will be called. When hdmi->force is equal to
      DRM_FORCE_UNSPECIFIED the function will rely on hdmi->rxsense. If this
      field has not been updated by the irq handler, it will be false and
      DRM_FORCE_ON won't be put to hdmi->force.
      
      Consequently, most of the time dw_hdmi_poweron() won't be called in this
      use case, TMDS won't be re-enabled the PHY won't be re-initialized,
      resulting in a "Signal not found".
      
      This commit fixes the issue by removing the check for "!hdmi->disabled".
      As already explained, even if the PHY is partially disabled, information
      coming from HDMI Transmitter about HPD should be saved for a later use.
      Signed-off-by: default avatarRomain Perier <romain.perier@collabora.com>
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Link: https://patchwork.freedesktop.org/patch/143602/
      187697a4
  7. 25 Mar, 2017 3 commits