1. 08 Dec, 2014 11 commits
    • Dave Airlie's avatar
      drm/tile: expose the tile property to userspace (v3) · 6f134d7b
      Dave Airlie authored
      This takes the tiling info from the connector and
      exposes it to userspace, as a blob object in a
      connector property.
      
      The contents of the blob is ABI.
      
      v2: add property + function documentation.
      
      v3: move property setup from previous patch.
      add boilerplate + fix long line (Daniel)
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      6f134d7b
    • Dave Airlie's avatar
      drm/connector: store tile information from displayid (v3) · 40d9b043
      Dave Airlie authored
      This creates a tile group from DisplayID block, and
      stores the pieces of parsed info from the DisplayID block
      into the connector.
      
      v2: add missing signoff, add new connector bits to docs.
      
      v3: remove some debugging.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      40d9b043
    • Dave Airlie's avatar
      drm/mst: cached EDID for logical ports (v2) · c6a0aed4
      Dave Airlie authored
      Logical ports are never going to have EDID changes,
      they are used for the internal ports on MST monitors.
      
      We cache the EDIDs from these to save time at MST probe.
      
      v2: drop misplace tile property line, meant for other patch.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      c6a0aed4
    • Dave Airlie's avatar
      drm: add tile_group support. (v3) · 138f9ebb
      Dave Airlie authored
      A tile group is an identifier shared by a single monitor,
      DisplayID topology has 8 bytes we can use for this, just
      use those for now until something else comes up in the
      future. We assign these to an idr and use the idr to
      tell userspace what connectors are in the same tile group.
      
      DisplayID v1.3 says the serial number must be unique for
      displays from the same manufacturer.
      
      v2:
      destroy idr (dvdhrm)
      add docbook (danvet)
      airlied:- not sure how to make docbook add fns to tile group section.
      
      v3: fix missing unlock.
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      138f9ebb
    • Dave Airlie's avatar
      drm/displayid: add displayid defines and edid extension (v2) · b49b55bd
      Dave Airlie authored
      These are just taken from the DisplayID v1.3 spec, and the
      DDC spec.
      
      v2: use __packed (Jani)
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      b49b55bd
    • Daniel Vetter's avatar
      drm/dp-mst: Remove branches before dropping the reference · 0391359d
      Daniel Vetter authored
      When we unplug a dp mst branch we unreference the entire tree from
      the root towards the leaves. Which is ok, since that's the way the
      pointers and so also the refcounts go.
      
      But when we drop the reference we must make sure that we remove the
      branches/ports from the lists/pointers before dropping the reference.
      Otherwise the get_validated functions will still return it instead
      of returning NULL (which indicates a potentially on-going unplug).
      
      The mst branch destroy gets this right for ports: First it deletes
      the port from the ports list, then it unrefs. But the ports destroy
      function gets it wrong: First it unrefs, then it drops the ref. Which
      means a zombie mst branch can still be validate with get_validated_mstb_ref
      when it shouldn't.
      
      Fix this.
      
      This should address a backtrace Dave dug out somewhere on unplug:
      
       [<ffffffffa00cc262>] drm_dp_mst_get_validated_mstb_ref_locked+0x92/0xa0 [drm_kms_helper]
       [<ffffffffa00cc211>] drm_dp_mst_get_validated_mstb_ref_locked+0x41/0xa0 [drm_kms_helper]
       [<ffffffffa00cc2aa>] drm_dp_get_validated_mstb_ref+0x3a/0x60 [drm_kms_helper]
       [<ffffffffa00cc2fb>] drm_dp_payload_send_msg.isra.14+0x2b/0x100 [drm_kms_helper]
       [<ffffffffa00cc547>] drm_dp_update_payload_part1+0x177/0x360 [drm_kms_helper]
       [<ffffffffa015c52e>] intel_mst_disable_dp+0x3e/0x80 [i915]
       [<ffffffffa013d60b>] haswell_crtc_disable+0x1cb/0x340 [i915]
       [<ffffffffa0136739>] intel_crtc_control+0x49/0x100 [i915]
       [<ffffffffa0136857>] intel_crtc_update_dpms+0x67/0x80 [i915]
       [<ffffffffa013fa59>] intel_connector_dpms+0x59/0x70 [i915]
       [<ffffffffa015c752>] intel_dp_destroy_mst_connector+0x32/0xc0 [i915]
       [<ffffffffa00cb44b>] drm_dp_destroy_port+0x6b/0xa0 [drm_kms_helper]
       [<ffffffffa00cb588>] drm_dp_destroy_mst_branch_device+0x108/0x130 [drm_kms_helper]
       [<ffffffffa00cb3cd>] drm_dp_port_teardown_pdt+0x3d/0x50 [drm_kms_helper]
       [<ffffffffa00cdb79>] drm_dp_mst_handle_up_req+0x499/0x540 [drm_kms_helper]
       [<ffffffff810d9ead>] ? trace_hardirqs_on_caller+0x15d/0x200 [<ffffffffa00cdc73>]
       drm_dp_mst_hpd_irq+0x53/0xa00 [drm_kms_helper] [<ffffffffa00c7dfb>]
       ? drm_dp_dpcd_read+0x1b/0x20 [drm_kms_helper] [<ffffffffa0153ed8>]
       ? intel_dp_dpcd_read_wake+0x38/0x70 [i915] [<ffffffffa015a225>]
       intel_dp_check_mst_status+0xb5/0x250 [i915] [<ffffffffa015ac71>]
       intel_dp_hpd_pulse+0x181/0x210 [i915] [<ffffffffa01104f6>]
       i915_digport_work_func+0x96/0x120 [i915]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      0391359d
    • Dave Airlie's avatar
      drm/fb_helper: move deferred fb checking into restore mode (v2) · e2809c7d
      Dave Airlie authored
      On MST systems the monitors don't appear when we set the fb up,
      but plymouth opens the drm device and holds it open while they
      come up, when plymouth finishes and lastclose gets called we
      don't do the delayed fb probe, so the monitor never appears on the
      console.
      
      Fix this by moving the delayed checking into the mode restore.
      
      v2: Daniel suggested that ->delayed_hotplug is set under
      the mode_config mutex, so we should check it under that as
      well, while we are in the area.
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      e2809c7d
    • Dave Airlie's avatar
      drm/dp: retry AUX transactions 32 times (v1.1) · 19a93f04
      Dave Airlie authored
      At least on two MST devices I've tested with, when
      they are link training downstream, they are totally
      unable to handle aux ch msgs, so they defer like nuts.
      I tried 16, it wasn't enough, 32 seems better.
      
      This fixes one Dell 4k monitor and one of the
      MST hubs.
      
      v1.1: fixup comment (Tom).
      Acked-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      19a93f04
    • Dave Airlie's avatar
      Merge branch 'drm_iommu_v15' of https://github.com/markyzq/kernel-drm-rockchip into drm-next · b75478d1
      Dave Airlie authored
      Merge rockchip GPU support.
      
      This has a branch in common with the iommu tree, hopefully the
      process works.
      
      * 'drm_iommu_v15' of https://github.com/markyzq/kernel-drm-rockchip:
        dt-bindings: video: Add documentation for rockchip vop
        dt-bindings: video: Add for rockchip display subsytem
        drm: rockchip: Add basic drm driver
        dt-bindings: iommu: Add documentation for rockchip iommu
        iommu/rockchip: rk3288 iommu driver
      b75478d1
    • Dave Airlie's avatar
      Merge branch 'amdkfd-next-3.19' of git://people.freedesktop.org/~gabbayo/linux into drm-next · b00ff043
      Dave Airlie authored
      As discussed on irc, I'm sending a pull request with one important change:
      
      - Disable support for 32-bit user processes. This is done due to AMD's decision
        to remove support for 32-bit user processes on Linux for its HSA stack.
      
      * 'amdkfd-next-3.19' of git://people.freedesktop.org/~gabbayo/linux:
        amdkfd: Disable support for 32-bit user processes
      b00ff043
    • Dave Airlie's avatar
      Merge tag 'v3.18' into drm-next · 8c863944
      Dave Airlie authored
      Linux 3.18
      
      Backmerge Linus tree into -next as we had conflicts in i915/radeon/nouveau,
      and everyone was solving them individually.
      
      * tag 'v3.18': (57 commits)
        Linux 3.18
        watchdog: s3c2410_wdt: Fix the mask bit offset for Exynos7
        uapi: fix to export linux/vm_sockets.h
        i2c: cadence: Set the hardware time-out register to maximum value
        i2c: davinci: generate STP always when NACK is received
        ahci: disable MSI on SAMSUNG 0xa800 SSD
        context_tracking: Restore previous state in schedule_user
        slab: fix nodeid bounds check for non-contiguous node IDs
        lib/genalloc.c: export devm_gen_pool_create() for modules
        mm: fix anon_vma_clone() error treatment
        mm: fix swapoff hang after page migration and fork
        fat: fix oops on corrupted vfat fs
        ipc/sem.c: fully initialize sem_array before making it visible
        drivers/input/evdev.c: don't kfree() a vmalloc address
        cxgb4: Fill in supported link mode for SFP modules
        xen-netfront: Remove BUGs on paged skb data which crosses a page boundary
        mm/vmpressure.c: fix race in vmpressure_work_fn()
        mm: frontswap: invalidate expired data on a dup-store failure
        mm: do not overwrite reserved pages counter at show_mem()
        drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6
        ...
      
      Conflicts:
      	drivers/gpu/drm/i915/intel_display.c
      	drivers/gpu/drm/nouveau/nouveau_drm.c
      	drivers/gpu/drm/radeon/radeon_cs.c
      8c863944
  2. 07 Dec, 2014 2 commits
  3. 06 Dec, 2014 2 commits
  4. 05 Dec, 2014 11 commits
  5. 04 Dec, 2014 7 commits
  6. 03 Dec, 2014 7 commits