1. 08 Aug, 2014 2 commits
    • Jiri Kosina's avatar
      drm/i915: read HEAD register back in init_ring_common() to enforce ordering · ece4a17d
      Jiri Kosina authored
      Withtout this, ring initialization fails reliabily during resume with
      
      	[drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head ffffff8804 tail 00000000 start 000e4000
      
      This is not a complete fix, but it is verified to make the ring
      initialization failures during resume much less likely.
      
      We were not able to root-cause this bug (likely HW-specific to Gen4 chips)
      yet. This is therefore used as a ducttape before problem is fully
      understood and proper fix created, so that people don't suffer from
      completely unusable systems in the meantime.
      
      The discussion and debugging is happening at
      
      	https://bugs.freedesktop.org/show_bug.cgi?id=76554Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ece4a17d
    • Rafael Barbalho's avatar
      drm/i915: Fix crash when failing to parse MIPI VBT · ed3b6679
      Rafael Barbalho authored
      This particular nasty presented itself while trying to register the
      intelfb device (intel_fbdev.c). During the process of registering the device
      the driver will disable the crtc via i9xx_crtc_disable. These will
      also disable the panel using the generic mipi panel functions in
      dsi_mod_vbt_generic.c. The stale MIPI generic data sequence pointers would
      cause a crash within those functions. However, all of this is happening
      while console_lock is held from do_register_framebuffer inside fbcon.c. Which
      means that you got kernel log and just the device appearing to reboot/hang for
      no apparent reason.
      
      The fault started from the FB_EVENT_FB_REGISTERED event using the
      fb_notifier_call_chain call in fbcon.c.
      
      This regression has been introduced in
      
      commit d3b542fc
      Author: Shobhit Kumar <shobhit.kumar@intel.com>
      Date:   Mon Apr 14 11:00:34 2014 +0530
      
          drm/i915: Add parsing support for new MIPI blocks in VBT
      
      Cc: Shobhit Kumar <shobhit.kumar@intel.com>
      Signed-off-by: default avatarRafael Barbalho <rafael.barbalho@intel.com>
      Reviewed-by: default avatarShobhit Kumar <shobhit.kumar@intel.com>
      [danvet: Add regression citation.]
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ed3b6679
  2. 07 Aug, 2014 17 commits
  3. 05 Aug, 2014 7 commits
  4. 04 Aug, 2014 14 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