1. 22 Feb, 2013 5 commits
    • Thierry Reding's avatar
      drm/tegra: Add plane support · f34bc787
      Thierry Reding authored
      Add support for the B and C planes which support RGB and YUV pixel
      formats and can be used as overlays or hardware cursor. Currently 32-bit
      XRGB as well as UYVY, YUV420 and YUV422 pixel formats are advertised.
      Other formats should be easy to add but these are the most common ones
      and should cover the majority of use-cases.
      Signed-off-by: default avatarThierry Reding <thierry.reding@avionic-design.de>
      f34bc787
    • Thierry Reding's avatar
      drm/tegra: Remove bogus tegra_framebuffer structure · 894752bb
      Thierry Reding authored
      Tegra uses the CMA FB helpers so framebuffers passed to the driver need
      to use the corresponding functions to access the underlying GEM objects.
      
      This used to work because struct tegra_framebuffer was sufficiently
      similar to struct drm_fb_cma but that isn't guaranteed to stay that way.
      Signed-off-by: default avatarThierry Reding <thierry.reding@avionic-design.de>
      894752bb
    • Thierry Reding's avatar
      drm: Add consistency check for page-flipping · 8cf1e981
      Thierry Reding authored
      Driver implementations of the drm_crtc's .page_flip() function are
      required to update the crtc->fb field on success to reflect that the new
      framebuffer is now in use. This is important to keep reference counting
      on the framebuffers balanced.
      
      While at it, document this requirement to keep others from falling into
      the same trap.
      Suggested-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarThierry Reding <thierry.reding@avionic-design.de>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      8cf1e981
    • Dave Airlie's avatar
      Merge branch 'exynos-drm-next' of... · c976cb37
      Dave Airlie authored
      Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
      
      The summary:
      . Add display mode check operaion to mixer driver
        - Mixer IP also can put certain restrictions on the proposed
          display modes and these restrictions need to be considered
          during mode negotiation, which happens immediately after
          edid parsing.
      . Set correct mode for range of resolutions
        - With this patch, the mixer driver could find the correct mode
          for the range of resolutions upto 1080 vertical lines.
      . Support extra resolution for hdmi
        - This patch programs the core and timing generator registers
          using the timing data provided in drm_display_mode without
          hard-coded configurations. So this patch adds additional PHY
          configs to allow us to support more permissible resolutions
          and refresh rates.
      . Add device tree support for g2d
        - This patch adds just the compatible string for exynos5250 SoC
          so that with device tree enabling, this driver can be probed.
      . And bug fixes and code cleanups.
      
      * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
        drm/exynos: Add device tree based discovery support for G2D
        drm/exynos: hdmi: support extra resolutions using drm_display_mode timings
        drm/exynos: mixer: set correct mode for range of resolutions
        drm/exynos: implement display-mode-check callback in mixer driver
        drm/exynos: add display-mode-check operation to exynos_mixer_ops struct
        drm/exynos: release resources properly when fb creation is failed.
        drm/exynos: fix wrong pointer access at vm close.
        drm/exynos: Add missing braces around sizeof
        drm/exynos: consider exception case to fb handle creation
        drm/exynos: fix iommu address allocation order
      c976cb37
    • Patrik Jakobsson's avatar
      gma500: Fix n, m1 and m2 clock limits for sdvo and lvds · 907a773b
      Patrik Jakobsson authored
      The values of n, m1 and m2 needs to be subtracted by 2 before writing them to
      the FP register. The dot clock calculation already thinks of these values in
      register form so we must also specify them as such.
      Signed-off-by: default avatarPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      907a773b
  2. 21 Feb, 2013 10 commits
  3. 20 Feb, 2013 25 commits