1. 24 11月, 2015 1 次提交
  2. 16 8月, 2015 3 次提交
  3. 15 8月, 2015 1 次提交
  4. 30 7月, 2015 1 次提交
  5. 12 6月, 2015 1 次提交
    • R
      drm/msm: fix timeout calculation · 56c2da83
      Rob Clark 提交于
      The 'timeout' value comes from userspace (CLOCK_MONOTONIC), but
      converting this directly to jiffies doesn't take into account the
      initial jiffies count at boot, which may differ from the base time
      of CLOCK_MONOTONIC.
      
      TODO: add ktime_delta_jiffies() when rebasing on 4.1 and use that
      instead of ktime_sub/ktime_to_timespec/timespec_to_jiffies combo (as
      suggested by Arnd)
      
      v2: switch over from 'struct timespec' to ktime_t throughout, since
      'struct timespec' will be deprecated (as suggested by Arnd)
      v3: minor cosmetic tweaks
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      56c2da83
  6. 02 4月, 2015 1 次提交
  7. 02 2月, 2015 2 次提交
  8. 19 12月, 2014 1 次提交
  9. 18 12月, 2014 1 次提交
    • D
      drm/atomic-helper: Again check modeset *before* plane states · b4274fbe
      Daniel Vetter 提交于
      This essentially reverts
      
      commit 934ce1c2
      Author: Rob Clark <robdclark@gmail.com>
      Date:   Wed Nov 19 16:41:33 2014 -0500
      
          drm/atomic: check mode_changed *after* atomic_check
      
      Depending upon the driver both orders (or maybe even interleaving) is
      required:
      - If ->atomic_check updates ->mode_changed then helper_check_modeset
        must be run afters.
      - If ->atomic_check depends upon accurate adjusted dotclock values for
        e.g. watermarks, then helper_check_modeset must be run first.
      
      The failure mode in the first case is usually a totally angry hw
      because the pixel format switching doesn't happen. The failure mode in
      the later case is usually nothing, since in most cases the old
      adjusted mode from the previous modeset wont be too far off to be a
      problem. So just underruns and perhaps even just suboptimal (from a
      power consumption) watermarks.
      
      Furthermore in the transitional helpers we only call ->atomic_check
      after the new modeset state has been fully set up (and hence
      computed).
      
      Given that asymmetry in expected failure modes I think it's safer to
      go back to the older order. So do that and give msm a special check
      function to compensate.
      
      Also update kerneldoc to explain this a bit.
      
      v2: Actually add the missing hunk Rob spotted.
      
      v3: Move msm_atomic_check into msm_atomic.c, requested by Rob.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      Tested-by: NRob Clark <robdclark@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      b4274fbe
  10. 21 11月, 2014 1 次提交
    • R
      drm/msm/mdp5: use irqdomains · f6a8eaca
      Rob Clark 提交于
      For mdp5, the irqs of hdmi/eDP/dsi0/dsi1 blocks get routed through the
      mdp block.  In order to decouple hdmi/eDP/etc, register an irq domain
      in mdp5.  When hdmi/dsi/etc are used with mdp4, they can directly setup
      their irqs in their DT nodes as normal.  When used with mdp5, instead
      set the mdp device as the interrupt-parent, as in:
      
      	mdp: qcom,mdss_mdp@fd900000 {
      		compatible = "qcom,mdss_mdp";
      		interrupt-controller;
      		#interrupt-cells = <1>;
      		...
      	};
      
      	hdmi: qcom,hdmi_tx@fd922100 {
      		compatible = "qcom,hdmi-tx-8074";
      		interrupt-parent = <&mdp>;
      		interrupts = <8 0>;   /* MDP5_HW_INTR_STATUS.INTR_HDMI */
      		...
      	};
      
      There is a slight awkwardness, in that we cannot disable child irqs
      at the mdp level, they can only be cleared in the child block.  So
      you must not use threaded irq handlers in the child.  I'm not sure
      if there is a better way to deal with that.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      f6a8eaca
  11. 17 11月, 2014 6 次提交
  12. 30 9月, 2014 1 次提交
  13. 24 9月, 2014 1 次提交
  14. 02 6月, 2014 2 次提交
  15. 31 5月, 2014 1 次提交
  16. 31 3月, 2014 1 次提交
  17. 10 1月, 2014 4 次提交
    • R
      drm/msm: add hdmi support for apq8x74/mdp5 · dada25bd
      Rob Clark 提交于
      The HDMI block is basically the same between older SoC's with mdp4
      display controller, and newer ones with mdp5.
      
      So mostly this consists of better abstracting out the different sets of
      regulators, clks, etc.  In particular, for regulators and clks we can
      split it up by what is needed for hot plug detect to work, and what is
      needed to light up the display.
      
      Also, 8x74 has a new phy.. a very simple one, but split out into a
      different mmio space.  And with mdp5, the irq is shared with mdp, so we
      don't directly register our own irq handler.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      dada25bd
    • R
      drm/msm: split out msm_kms.h · dd2da6e3
      Rob Clark 提交于
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      dd2da6e3
    • R
      drm/msm: add support for non-IOMMU systems · 871d812a
      Rob Clark 提交于
      Add a VRAM carveout that is used for systems which do not have an IOMMU.
      
      The VRAM carveout uses CMA.  The arch code must setup a CMA pool for the
      device (preferrably in highmem.. a 256m-512m VRAM pool in lowmem is not
      cool).  The user can configure the VRAM pool size using msm.vram module
      param.
      
      Technically, the abstraction of IOMMU behind msm_mmu is not strictly
      needed, but it simplifies the GEM code a bit, and will be useful later
      when I add support for a2xx devices with GPUMMU, so I decided to keep
      this part.
      
      It appears to be possible to configure the GPU to restrict access to
      addresses within the VRAM pool, but this is not done yet.  So for now
      the GPU will refuse to load if there is no sort of mmu.  Once address
      based limits are supported and tested to confirm that we aren't giving
      the GPU access to arbitrary memory, this restriction can be lifted
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      871d812a
    • R
      drm/msm: COMPILE_TEST support · 3083894f
      Rob Clark 提交于
      With a simple stub, we can get COMPILE_TEST support.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      3083894f
  18. 02 11月, 2013 3 次提交
  19. 12 9月, 2013 1 次提交
    • R
      drm/msm: return -EBUSY if bo still active · f816f272
      Rob Clark 提交于
      When we CPU_PREP a bo with NOSYNC flag (for example, to implement
      PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE), an -EBUSY return indicates to
      userspace that the bo is still busy.  Previously it was incorrectly
      returning 0 in this case.
      
      And while we're in there throw in an bit of extra sanity checking in
      case userspace tries to wait for a bogus fence.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      f816f272
  20. 11 9月, 2013 1 次提交
    • R
      drm/msm: handle read vs write fences · bf6811f3
      Rob Clark 提交于
      The userspace API already had everything needed to handle read vs write
      synchronization.  This patch actually bothers to hook it up properly, so
      that we don't need to (for example) stall on userspace read access to a
      buffer that gpu is also still reading.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      bf6811f3
  21. 02 9月, 2013 1 次提交
  22. 25 8月, 2013 2 次提交
    • R
      drm/msm: add a3xx gpu support · 7198e6b0
      Rob Clark 提交于
      Add initial support for a3xx 3d core.
      
      So far, with hardware that I've seen to date, we can have:
       + zero, one, or two z180 2d cores
       + a3xx or a2xx 3d core, which share a common CP (the firmware
         for the CP seems to implement some different PM4 packet types
         but the basics of cmdstream submission are the same)
      
      Which means that the eventual complete "class" hierarchy, once
      support for all past and present hw is in place, becomes:
       + msm_gpu
         + adreno_gpu
           + a3xx_gpu
           + a2xx_gpu
         + z180_gpu
      
      This commit splits out the parts that will eventually be common
      between a2xx/a3xx into adreno_gpu, and the parts that are even
      common to z180 into msm_gpu.
      
      Note that there is no cmdstream validation required.  All memory access
      from the GPU is via IOMMU/MMU.  So as long as you don't map silly things
      to the GPU, there isn't much damage that the GPU can do.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      7198e6b0
    • R
      drm/msm: basic KMS driver for snapdragon · c8afe684
      Rob Clark 提交于
      The snapdragon chips have multiple different display controllers,
      depending on which chip variant/version.  (As far as I can tell, current
      devices have either MDP3 or MDP4, and upcoming devices have MDSS.)  And
      then external to the display controller are HDMI, DSI, etc. blocks which
      may be shared across devices which have different display controller
      blocks.
      
      To more easily add support for different display controller blocks, the
      display controller specific bits are split out into a "kms" module,
      which provides the kms plane/crtc/encoder objects.
      
      The external HDMI, DSI, etc. blocks are part encoder, and part connector
      currently.  But I think I will pull in the drm_bridge patches from
      chromeos tree, and split them into a bridge+connector, with the
      registers that need to be set in modeset handled by the bridge.  This
      would remove the 'msm_connector' base class.  But some things need to be
      double checked to make sure I could get the correct ON/OFF sequencing..
      
      This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
      (part of MDP4 block), and hdmi.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      c8afe684