1. 16 8月, 2016 1 次提交
    • D
      drm: Extract drm_framebuffer.[hc] · 7520a277
      Daniel Vetter 提交于
      Also start with drm_modeset.h with the core bits, since we need
      to untangle this mess somehow. That allows us to move the drm_modes.h
      include to the right spot, except for the temporary connector status
      enum. That will get fixed as soon as drm_connector.h exists.
      
      v2: Rebase.
      
      v3: Move drm_crtc_force_disable_all back again, that wasn't meant to
      be moved (Sean).
      
      v4: Rebase.
      
      Cc: Sean Paul <seanpaul@chromium.org>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7520a277
  2. 29 7月, 2016 1 次提交
    • M
      drm: add generic zpos property · 44d1240d
      Marek Szyprowski 提交于
      version 8:
      - move drm_blend.o from drm-y to drm_kms_helper-y to avoid
        EXPORT_SYMBOL(drm_atomic_helper_normalize_zpos)
      - remove dead function declarations in drm_crtc.h
      
      version 7:
      - remove useless EXPORT_SYMBOL()
      - better z-order wording in Documentation
      
      version 6:
      - add zpos in gpu documentation file
      - merge Ville patch about zpos initial value and API improvement.
        I have split Ville patch between zpos core and drivers
      
      version 5:
      - remove zpos range check and comeback to 0 to N-1
        normalization algorithm
      
      version 4:
      - make sure that normalized zpos value is stay
        in the defined property range and warn user if not
      
      This patch adds support for generic plane's zpos property property with
      well-defined semantics:
      - added zpos properties to plane and plane state structures
      - added helpers for normalizing zpos properties of given set of planes
      - well defined semantics: planes are sorted by zpos values and then plane
        id value if zpos equals
      
      Normalized zpos values are calculated automatically when generic
      muttable zpos property has been initialized. Drivers can simply use
      plane_state->normalized_zpos in their atomic_check and/or plane_update
      callbacks without any additional calls to DRM core.
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      
      Compare to Marek's original patch zpos property is now specific to each
      plane and no more to the core.
      Normalize function take care of the range of per plane defined range
      before set normalized_zpos.
      Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Cc: Joonyoung Shim <jy0922.shim@samsung.com>
      Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: vincent.abriou@st.com
      Cc: fabien.dessenne@st.com
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      44d1240d
  3. 14 7月, 2016 1 次提交
    • D
      Revert "drm: Resurrect atomic rmfb code" · 0dcac500
      Daniel Vetter 提交于
      This reverts commit 11c21e73.
      
      For reasons totally unclear this manages to wreak havoc with the audio
      rpm refcount:
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 215 at drivers/gpu/drm/i915/intel_runtime_pm.c:1729 intel_display_power_put+0xe8/0x100 [i915]
      Use count on domain AUDIO is already zero
      Modules linked in: i915 ax88179_178a usbnet mii snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec x86_pkg_temp_thermal snd_hwdep intel_powerclamp snd_hda_core co
      f_pclmul crc32_pclmul snd_pcm ghash_clmulni_intel mei_me mei e1000e ptp pps_core i2c_hid [last unloaded: i915]
      CPU: 0 PID: 215 Comm: kworker/0:2 Not tainted 4.7.0-rc6+ #44
      Hardware name: Intel Corporation Skylake Client platform/Skylake Halo DDR4 RVP11, BIOS SKLSE2R1.R00.X106.B00.1601180206 01/18/2016
      Workqueue: events output_poll_execute
       0000000000000000 ffff88045573fa38 ffffffff813a2d6b ffff88045573fa88
       0000000000000000 ffff88045573fa78 ffffffff81075db6 000006c15a590000
       ffff88045a59a238 ffff88045a590054 ffff88045a590000 ffff88045a590000
      Call Trace:
       [<ffffffff813a2d6b>] dump_stack+0x4d/0x72
       [<ffffffff81075db6>] __warn+0xc6/0xe0
       [<ffffffff81075e1a>] warn_slowpath_fmt+0x4a/0x50
       [<ffffffffa046399d>] ? hsw_audio_codec_disable+0xdd/0x110 [i915]
       [<ffffffffa041e638>] intel_display_power_put+0xe8/0x100 [i915]
       [<ffffffffa049d776>] intel_disable_ddi+0x46/0x80 [i915]
       [<ffffffffa0474eef>] haswell_crtc_disable+0x16f/0x290 [i915]
       [<ffffffffa047cb53>] intel_atomic_commit_tail+0x153/0x10e0 [i915]
       [<ffffffff814aa020>] ? drm_atomic_helper_swap_state+0x140/0x2d0
       [<ffffffffa047dedd>] intel_atomic_commit+0x3fd/0x520 [i915]
       [<ffffffff814d0252>] ? drm_atomic_add_affected_connectors+0x22/0xf0
       [<ffffffff814cf8a2>] drm_atomic_commit+0x32/0x50
       [<ffffffff814aed07>] restore_fbdev_mode+0x147/0x260
       [<ffffffff814b026e>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2e/0x70
       [<ffffffff814b02d8>] drm_fb_helper_set_par+0x28/0x50
       [<ffffffff814b0203>] drm_fb_helper_hotplug_event+0x143/0x180
       [<ffffffffa0498ab5>] intel_fbdev_output_poll_changed+0x15/0x20 [i915]
       [<ffffffff814a1f92>] drm_kms_helper_hotplug_event+0x22/0x30
       [<ffffffff814a2172>] output_poll_execute+0x192/0x1e0
       [<ffffffff8108cf7c>] process_one_work+0x14c/0x480
       [<ffffffff8108d4fa>] worker_thread+0x24a/0x4e0
       [<ffffffff8108d2b0>] ? process_one_work+0x480/0x480
       [<ffffffff8108d2b0>] ? process_one_work+0x480/0x480
       [<ffffffff81092904>] kthread+0xc4/0xe0
       [<ffffffff8173013f>] ret_from_fork+0x1f/0x40
       [<ffffffff81092840>] ? kthread_worker_fn+0x180/0x180
      ---[ end trace 2d440da5f0c053e4 ]---
      
      Instead of scratching heads too much while CI is down, let's revert
      before more trouble is caused.
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reported-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1468502194-17029-1-git-send-email-daniel.vetter@ffwll.ch
      0dcac500
  4. 13 7月, 2016 1 次提交
  5. 22 6月, 2016 2 次提交
  6. 22 4月, 2016 1 次提交
  7. 05 1月, 2015 1 次提交
  8. 13 3月, 2014 1 次提交
  9. 05 7月, 2013 2 次提交
  10. 01 7月, 2013 8 次提交
  11. 26 4月, 2013 1 次提交
    • B
      drm/nve0: magic up some support for GF117 · 3f196a04
      Ben Skeggs 提交于
      Seen in the wild, don't have the hardware but this hacks things up to
      treat it the same as GF119 for now.
      
      Should be relatively safe, I'd be very surprised if anything major
      changed outside of PGRAPH.  PGRAPH (3D etc) is disabled by default
      however until it's confirmed working.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      3f196a04
  12. 03 10月, 2012 2 次提交
  13. 21 12月, 2011 2 次提交
  14. 20 9月, 2011 1 次提交
  15. 23 6月, 2011 1 次提交
    • B
      drm/nvc0/gr: import and use our own fuc by default · 0411de85
      Ben Skeggs 提交于
      The ability to use NVIDIA's fuc has been retained *temporarily* in order
      to better debug any issues that may be lingering in our initial attempt
      at writing this ucode.  Once I'm fairly confident we're okay, it'll be
      removed.
      
      There's a number of things not implemented by this fuc currently, but
      most of it is sets of state that our context setup would not have used
      anyway.  No doubt we'll find out what they're for at some point, and
      implement it if required.
      
      This has been tested on 0xc0/0xc4 thus far, and from what I could tell
      it worked as well as NVIDIA's.  It's also been tested on 0xc1, but even
      with NVIDIA's fuc that chipset doesn't work correctly with nouveau yet.
      
      0xc3/0xc8/0xce should in theory be supported too, but I don't have the
      hardware to check that.
      
      There's no doubt numerous bugs to squash yet, please report any!
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      0411de85