1. 11 Aug, 2014 1 commit
    • Daniel Vetter's avatar
      drm: Add a plane->reset hook · 2a0d7cfd
      Daniel Vetter authored
      In general having this can't hurt, and the atomic helpers will need
      it to be able to reset the state objects properly. The overall idea
      is to reset in the order pixels flow, so planes -> crtcs ->
      encoders -> connectors.
      
      v2: Squash in fixup from Ville to correctly deference struct drm_plane
      instead of drm_crtc when walking the plane list. Fixes an oops in
      driver init and resume.
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2a0d7cfd
  2. 08 Aug, 2014 5 commits
    • Daniel Vetter's avatar
      drm: trylock modest locking for fbdev panics · cb597bb3
      Daniel Vetter authored
      In the fbdev code we want to do trylocks only to avoid deadlocks and
      other ugly issues. Thus far we've only grabbed the overall modeset
      lock, but that already failed to exclude a pile of potential
      concurrent operations. With proper atomic support this will be worse.
      
      So add a trylock mode to the modeset locking code which attempts all
      locks only with trylocks, if possible. We need to track this in the
      locking functions themselves and can't restrict this to drivers since
      driver-private w/w mutexes must be treated the same way.
      
      There's still the issue that other driver private locks aren't handled
      here at all, but well can't have everything. With this we will at
      least not regress, even once atomic allows lots of concurrent kms
      activity.
      
      Aside: We should move the acquire context to stack-based allocation in
      the callers to get rid of that awful WARN_ON(kmalloc_failed) control
      flow which just blows up when memory is short. But that's material for
      separate patches.
      
      v2:
      - Fix logic inversion fumble in the fb helper.
      - Add proper kerneldoc.
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      cb597bb3
    • Daniel Vetter's avatar
      drm: Move ->old_fb from crtc to plane · 3d30a59b
      Daniel Vetter authored
      Atomic implemenations for legacy ioctls must be able to drop locks.
      Which doesn't cause havoc since we only do that while constructing
      the new state, so no driver or hardware state change has happened.
      
      The only troubling bit is the fb refcounting the core does - if
      someone else has snuck in then it might potentially unref an
      outdated framebuffer. To fix that move the old_fb temporary storage
      into struct drm_plane for all ioctls, so that the atomic helpers can
      update it.
      
      v2: Fix up the error case handling as suggested by Matt Roper and just
      grab locks uncoditionally - there's no point in optimizing the locking
      for when userspace gets it wrong.
      
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      3d30a59b
    • Daniel Vetter's avatar
      drm: Handle legacy per-crtc locking with full acquire ctx · d059f652
      Daniel Vetter authored
      So drivers using the atomic interfaces expect that they can acquire
      additional locks internal to the driver as-needed. Examples would be
      locks to protect shared state like shared display PLLs.
      
      Unfortunately the legacy ioctls assume that all locking is fully done
      by the drm core. Now for those paths which grab all locks we already
      have to keep around an acquire context in dev->mode_config. Helper
      functions that implement legacy interfaces in terms of atomic support
      can therefore grab this acquire contexts and reuse it.
      
      The only interfaces left are the cursor and pageflip ioctls. So add
      functions to grab the crtc lock these need using an acquire context
      and preserve it for atomic drivers to reuse.
      
      v2:
      - Fixup comments&kerneldoc.
      - Drop the WARNING from modeset_lock_all_crtcs since that can be used
        in legacy paths with crtc locking.
      
      v3: Fix a type on the kerneldoc Dave spotted.
      
      Cc: Dave Airlie <airlied@redhat.com>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d059f652
    • Daniel Vetter's avatar
      drm: Move modeset_lock_all helpers to drm_modeset_lock.[hc] · a6a8bb84
      Daniel Vetter authored
      Somehow we've forgotten about this little bit of OCD.
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a6a8bb84
    • Daniel Vetter's avatar
      drm: Add drm_plane/connector_index · 10f637bf
      Daniel Vetter authored
      In the atomic state we'll have an array of states for crtcs, planes
      and connectors and need to be able to at them by their index. We
      already have a drm_crtc_index function so add the missing ones for
      planes and connectors.
      
      If it later on turns out that the list walking is too expensive we can
      add the index to the relevant modeset objects.
      
      Rob Clark doesn't like the loops too much, but we can always add an
      obj->idx parameter later on. And for now reiterating is actually safer
      since nowadays we have hotpluggable connectors (thanks to DP MST).
      
      v2: Fix embarrassing copypasta fail in kerneldoc and header
      declarations, spotted by Matt Roper.
      
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      10f637bf
  3. 06 Aug, 2014 5 commits
    • Rob Clark's avatar
      drm: idiot-proof vblank · e6ae8687
      Rob Clark authored
      After spending slightly more time than I'd care to admit debugging the
      various and presumably spectacular way things fail when you pass too low
      a value to drm_vblank_init() (thanks console-lock for not letting me see
      the carnage!), I decided it might be a good idea to add some sanity
      checking.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e6ae8687
    • Ville Syrjälä's avatar
      drm: Warn when leaking flip events on close · ddde4371
      Ville Syrjälä authored
      Warn when there are events on the file_priv->event_list just before
      file_priv gets freed. This can occur if the driver doesn't clean up
      pending page flip events in ->preclose().
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      ddde4371
    • Chris Wilson's avatar
      drm: Perform cmdline mode parsing during connector initialisation · eaf99c74
      Chris Wilson authored
      i915.ko has a custom fbdev initialisation routine that aims to preserve
      the current mode set by the BIOS, unless overruled by the user. The
      user's wishes are determined by what, if any, mode is specified on the
      command line (via the video= parameter). However, that command line mode
      is first parsed by drm_fb_helper_initial_config() which is called after
      i915.ko's custom initial_config() as a fallback method. So in order for
      us to honour it, we need to move the cmdline parser earlier. If we
      perform the connector cmdline parsing as soon as we initialise the
      connector, that cmdline mode and forced status is then available even if
      the fbdev helper is not compiled in or never called.
      
      We also then expose the cmdline user mode in the connector mode lists.
      
      v2: Rebase after connector->name upheaval.
      
      v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely
      simplifies things while at that.
      
      v4: Fix checkpatch.
      
      v5: Select FB_CMDLINE to adapt to the changed fbdev patch.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154
      Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
      Cc: dri-devel@lists.freedesktop.org
      Cc: Julia Lemire <jlemire@matrox.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      eaf99c74
    • Daniel Vetter's avatar
      video/fbdev: Always built-in video= cmdline parsing · ea6763c1
      Daniel Vetter authored
      In drm/i915 we want to get at the video= cmdline modes even when we
      don't have fbdev support enabled, so that users can always override
      the kernel's initial mode selection.
      
      But that gives us a direct depency upon the parsing code in the fbdev
      subsystem. Since it's so little code just extract these 2 functions
      and always build them in.
      
      Whiel at it fix the checkpatch fail in this code.
      
      v2: Also move fb_mode_option. Spotted by the kbuild.
      
      v3: Review from Geert:
      - Keep the old copyright notice from fb_mem.c, although I have no
      idea what exactly applies.
      - Only compile this when needed.
      
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Plagniol-Villard <plagnioj@jcrosoft.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: linux-fbdev@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      
      --
      
      I prefer if we can merge this through drm-next since we'll use it
      there in follow-up patches.
      -Daniel
      ea6763c1
    • Daniel Vetter's avatar
      drm: Don't grab an fb reference for the idr · 83f45fc3
      Daniel Vetter authored
      The current refcounting scheme is that the fb lookup idr also holds a
      reference. This works out nicely bacause thus far we've always
      explicitly cleaned up idr entries for framebuffers:
      - Userspace fbs get removed in the rmfb ioctl or when the drm file
        gets closed.
      - Kernel fbs (for fbdev emulation) get cleaned up by the driver code
        at module unload time.
      
      But now i915 also reconstructs the bios fbs for a smooth transition.
      And that fb is purely transitional and should get removed immmediately
      once all crtcs stop using it. Of course if the i915 fbdev code decides
      to reuse it as the main fbdev fb then it shouldn't be cleaned up, but
      in that case the fbdev code will grab it's own reference.
      
      The problem is now that we also want to register that takeover fb in
      the idr, so that userspace can do a smooth transition (animated maybe
      even!) itself. But currently we have no one who will clean up the idr
      reference once that fb isn't useful any more, and so essentially leak
      it.
      
      Fix this by no longer holding a full fb reference for the idr, but
      instead just have a weak reference using kref_get_unless_zero. But
      that requires us to synchronize and clean up with the idr and fb_lock
      in drm_framebuffer_free, so add that. It's a bit ugly that we have to
      unconditionally grab the fb_lock, but without that someone might creep
      through a race.
      
      This leak was caught by the fb leak check in drm_mode_config_cleanup.
      Originally the leak was introduced in
      
      commit 46f297fb
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Fri Mar 7 08:57:48 2014 -0800
      
          drm/i915: add plane_config fetching infrastructure v2
      
      Cc:  Jesse Barnes <jbarnes@virtuousgeek.org>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77511Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      83f45fc3
  4. 05 Aug, 2014 8 commits
    • Daniel Vetter's avatar
      drm: Fix race when checking for fb in the generic kms obj lookup · 168c02ec
      Daniel Vetter authored
      In my review of
      
      commit 98f75de4
      Author: Rob Clark <robdclark@gmail.com>
      Date:   Fri May 30 11:37:03 2014 -0400
      
          drm: add object property typ
      
      I asked for a check to make sure that we never leak an fb from the
      generic mode object lookup since those have completely different
      lifetime rules. Rob added it, but outside of the idr mutex, which
      means that our dereference of obj->type can already chase free'd
      memory.
      
      Somehow I didn't spot this, so fix this asap.
      
      v2: Simplify the conditionals as suggested by Chris.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      168c02ec
    • Chris Wilson's avatar
      drm: Unlink dead file_priv from list of active files first · dff01de1
      Chris Wilson authored
      In order to prevent external observers walking the list of open DRM
      files from seeing an invalid drm_file_private in the process of being
      torndown, the first operation we need to take is to unlink the
      drm_file_private from that list.
      
      	general protection fault: 0000 [#1] PREEMPT SMP
      	Modules linked in: i915 i2c_algo_bit drm_kms_helper drm lpc_ich mfd_core nls_iso8859_1 i2c_hid video hid_generic usbhid hid e1000e ahci ptp libahci pps_core
      	CPU: 3 PID: 8220 Comm: cat Not tainted 3.16.0-rc6+ #4
      	Hardware name: Intel Corporation Shark Bay Client platform/WhiteTip Mountain 1, BIOS HSWLPTU1.86C.0119.R00.1303230105 03/23/2013
      	task: ffff8800219642c0 ti: ffff880047024000 task.ti: ffff880047024000
      	RIP: 0010:[<ffffffffa0137c70>]  [<ffffffffa0137c70>] per_file_stats+0x110/0x160 [i915]
      	RSP: 0018:ffff880047027d48  EFLAGS: 00010246
      	RAX: 6b6b6b6b6b6b6b6b RBX: ffff880047027e30 RCX: 0000000000000000
      	RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff88003a05cd00
      	RBP: ffff880047027d58 R08: 0000000000000001 R09: 0000000000000000
      	R10: ffff8800219642c0 R11: 0000000000000000 R12: ffff88003a05cd00
      	R13: 0000000000000000 R14: ffff88003a05cd00 R15: ffff880047027d88
      	FS:  00007f5f73a13740(0000) GS:ffff88014e380000(0000) knlGS:0000000000000000
      	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      	CR2: 00000000023ff038 CR3: 0000000021a4b000 CR4: 00000000001407e0
      	Stack:
      	 0000000000000001 000000000000ffff ffff880047027dc8 ffffffff813438e4
      	 ffff880047027e30 ffffffffa0137b60 ffff880021a8af58 ffff880021a8f1a0
      	 ffff8800a2061fb0 ffff8800a2062048 ffff8800a2061fb0 ffff8800a1e23478
      	Call Trace:
      	 [<ffffffff813438e4>] idr_for_each+0xf4/0x180
      	 [<ffffffffa0137b60>] ? i915_gem_stolen_list_info+0x1f0/0x1f0 [i915]
      	 [<ffffffffa013a17a>] i915_gem_object_info+0x5ca/0x6a0 [i915]
      	 [<ffffffff81193ec5>] seq_read+0xf5/0x3a0
      	 [<ffffffff8116d950>] vfs_read+0x90/0x150
      	 [<ffffffff8116e509>] SyS_read+0x49/0xb0
      	 [<ffffffff815d8622>] tracesys+0xd0/0xd5
      	Code: 01 00 00 49 39 84 24 08 01 00 00 74 55 49 8b 84 24 b8 00 00 00 48 01 43 18 31 c0 5b 41 5c 5d c3 0f 1f 00 49 8b 44 24 08 4c 89 e7 <48> 8b 70 28 48 81 c6 48 80 00 00 e8 80 14 01 00 84 c0 74 bc 49
      	RIP  [<ffffffffa0137c70>] per_file_stats+0x110/0x160 [i915]
      	RSP <ffff880047027d48>
      Reported-by: default avatar"Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81712Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: "Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      dff01de1
    • Tetsuo Handa's avatar
      drm/ttm: Pass GFP flags in order to avoid deadlock. · a91576d7
      Tetsuo Handa authored
      Commit 7dc19d5a "drivers: convert shrinkers to new count/scan API" added
      deadlock warnings that ttm_page_pool_free() and ttm_dma_page_pool_free()
      are currently doing GFP_KERNEL allocation.
      
      But these functions did not get updated to receive gfp_t argument.
      This patch explicitly passes sc->gfp_mask or GFP_KERNEL to these functions,
      and removes the deadlock warning.
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: stable <stable@kernel.org> [2.6.35+]
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      a91576d7
    • Tetsuo Handa's avatar
      drm/ttm: Fix possible stack overflow by recursive shrinker calls. · 71336e01
      Tetsuo Handa authored
      While ttm_dma_pool_shrink_scan() tries to take mutex before doing GFP_KERNEL
      allocation, ttm_pool_shrink_scan() does not do it. This can result in stack
      overflow if kmalloc() in ttm_page_pool_free() triggered recursion due to
      memory pressure.
      
        shrink_slab()
        => ttm_pool_shrink_scan()
           => ttm_page_pool_free()
              => kmalloc(GFP_KERNEL)
                 => shrink_slab()
                    => ttm_pool_shrink_scan()
                       => ttm_page_pool_free()
                          => kmalloc(GFP_KERNEL)
      
      Change ttm_pool_shrink_scan() to do like ttm_dma_pool_shrink_scan() does.
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: stable <stable@kernel.org> [2.6.35+]
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      71336e01
    • Tetsuo Handa's avatar
      drm/ttm: Use mutex_trylock() to avoid deadlock inside shrinker functions. · 22e71691
      Tetsuo Handa authored
      I can observe that RHEL7 environment stalls with 100% CPU usage when a
      certain type of memory pressure is given. While the shrinker functions
      are called by shrink_slab() before the OOM killer is triggered, the stall
      lasts for many minutes.
      
      One of reasons of this stall is that
      ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan() are called and
      are blocked at mutex_lock(&_manager->lock). GFP_KERNEL allocation with
      _manager->lock held causes someone (including kswapd) to deadlock when
      these functions are called due to memory pressure. This patch changes
      "mutex_lock();" to "if (!mutex_trylock()) return ...;" in order to
      avoid deadlock.
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: stable <stable@kernel.org> [3.3+]
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      22e71691
    • Tetsuo Handa's avatar
      drm/ttm: Choose a pool to shrink correctly in ttm_dma_pool_shrink_scan(). · 46c2df68
      Tetsuo Handa authored
      We can use "unsigned int" instead of "atomic_t" by updating start_pool
      variable under _manager->lock. This patch will make it possible to avoid
      skipping when choosing a pool to shrink in round-robin style, after next
      patch changes mutex_lock(_manager->lock) to !mutex_trylock(_manager->lork).
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: stable <stable@kernel.org> [3.3+]
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      46c2df68
    • Tetsuo Handa's avatar
      drm/ttm: Fix possible division by 0 in ttm_dma_pool_shrink_scan(). · 11e504cc
      Tetsuo Handa authored
      list_empty(&_manager->pools) being false before taking _manager->lock
      does not guarantee that _manager->npools != 0 after taking _manager->lock
      because _manager->npools is updated under _manager->lock.
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: stable <stable@kernel.org> [3.3+]
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      11e504cc
    • Dave Airlie's avatar
      74cd62ea
  5. 04 Aug, 2014 21 commits
    • Dave Airlie's avatar
      drm/sti: fix warning in build. · 8bb652eb
      Dave Airlie authored
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      8bb652eb
    • Dave Airlie's avatar
      Merge branch 'drm_kms_for_next-v8' of... · 96b1b971
      Dave Airlie authored
      Merge branch 'drm_kms_for_next-v8' of git://git.linaro.org/people/benjamin.gaignard/kernel into drm-next
      
      This series of patches add the support of DRM/KMS drivers for STMicroelectronics
      chipsets stih416 and stih407.
      
      Hardware is split in two main blocks: Compositor and TVout. Each of them
      includes specific hardware IPs and the display timing are controlled by a specific
      Video Timing Generator hardware IP (VTG).
      
      Compositor is made of the follow hardware IPs:
       - GDP (Generic Display Pipeline) which is an entry point for graphic (RGB)
         buffers
       - VDP (Video Diplay Pipeline) which is an entry point for video (YUV) buffers
       - HQVDP (High Quality Video Display Processor) that supports scaling,
         deinterlacing and some miscellaneous image quality improvements.
         It fetches the Video decoded buffers from memory, processes them and pushes
         them to the Compositor through a HW dedicated bus.
       - Mixer is responsible of mixing all the entries depending of their
         respective z-order and layout
      
      TVout is divided in 3 parts:
       - HDMI to generate HDMI signals, depending of chipset version HDMI phy can
         change.
       - HDA to generate signals for HD analog TV
       - VIP to control/switch data path coming from Compositor
      
      On stih416 compositor and Tvout are on different dies so a Video Trafic Advance
      inter-die Communication mechanism (VTAC) is needed.
      
      +---------------------------------------------+   +----------------------------------------+
      | +-------------------------------+   +----+  |   |  +----+   +--------------------------+ |
      | |                               |   |    |  |   |  |    |   |  +---------+     +----+  | |
      | | +----+              +------+  |   |    |  |   |  |    |   |  | VIP     |---->|HDMI|  | |
      | | |GPD +------------->|      |  |   |    |  |   |  |    |   |  |         |     +----+  | |
      | | +----+              |Mixer |--|-->|    |  |   |  |    |---|->| switcher|             | |
      | |                     |      |  |   |    |  |   |  |    |   |  |         |     +----+  | |
      | |                     |      |  |   |    |  |   |  |    |   |  |         |---->|HDA |  | |
      | |                     +------+  |   |VTAC|========>|VTAC|   |  +---------+     +----+  | |
      | |                               |   |    |  |   |  |    |   |                          | |
      | |         Compositor            |   |    |  |   |  |    |   |           TVout          | |
      | +-------------------------------+   |    |  |   |  |    |   +--------------------------+ |
      |                      ^              |    |  |   |  |    |             ^                  |
      |                      |              |    |  |   |  |    |             |                  |
      |               +--------------+      |    |  |   |  |    |      +-------------+           |
      |               | VTG (master) |----->|    |  |   |  |    |----->| VTG (slave) |           |
      |               +--------------+      +----+  |   |  +----+      +-------------+           |
      |Digital die                                  |   |                              Analog Die|
      +---------------------------------------------+   +----------------------------------------+
      
      On stih407 Compositor and Tvout are on the same die
      
      +-----------------------------------------------------------------+
      | +-------------------------------+  +--------------------------+ |
      | |                               |  |  +---------+     +----+  | |
      | | +----+              +------+  |  |  | VIP     |---->|HDMI|  | |
      | | |GPD +------------->|      |  |  |  |         |     +----+  | |
      | | +----+              |Mixer |--|--|->| switcher|             | |
      | | +----+   +-----+    |      |  |  |  |         |     +----+  | |
      | | |VDP +-->+HQVDP+--->|      |  |  |  |         |---->|HDA |  | |
      | | +----+   +-----+    +------+  |  |  +---------+     +----+  | |
      | |                               |  |                          | |
      | |         Compositor            |  |           TVout          | |
      | +-------------------------------+  +--------------------------+ |
      |                              ^        ^                         |
      |                              |        |                         |
      |                           +--------------+                      |
      |                           |     VTG      |                      |
      |                           +--------------+                      |
      |Digital die                                                      |
      +-----------------------------------------------------------------+
      
      In addition of the drivers for the IPs listed before a thin I2C driver (hdmiddc) is used
      by HDMI driver to retrieve EDID for monitor.
      
      To unify interfaces of GDP and VDP we create a "layer" interface called by
      compositor to control both GPD and VDP.
      
      Hardware have memory contraints (alignment, contiguous) so we use CMA drm helpers functions
      to allocate frame buffer.
      
      File naming convention is:
       - sti_* for IPs drivers
       - sti_drm_* for drm functions implementation.
      
      * 'drm_kms_for_next-v8' of git://git.linaro.org/people/benjamin.gaignard/kernel:
        drm: sti: Add DRM driver itself
        drm: sti: add Compositor
        drm: sti: add Mixer
        drm: sti: add VID layer
        drm: sti: add GDP layer
        drm: sti: add TVOut driver
        drm: sti: add HDA driver
        drm: sti: add HDMI driver
        drm: sti: add VTAC drivers
        drm: sti: add VTG driver
        drm: sti: add bindings for DRM driver
      96b1b971
    • Dave Airlie's avatar
      Merge branch 'tda998x-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-next · 920f9464
      Dave Airlie authored
      This builds upon the previous set of fixes which were pulled on 6th July.
      Included in this set are:
      - an update from Jean-Francois to add the missing reg documentation entry
        to the device tree documentation.
      - conversion of the tda998x driver to the component helpers.
      
      * 'tda998x-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox:
        drm/i2c: tda998x: add component support
        drm/i2c: tda998x: allow re-use of tda998x support code
        drm/i2c: tda998x: fix lack of required reg in DT documentation
      
      Conflicts:
      	drivers/gpu/drm/i2c/tda998x_drv.c
      920f9464
    • Dave Airlie's avatar
      Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next · eceb55a0
      Dave Airlie authored
      This time around we have a mix of new hw enablement (mdp5 v1.3 /
      apq8084), plus devicetree and various upstream changes (mostly
      adapting to CCF vs downstream clk driver differences) for mdp4 /
      apq8064.  With these drm/msm patches plus a few other small patchsets
      (from linaro qcom integration branch.. mostly stuff queued up for
      3.17) we have the inforce ifc6410 board working, with gpu.  Much nicer
      to work with than ancient vendor android branch :-)
      
      * 'msm-next' of git://people.freedesktop.org/~robclark/linux:
        drm/msm/hdmi: fix HDMI_MUX_EN gpio request typo
        drm/msm/hdmi: enable lpm-mux if it is present
        drm/msm/mdp5: add support for MDP5 v1.3
        drm/msm: fix potential deadlock in gpu init
        drm/msm: use upstream iommu
        drm/msm: no mmu is only error if not using vram carveout
        drm/msm: fix BUG_ON() in error cleanup path
        drm/msm/mdp4: add mdp axi clk
        drm/msm: hdmi phy 8960 phy pll
        drm/msm: update generated headers
        drm/msm: DT support for 8960/8064 (v3)
        drm/msm: Implement msm drm fb_mmap callback function
        drm/msm: activate iommu support
        drm/msm: fix double struct_mutex acquire
      eceb55a0
    • Dave Airlie's avatar
      Merge tag 'v3.16' into drm-next · 5d42f82a
      Dave Airlie authored
      Linux 3.16
      
      backmerge requested by i915, nouveau and radeon authors
      
      Conflicts:
      	drivers/gpu/drm/i915/i915_gem_render_state.c
      	drivers/gpu/drm/i915/intel_drv.h
      5d42f82a
    • Beeresh Gopal's avatar
      drm/msm/hdmi: fix HDMI_MUX_EN gpio request typo · a2fe6cdc
      Beeresh Gopal authored
      HDMI_MUX_EN gpio is requested. If an error occurs, the same name
      should be printed (HDMI_MUX_EN) instead of HDMI_MUX_SEL (typo).
      Signed-off-by: default avatarBeeresh Gopal <gbeeresh@codeaurora.org>
      Signed-off-by: default avatarStephane Viau <sviau@codeaurora.org>
      Reviewed-by: default avatarAndreas Färber <afaerber@suse.de>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      a2fe6cdc
    • Beeresh Gopal's avatar
      drm/msm/hdmi: enable lpm-mux if it is present · 1930f38a
      Beeresh Gopal authored
      lpm-mux is programmed to enable HDMI connector
      on the docking station for S805 chipset based
      devices.
      Signed-off-by: default avatarBeeresh Gopal <gbeeresh@codeaurora.org>
      Signed-off-by: default avatarStephane Viau <sviau@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      1930f38a
    • Stephane Viau's avatar
      drm/msm/mdp5: add support for MDP5 v1.3 · 3d47fd47
      Stephane Viau authored
      MDP5 has several functional blocks (ie: VIG/RGB pipes, LMs, ...).
      From one revision to another, these blocks' base addresses might
      change due to the number of instances present in the MDP5 hw.
      A way of dealing with these offset changes is to introduce
      dynamic offsets 'per block'.
      
      This change adds support for the new revision of MDP5: v1.3.
      The idea is to define one hw config per MDP version and select
      either one of them at runtime, after reading the MDP5 version.
      
      Once the MDP version is known, 'per block' dynamic offsets
      are initialized through a global pointer, which is then used for
      read/write register access.
      Signed-off-by: default avatarStephane Viau <sviau@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      3d47fd47
    • Rob Clark's avatar
      drm/msm: fix potential deadlock in gpu init · a1ad3523
      Rob Clark authored
      Somewhere along the way, the firmware loader sprouted another lock
      dependency, resulting in possible deadlock scenario:
      
       &dev->struct_mutex --> &sb->s_type->i_mutex_key#2 --> &mm->mmap_sem
      
      which is problematic vs things like gem mmap.
      
      So introduce a separate mutex to synchronize gpu init.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      a1ad3523
    • Rob Clark's avatar
      drm/msm: use upstream iommu · 944fc36c
      Rob Clark authored
      Downstream kernel IOMMU had a non-standard way of dealing with multiple
      devices and multiple ports/contexts.  We don't need that on upstream
      kernel, so rip out the crazy.
      
      Note that we have to move the pinning of the ringbuffer to after the
      IOMMU is attached.  No idea how that managed to work properly on the
      downstream kernel.
      
      For now, I am leaving the IOMMU port name stuff in place, to simplify
      things for folks trying to backport latest drm/msm to device kernels.
      Once we no longer have to care about pre-DT kernels, we can drop this
      and instead backport upstream IOMMU driver.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      944fc36c
    • Rob Clark's avatar
      1c4997fe
    • Rob Clark's avatar
      drm/msm: fix BUG_ON() in error cleanup path · 036c1708
      Rob Clark authored
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      036c1708
    • Rob Clark's avatar
      drm/msm/mdp4: add mdp axi clk · e8abb5b5
      Rob Clark authored
      Downstream kernel holds this clk via a fake-parent relationship.
      Upstream clock framework requires that we hold it explicitly.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      e8abb5b5
    • Rob Clark's avatar
      drm/msm: hdmi phy 8960 phy pll · 034fbcc3
      Rob Clark authored
      On downstream kernel the clk driver directly bangs hdmi phy registers.
      For upstream kernel, we need to model this as a clock and register with
      the clock framework.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      034fbcc3
    • Rob Clark's avatar
      drm/msm: update generated headers · 89301471
      Rob Clark authored
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      89301471
    • Rob Clark's avatar
      drm/msm: DT support for 8960/8064 (v3) · 41e69778
      Rob Clark authored
      Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
      add necessary DT support so that we can use drm/msm on upstream kernel.
      
      v2: update for review comments
      v3: rebase on component helper changes
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      41e69778
    • Hai Li's avatar
      drm/msm: Implement msm drm fb_mmap callback function · 8f67da33
      Hai Li authored
      This change implements msm drm specific fb_mmap function for fb device
      to properly map the fb address to userspace.
      Signed-off-by: default avatarHai Li <hali@codeaurora.org>
      Signed-off-by: default avatarStephane Viau <sviau@codeaurora.org>
      Signed-off-by: Rob Clark <robdclark@gmail.com> (+ minor comment tweak)
      8f67da33
    • Stephane Viau's avatar
      drm/msm: activate iommu support · 3bf6c1ec
      Stephane Viau authored
      This changes activates the iommu support for MDP5, through the
      platform config structure.
      Signed-off-by: default avatarStephane Viau <sviau@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      3bf6c1ec
    • Rob Clark's avatar
      drm/msm: fix double struct_mutex acquire · b544021f
      Rob Clark authored
      Mutex is already grabbed in show_locked().. somehow this slipped
      through.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      b544021f
    • Dave Airlie's avatar
      Merge tag 'drm-intel-next-2014-07-25-merged' of... · c759606c
      Dave Airlie authored
      Merge tag 'drm-intel-next-2014-07-25-merged' of git://anongit.freedesktop.org/drm-intel into drm-next
      
      Final feature pull for 3.17.
      
      drm-intel-next-2014-07-25:
      - Ditch UMS support (well just the config option for now)
      - Prep work for future platforms (Sonika Jindal, Damien)
      - runtime pm/soix fixes (Paulo, Jesse)
      - psr tracking improvements, locking fixes, now enabled by default!
      - rps fixes for chv (Deepak, Ville)
      - drm core patches for rotation support (Ville, Sagar Kamble) - the i915 parts
        unfortunately didn't make it yet
      - userptr fixes (Chris)
      - minimum backlight brightness (Jani), acked long ago by Matthew Garret on irc -
        I've forgotten about this patch :(
      
      QA is a bit unhappy about the DP MST stuff since it broke hpd testing a
      bit, but otherwise looks sane. I've backmerged drm-next to resolve
      conflicts with the mst stuff, which means the new tag itself doesn't
      contain the overview as usual.
      
      * tag 'drm-intel-next-2014-07-25-merged' of git://anongit.freedesktop.org/drm-intel: (75 commits)
        drm/i915/userptr: Keep spin_lock/unlock in the same block
        drm/i915: Allow overlapping userptr objects
        drm/i915: Ditch UMS config option
        drm/i915: respect the VBT minimum backlight brightness
        drm/i915: extract backlight minimum brightness from VBT
        drm/i915: Replace HAS_PCH_SPLIT which incorrectly lets some platforms in
        drm/i915: Returning from increase/decrease of pllclock when invalid
        drm/i915: Setting legacy palette correctly for different platforms
        drm/i915: Avoid incorrect returning for some platforms
        drm/i915: Writing proper check for reading of pipe status reg
        drm/i915: Returning the right VGA control reg for platforms
        drm/i915: Allowing changing of wm latencies for valid platforms
        drm/i915: Adding HAS_GMCH_DISPLAY macro
        drm/i915: Fix possible overflow when recording semaphore states.
        drm/i915: Do not unmap object unless no other VMAs reference it
        drm/i915: remove plane/cursor/pipe assertions from intel_crtc_disable
        drm/i915: Reorder ctx unref on ppgtt cleanup
        drm/i915/error: Check the potential ctx obj's vm
        drm/i915: Fix printing proper min/min/rpe values in debugfs
        drm/i915: BDW can also detect unclaimed registers
        ...
      c759606c
    • Dave Airlie's avatar
      drm: close race in connector registration (v2) · 2ee39452
      Dave Airlie authored
      Daniel pointed out with hotplug that userspace could be trying to oops us
      as root for lols, and that to be correct we shouldn't register the object
      with the idr before we have fully set the connector object up.
      
      His proposed solution was a lot more life changing, this seemed like a simpler
      proposition to me, get the connector object id from the idr, but don't
      register the object until the drm_connector_register callback.
      
      The open question is whether the drm_mode_object_register needs a bigger lock
      than just the idr one, but I can't see why it would, but I can be locking
      challenged.
      
      v2: fix bool noreg into sane - add comment.
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      2ee39452