1. 22 7月, 2015 1 次提交
  2. 01 7月, 2015 1 次提交
  3. 26 6月, 2015 1 次提交
  4. 25 6月, 2015 1 次提交
    • D
      drm/dp/mst: close deadlock in connector destruction. · 6b8eeca6
      Dave Airlie 提交于
      I've only seen this once, and I failed to capture the
      lockdep backtrace, but I did some investigations.
      
      If we are calling into the MST layer from EDID probing,
      we have the mode_config mutex held, if during that EDID
      probing, the MST hub goes away, then we can get a deadlock
      where the connector destruction function in the driver
      tries to retake the mode config mutex.
      
      This offloads connector destruction to a workqueue,
      and avoid the subsequenct lock ordering issue.
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      6b8eeca6
  5. 19 6月, 2015 1 次提交
  6. 05 6月, 2015 1 次提交
  7. 03 6月, 2015 1 次提交
    • D
      Add virtio gpu driver. · dc5698e8
      Dave Airlie 提交于
      This patch adds a kms driver for the virtio gpu.  The xorg modesetting
      driver can handle the device just fine, the framebuffer for fbcon is
      there too.
      
      Qemu patches for the host side are under review currently.
      
      The pci version of the device comes in two variants: with and without
      vga compatibility.  The former has a extra memory bar for the vga
      framebuffer, the later is a pure virtio device.  The only concern for
      this driver is that in the virtio-vga case we have to kick out the
      firmware framebuffer.
      
      Initial revision has only 2d support, 3d (virgl) support requires
      some more work on the qemu side and will be added later.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      dc5698e8
  8. 26 5月, 2015 4 次提交
  9. 22 5月, 2015 2 次提交
  10. 21 5月, 2015 3 次提交
    • A
      drm: bridge: Allow daisy chaining of bridges · 862e686c
      Archit Taneja 提交于
      Allow drm_bridge objects to link to each other in order to form an encoder
      chain. The requirement for creating a chain of bridges comes because the
      MSM drm driver uses up its encoder and bridge objects for blocks within
      the SoC itself. There isn't anything left to use if the SoC display output
      is connected to an external encoder IC. Having an additional bridge
      connected to the existing bridge helps here. In general, it is possible for
      platforms to have  multiple devices between the encoder and the
      connector/panel that require some sort of configuration.
      
      We create drm bridge helper functions corresponding to each op in
      'drm_bridge_funcs'. These helpers call the corresponding
      'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
      used internally by drm_atomic_helper.c and drm_crtc_helper.c.
      
      The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
      the bridge closet to the encoder, and proceed until the last bridge in the
      chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
      helpers. The drm_bridge_disable/post_disable helpers disable the last
      bridge in the chain first, and proceed until the first bridge in the chain
      is disabled.
      
      drm_bridge_attach() remains the same. As before, the driver calling this
      function should make sure it has set the links correctly. The order in
      which the bridges are connected to each other determines the order in which
      the calls are made. One requirement is that every bridge in the chain
      should point the parent encoder object. This is required since bridge
      drivers expect a valid encoder pointer in drm_bridge. For example, consider
      a chain where an encoder's output is connected to bridge1, and bridge1's
      output is connected to bridge2:
      
      	/* Like before, attach bridge to an encoder */
      	bridge1->encoder = encoder;
      	ret = drm_bridge_attach(dev, bridge1);
      	..
      
      	/*
      	 * set the first bridge's 'next' bridge to bridge2, set its encoder
      	 * as bridge1's encoder
      	 */
      	bridge1->next = bridge2
      	bridge2->encoder = bridge1->encoder;
      	ret = drm_bridge_attach(dev, bridge2);
      
      	...
      	...
      
      This method of bridge chaining isn't intrusive and existing drivers that
      use drm_bridge will behave the same way as before. The bridge helpers also
      cleans up the atomic and crtc helper files a bit.
      Reviewed-by: NJani Nikula <jani.nikula@linux.intel.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      Reviewed-by: NDaniel Vetter <daniel@ffwll.ch>
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      862e686c
    • M
      drm/atomic: add drm_atomic_add_affected_planes · e01e9f75
      Maarten Lankhorst 提交于
      This is a convenience function to add all planes for a crtc,
      similar to add_affected_connectors. This will be used in
      drm_atomic_helper_check_modeset, but drivers can call it too
      when they need to recalculate all state.
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      [danvet: Amend kerneldoc a bit.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e01e9f75
    • M
      drm/atomic: add commit_planes_on_crtc helper · de28d021
      Maarten Lankhorst 提交于
      drm_atomic_helper_commit_planes calls all atomic_begin's first,
      then updates all planes, finally calling atomic_flush.
      
      Some drivers may want to things like disabling irq's
      from their atomic_begin, in which case a second call to atomic_begin
      will splat. By using commit_planes_on_crtc on each crtc in the
      atomic state they'll evade that issue.
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      [danvet: Extend kerneldoc a bit as discussed with Maarten on irc.]
      [danvet: Squash in fixup to check for crtc_funcs in all places.
      Reported by Dan Carpenter.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      de28d021
  11. 20 5月, 2015 1 次提交
  12. 18 5月, 2015 2 次提交
  13. 13 5月, 2015 3 次提交
  14. 12 5月, 2015 1 次提交
  15. 08 5月, 2015 3 次提交
    • D
      drm/edid: Kerneldoc for newly added edid_corrupt · ac6f2e29
      Daniel Vetter 提交于
      Also treat it as a proper boolean.
      
      Cc: Todd Previte <tprevite@gmail.com>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: dri-devel@lists.freedesktop.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      ac6f2e29
    • D
      drm: Introduce blob_lock · 8fb6e7a5
      Daniel Stone 提交于
      Create a new global blob_lock mutex, which protects the blob property
      list from insertion and/or deletion.
      Signed-off-by: NDaniel Stone <daniels@collabora.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8fb6e7a5
    • T
      drm: Add edid_corrupt flag for Displayport Link CTS 4.2.2.6 · 6ba2bd3d
      Todd Previte 提交于
      Displayport compliance test 4.2.2.6 requires that a source device be capable of
      detecting a corrupt EDID. The test specification states that the sink device
      sets up the EDID with an invalid checksum. To do this, the sink sets up an
      invalid EDID header, expecting the source device to generate the checksum and
      compare it to the value stored in the last byte of the block data.
      
      Unfortunately, the DRM EDID reading and parsing functions are actually too good
      in this case; the header is fixed before the checksum is computed and thus the
      test never sees the invalid checksum. This results in a failure to pass the
      compliance test.
      
      To correct this issue, when the EDID code detects that the header is invalid,
      a flag is set to indicate that the EDID is corrupted. In this case, it sets
      edid_corrupt flag and continues with its fix-up code. This flag is also set in
      the case of a more seriously damaged header (fixup score less than the
      threshold). For consistency, the edid_corrupt flag is also set when the
      checksum is invalid as well.
      
      V2:
      - Removed the static bool global
      - Added a bool to the drm_connector struct to reaplce the static one for
        holding the status of raw edid header corruption detection
      - Modified the function signature of the is_valid function to take an
        additional parameter to store the corruption detected value
      - Fixed the other callers of the above is_valid function
      V3:
      - Updated the commit message to be more clear about what and why this
        patch does what it does.
      - Added comment in code to clarify the operations there
      - Removed compliance variable and check_link_status update; those
        have been moved to a later patch
      - Removed variable assignment from the bottom of the test handler
      V4:
      - Removed i915 tag from subject line as the patch is not i915-specific
      V5:
      - Moved code causing a compilation error to this patch where the variable
        is actually declared
      - Maintained blank lines / spacing so as to not contaminate the patch
      V6:
      - Removed extra debug messages
      - Added documentation to for the added parameter on drm_edid_block_valid
      - Fixed more whitespace issues in check_link_status
      - Added a clear of the header_corrupt flag to the end of the test handler
        in intel_dp.c
      - Changed the usage of the new function prototype in several places to use
        NULL where it is not needed by compliance testing
      V7:
      - Updated to account for long_pulse flag propagation
      V8:
      - Removed clearing of header_corrupt flag from the test handler in intel_dp.c
      - Added clearing of header_corrupt flag in the drm_edid_block_valid function
      V9:
      - Renamed header_corrupt flag to edid_corrupt to more accurately reflect its
        value and purpose
      - Updated commit message
      V10:
      - Updated for versioning and patch swizzle
      - Revised the title to more accurately reflect the nature and contents of
        the patch
      - Fixed formatting/whitespace problems
      - Added set flag when computed checksum is invalid
      Signed-off-by: NTodd Previte <tprevite@gmail.com>
      Cc: dri-devel@lists.freedesktop.org
      Acked-by: NDave Airlie <airlied@redhat.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6ba2bd3d
  16. 05 5月, 2015 3 次提交
  17. 04 5月, 2015 1 次提交
    • D
      drm/vblank: Fixup and document timestamp update/read barriers · 99264a61
      Daniel Vetter 提交于
      This was a bit too much cargo-culted, so lets make it solid:
      - vblank->count doesn't need to be an atomic, writes are always done
        under the protection of dev->vblank_time_lock. Switch to an unsigned
        long instead and update comments. Note that atomic_read is just a
        normal read of a volatile variable, so no need to audit all the
        read-side access specifically.
      
      - The barriers for the vblank counter seqlock weren't complete: The
        read-side was missing the first barrier between the counter read and
        the timestamp read, it only had a barrier between the ts and the
        counter read. We need both.
      
      - Barriers weren't properly documented. Since barriers only work if
        you have them on boths sides of the transaction it's prudent to
        reference where the other side is. To avoid duplicating the
        write-side comment 3 times extract a little store_vblank() helper.
        In that helper also assert that we do indeed hold
        dev->vblank_time_lock, since in some cases the lock is acquired a
        few functions up in the callchain.
      
      Spotted while reviewing a patch from Chris Wilson to add a fastpath to
      the vblank_wait ioctl.
      
      v2: Add comment to better explain how store_vblank works, suggested by
      Chris.
      
      v3: Peter noticed that as-is the 2nd smp_wmb is redundant with the
      implicit barrier in the spin_unlock. But that can only be proven by
      auditing all callers and my point in extracting this little helper was
      to localize all the locking into just one place. Hence I think that
      additional optimization is too risky.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Michel Dänzer <michel@daenzer.net>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-and-tested-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      99264a61
  18. 14 4月, 2015 1 次提交
  19. 13 4月, 2015 2 次提交
  20. 12 4月, 2015 1 次提交
  21. 10 4月, 2015 1 次提交
  22. 09 4月, 2015 1 次提交
  23. 08 4月, 2015 1 次提交
  24. 03 4月, 2015 2 次提交
    • P
      drm/panel: Add display timing support · 2938931f
      Philipp Zabel 提交于
      Many panel data sheets, additionally to typical values, list allowed
      ranges for timings such as hsync/vsync lengths, porches, and the pixel
      clock rate. These can be stored in a struct display_timing, to be used
      by an encoder mode_fixup callback to clamp user provided timing values
      or to validate workarounds for clock source limitations.
      
      This patch adds a new drm_panel_funcs callback that returns the panel's
      available display_timing entries.
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      2938931f
    • T
      drm/atomic: Add helpers for state-subclassing drivers · f5e7840b
      Thierry Reding 提交于
      Drivers that subclass CRTC, plane or connector state need to carefully
      duplicate the code that the atomic helpers have. This is bound to cause
      breakage eventually because it requires auditing all drivers and update
      them when code is added to the helpers.
      
      In order to avoid that, implement new helpers that perform the required
      steps when copying and destroying state. These new helpers are exported
      so that state-subclassing drivers can use them. The default helpers are
      implemented using them as well, providing a single location that needs
      to be changed when adding to base atomic states.
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NEric Anholt <eric@anholt.net>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      f5e7840b
  25. 01 4月, 2015 1 次提交