1. 29 Nov, 2012 6 commits
    • Inki Dae's avatar
      drm/exynos: remove unnecessary code. · fa3692d1
      Inki Dae authored
      plane->fb will be set to new fb after update_plane callback is called
      by drm_mode_set_plane()
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      fa3692d1
    • Inki Dae's avatar
      drm/exynos: fix linux framebuffer address setting. · 9d934799
      Inki Dae authored
      With iommu, buffer->dma_addr has device addres so this patch
      fixes for physical address to be set to fix.smem_start always.
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      9d934799
    • Dave Airlie's avatar
      Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel into drm-next · 7136470d
      Dave Airlie authored
      Daniel writes:
      Besides the big item of lifting the "preliminary hw support" tag from the
       Haswell code, just small bits&pieces all over:
       - Leftover Haswell patches and some fixes from Paulo
       - LyncPoint PCH support (for hsw)
       - OOM handling improvements from Chris Wilson
       - connector property and send_vblank_event refactorings from Rob Clark
       - random pile of small fixes
      
       Note that the send_vblank refactorings will cause some locking WARNs to
       show up. Imre has fixed that up, but since all the driver changes outside
       of the drm core have been for exonys, those four patches are merged
       through the exonys-next tree.
      
      Meh, I've forgotten to cherry-pick an important fix from Ben for a
      regression in the 3.8 gen6+ gtt code. New pull request below. While I'm at
      it, the hdmi VIC patch for the drm edid code is still in my queue, I'll
      send you that in the next 3.8-fixes pull.
      
      * 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: (33 commits)
        drm/i915: Fix pte updates in ggtt clear range
        drm/i915: promote Haswell to full support
        drm/i915: Report the origin of the LVDS fixed panel mode
        drm/i915: LVDS fallback to fixed-mode if EDID not present
        drm/i915/sdvo: kfree the intel_sdvo_connector, not drm_connector, on destroy
        drm/i915: drm_connector_property -> drm_object_property
        drm/i915: use drm_send_vblank_event() helper
        drm/i915: Use pci_resource functions for BARs.
        drm/i915: Borrow our struct_mutex for the direct reclaim
        drm/i915: Defer assignment of obj->gtt_space until after all possible mallocs
        drm/i915: Apply the IBX transcoder A w/a for HDMI to SDVO as well
        drm/i915: implement WaMbcDriverBootEnable on Haswell
        drm/i915: fix intel_ddi_get_cdclk_freq for ULT machines
        drm/i915: make the panel fitter work on pipes B and C on Haswell
        drm/i915: make the panel fitter work on pipes B and C on IVB
        drm/i915: don't intel_crt_init if DDI A has 4 lanes
        drm/i915: make DP work on LPT-LP machines
        drm/i915: fix false positive "Unclaimed write" messages
        drm/i915: use cpu/pch transcoder on intel_enable_pipe
        drm/i915: don't limit Haswell CRT encoder to pipe A
        ...
      7136470d
    • Ben Widawsky's avatar
      drm/i915: Fix pte updates in ggtt clear range · 2ff4aeac
      Ben Widawsky authored
      This bug was introduced by me:
      commit e76e9aeb
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Sun Nov 4 09:21:27 2012 -0800
      
          drm/i915: Stop using AGP layer for GEN6+
      
      The existing code uses memset_io which follows memset semantics in only
      guaranteeing a write of individual bytes. Since a PTE entry is 4 bytes,
      this can only be correct if the scratch page address is 0.
      
      This caused unsightly errors when we clear the range at load time,
      though I'm not really sure what the heck is referencing that memory
      anyway. I caught this is because I believe we have some other bug where
      the display is doing reads of memory we feel should be cleared (or we
      are relying on scratch pages to be a specific value).
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2ff4aeac
    • Thierry Reding's avatar
      drm: tegra: Add maintainers entry · bd3b49f2
      Thierry Reding authored
      Add myself as the maintainer of the NVIDIA Tegra DRM driver.
      Signed-off-by: default avatarThierry Reding <thierry.reding@avionic-design.de>
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      bd3b49f2
    • Jingoo Han's avatar
      drm/pci: add missing variable initialization · ca062415
      Jingoo Han authored
      Fixed build warning as below:
      
      drivers/gpu/drm/drm_pci.c: In function 'drm_pcie_get_speed_cap_mask':
      drivers/gpu/drm/drm_pci.c:496:9: warning: 'lnkcap' may be used uninitialized in this function [-Wuninitialized]
      drivers/gpu/drm/drm_pci.c:497:10: warning: 'lnkcap2' may be used uninitialized in this function [-Wuninitialized]
      Signed-off-by: default avatarJingoo Han <jg1.han@samsung.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      ca062415
  2. 28 Nov, 2012 34 commits