1. 23 9月, 2015 4 次提交
  2. 14 9月, 2015 2 次提交
  3. 08 9月, 2015 1 次提交
    • J
      drm/i915: initialize backlight max from VBT · aa17cdb4
      Jani Nikula 提交于
      Normally we determine the backlight PWM modulation frequency (which we
      also use as backlight max value) from the backlight registers at module
      load time, expecting the registers have been initialized by the BIOS. If
      this is not the case, we fail.
      
      The VBT contains the backlight modulation frequency in Hz. Add platform
      specific functions to convert the frequency in Hz to backlight PWM
      modulation frequency, and use them to initialize the backlight when the
      registers are not initialized by the BIOS.
      
      v2: Fix SPT and VLV. Thanks to Clint for the VLV code.
      
      Cc: Clint Taylor <clinton.a.taylor@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      aa17cdb4
  4. 02 9月, 2015 4 次提交
  5. 01 9月, 2015 2 次提交
    • V
      drm/i915: Add CHV PHY LDO power sanity checks · 30142273
      Ville Syrjälä 提交于
      At various points when changing the DPIO lane/phy power states,
      construct an expected value of the DISPLAY_PHY_STATUS register
      and compare it with the real thing.
      
      To construct the expected value we look at our shadow PHY_CONTROL
      register value (which should match what we've just written to the
      hardware), and we also need to look at the actual state of the cmn
      power wells as a disabled power well causes the relevant LDO status
      to be reported as 'on' in DISPLAY_PHY_STATUS.
      
      When initially powering up the PHY it performs various internal
      calibrations for which it fully powers up. That means that if we check
      for the expetected power state immediately upon releasing cmnreset we
      would get the occasional false positive. But we can of course
      poll until the expected value appears. It shouldn't be too long so
      this shouldn't make modesets substantially longer.
      
      One extra complication is introduced when we cross the streams, ie.
      drive port B with pipe B. In this case we trick CL2 (where the DPLL lives)
      into life by temporaily powering up the lanes in the second channel,
      and once the pipe is up and runnign we release the lane power override.
      At that point the power state of CL2 has somehow gotten entangled with
      the power state of the first channel. That means that constructing the
      expected DISPLAY_PHY_STATUS value is a bit tricky since based on the
      lane power states in the second channel, CL2 should also be powered
      down. But we can use the DPLL enable bit to determine when CL2 should
      be alive even if the lanes are powered down. However the power state
      of CL2 isn't actually tied in with the DPLL state, but to the state
      of the lanes in first channel, so we have to avoid checking the
      expected state between shutting down the DPLL and powering down
      the lanes in the first channel. So no calling assert_chv_phy_status()
      before the DISPLAY_PHY_CONTROL write in chv_phy_powergate_lanes(),
      but after the write is a safe time to check.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      30142273
    • V
      drm/i915: Add some CHV DPIO lane power state asserts · 6669e39f
      Ville Syrjälä 提交于
      Add some checks that the state of the DPIO lanes is more or less what we
      expect based on the overrides.
      
      The hardware only provides two bits per channel indicating whether all
      or some of the lanes are powered down, so we can't do an exact check.
      
      Additionally, CL2 powering down before we can check it adds another
      twist. To work around this we simply check for the 0 value of the
      CL2 register (which is what we get when it's powered down) and
      adjust our expectations.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6669e39f
  6. 26 8月, 2015 5 次提交
    • V
      drm/i915: Force CL2 off in CHV x1 PHY · 3e288786
      Ville Syrjälä 提交于
      We can choose to leave the display PHY CL2 powerdown up to some hardware
      signals, or we can force it. The BXT code forces the nonexistent CL2 in
      the x1 PHY to power down. Follow suit on CHV. Maybe it can still save
      some extra power by disabling some extra logic in CL1, or something.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3e288786
    • V
      drm/i915: Enable DPIO SUS clock gating on CHV · ee279218
      Ville Syrjälä 提交于
      CHV has supports some form of automagic clock gating for the
      DPIO SUS clock. We can simply enable the magic bits and the
      hardware should take care of the rest.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ee279218
    • V
      drm/i915: Implement PHY lane power gating for CHV · e0fce78f
      Ville Syrjälä 提交于
      Powergate the PHY lanes when they're not needed. For HDMI all four lanes
      are needed always, but for DP we can enable only the needed lanes. To
      power down the unused lanes we use some power down override bits in the
      DISPLAY_PHY_CONTROL register. Without the overrides it appears that the
      hardware always powers on all the lanes. When the port is disabled the
      power down override is not needed and the lanes will shut off on their
      own. That also means the override is critical to actually be able to
      access the DPIO registers before the port is actually enabled.
      
      Additionally the common lanes will power down when not needed. CL1
      remains on as long as anything else is on, CL2 will shut down when
      all the lanes in the same channel will shut down. There is one exception
      for CL2 that will be dealt in a separate patch for clarity.
      
      With potentially some lanes powered down, the DP code now has to check
      the number of active lanes before accessing PCS/TX registers. All
      registers in powered down blocks will reads as 0xffffffff, and soe we
      would drown in warnings from vlv_dpio_read() if we allowed the code
      to access all those registers.
      
      Another important detail in the DP code is the "TX latency optimal"
      setting. Normally the second TX lane acts as some kind of reset master,
      with the other lanes as slaves. But when only a single lane is enabled,
      that single lane obviously has to be the master.
      
      A bit of extra care is needed to reconstruct the initial state of the
      DISPLAY_PHY_CONTROL register since it can't be read safely. So instead
      read the actual lane status from the DPLL/PHY_STATUS registers and
      use that to determine which lanes ought to be powergated initially.
      
      We also need to switch the PHY power modes to "deep PSR" to avoid
      a hard system hang when powering down the single channel PHY.
      
      Also sprinkle a few debug prints around so that we can monitor the
      DISPLAY_PHY_STATUS changes without having to read it and risk
      corrupting it.
      
      v2: Add locking to chv_powergate_phy_lanes()
      v3: Actually enable dynamic powerdown in the PHY and deal with the
          fallout
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e0fce78f
    • X
      drm/i915/skl: enable DDI-E hotplug · 26951caf
      Xiong Zhang 提交于
      v2: fix one error found by checkpath.pl
      v3: Add one ignored break for switch-case. DDI-E hotplug
          function doesn't work after updating drm-intel tree,
          I checked the code and found this missing which isn't
          the root cause for broke DDI-E hp.  The broken
          DDI-E hp function is fixed by "Adding DDI_E power
          well domain".
      Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Tested-by: NTimo Aaltonen <timo.aaltonen@canonical.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      26951caf
    • A
      drm/i915: Change SRM, LRM instructions to use correct length · f1afe24f
      Arun Siluvery 提交于
      MI_STORE_REGISTER_MEM, MI_LOAD_REGISTER_MEM instructions are not really
      variable length instructions unlike MI_LOAD_REGISTER_IMM where it expects
      (reg, addr) pairs so use fixed length for these instructions.
      
      v2: rebase
      
      Cc: Dave Gordon <david.s.gordon@intel.com>
      Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      [danvet: Appease checkpatch as Mika spotted in i915_reg.h - it seems
      terminally unhappy about i915_cmd_parser.c so that would be a separate
      patch.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f1afe24f
  7. 15 8月, 2015 4 次提交
    • D
      drm/i915: Interrupt routing for GuC submission · 4df001d3
      Dave Gordon 提交于
      Turn on interrupt steering to route necessary interrupts to GuC.
      
      v6:
          Rebased
      
      Issue: VIZ-4884
      Signed-off-by: NAlex Dai <yu.dai@intel.com>
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4df001d3
    • A
      drm/i915: GuC-specific firmware loader · 33a732f4
      Alex Dai 提交于
      This fetches the required firmware image from the filesystem,
      then loads it into the GuC's memory via a dedicated DMA engine.
      
      This patch is derived from GuC loading work originally done by
      Vinit Azad and Ben Widawsky.
      
      v2:
          Various improvements per review comments by Chris Wilson
      
      v3:
          Removed 'wait' parameter to intel_guc_ucode_load() as firmware
              prefetch is no longer supported in the common firmware loader,
      	per Daniel Vetter's request.
          Firmware checker callback fn now returns errno rather than bool.
      
      v4:
          Squash uC-independent code into GuC-specifc loader [Daniel Vetter]
          Don't keep the driver working (by falling back to execlist mode)
              if GuC firmware loading fails [Daniel Vetter]
      
      v5:
          Clarify WOPCM-related #defines [Tom O'Rourke]
          Delete obsolete code no longer required with current h/w & f/w
              [Tom O'Rourke]
          Move the call to intel_guc_ucode_init() later, so that it can
              allocate GEM objects, and have it fetch the firmware; then
      	intel_guc_ucode_load() doesn't need to fetch it later.
              [Daniel Vetter].
      
      v6:
          Update comment describing intel_guc_ucode_load() [Tom O'Rourke]
      
      Issue: VIZ-4884
      Signed-off-by: NAlex Dai <yu.dai@intel.com>
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      33a732f4
    • V
      drm/i915: Move intel_dp->lane_count into pipe_config · 90a6b7b0
      Ville Syrjälä 提交于
      Currently we clobber intel_dp->lane_count in compute config, which means
      after a rejected modeset we may no longer be able to retrain the current
      link. Move lane_count into pipe_config to avoid that.
      
      v2: Add missing ':' to the pipe config debug dump
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      90a6b7b0
    • M
      drm/i915/gen8: Add 4 level switching infrastructure and lrc support · 2dba3239
      Michel Thierry 提交于
      In 64b (48bit canonical) PPGTT addressing, the PDP0 register contains
      the base address to PML4, while the other PDP registers are ignored.
      
      In LRC, the addressing mode must be specified in every context
      descriptor, and the base address to PML4 is stored in the reg state.
      
      v2: PML4 update in legacy context switch is left for historic reasons,
      the preferred mode of operation is with lrc context based submission.
      v3: s/gen8_map_page_directory/gen8_setup_page_directory and
      s/gen8_map_page_directory_pointer/gen8_setup_page_directory_pointer.
      Also, clflush will be needed for bxt. (Akash)
      v4: Squashed lrc-specific code and use a macro to set PML4 register.
      v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
      PDP update in bb_start is only for legacy 32b mode.
      v6: Rebase after final merged version of Mika's ppgtt/scratch
      patches.
      v7: There is no need to update the pml4 register value in
      execlists_update_context. (Akash)
      v8: Move pd and pdp setup functions to a previous patch, they do not
      belong here. (Akash)
      v9: Check USES_FULL_48BIT_PPGTT instead of GEN8_CTX_ADDRESSING_MODE in
      gen8_emit_bb_start to check if emit pdps is needed. (Akash)
      
      Cc: Akash Goel <akash.goel@intel.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+)
      Reviewed-by: NAkash Goel <akash.goel@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2dba3239
  8. 14 8月, 2015 1 次提交
    • P
      drm/i915: fix stolen bios_reserved checks · 3774eb50
      Paulo Zanoni 提交于
      I started digging this when I noticed that the BDW code was just
      reserving 1mb by coincidence since it was reading reserved fields.
      Then I noticed we didn't have any values set for SNB and earlier, and
      that the HSW sizes were wrong. After that, I noticed that the reserved
      area has a specific start, and may not exactly end where the stolen
      memory ends. I also noticed the base pointer can be zero. So I decided
      to just write a single patch fixing everything instead of 20 patches
      that would be much harder to review.
      
      This patch may solve random stolen memory corruption/problems on
      almost all platforms. Notice that since this is always dealing with
      the top of the stolen memory, the problems are not so easy to
      reproduce - especially since FBC is still disabled by default.
      
      One of the major differences of this patch is that we now look at both
      the size and base address. By only looking at the size we were
      assuming that the reserved area was always at the very top of
      stolen, which is not always true.
      
      After we merge the patch series that allows user space to allocate
      stolen memory we'll be able to write IGT tests that maybe catch the
      bugs fixed by this patch.
      
      v2:
        - s/BIOS reserved/stolen reserved/g (Chris)
        - Don't DRM_ERROR if we can't do anything about it (Chris)
        - Improve debug messages (Chris).
        - Use the gen7 version instead of gen6 on HSW. Tom found some
          documentation problems, so I think with gen7 we're on the safer
          side (Tom).
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3774eb50
  9. 05 8月, 2015 1 次提交
  10. 22 7月, 2015 1 次提交
  11. 15 7月, 2015 1 次提交
  12. 14 7月, 2015 1 次提交
    • P
      drm/i915: Added Programming of the MOCS · 3bbaba0c
      Peter Antoine 提交于
      This change adds the programming of the MOCS registers to the gen 9+
      platforms. The set of MOCS configuration entries introduced by this
      patch is intended to be minimal but sufficient to cover the needs of
      current userspace - i.e. a good set of defaults. It is expected to be
      extended in the future to provide further default values or to allow
      userspace to redefine its private MOCS tables based on its demand for
      additional caching configurations. In this setup, userspace should
      only utilize the first N entries, higher entries are reserved for
      future use.
      
      It creates a fixed register set that is programmed across the different
      engines so that all engines have the same table. This is done as the
      main RCS context only holds the registers for itself and the shared
      L3 values. By trying to keep the registers consistent across the
      different engines it should make the programming for the registers
      consistent.
      
      v2:
      -'static const' for private data structures and style changes.(Matt Turner)
      v3:
      - Make the tables "slightly" more readable. (Damien Lespiau)
      - Updated tables fix performance regression.
      v4:
      - Code formatting. (Chris Wilson)
      - re-privatised mocs code. (Daniel Vetter)
      v5:
      - Changed the name of a function. (Chris Wilson)
      v6:
      - re-based
      - Added Mesa table entry (skylake & broxton) (Francisco Jerez)
      - Tidied up the readability defines (Francisco Jerez)
      - NUMBER of entries defines wrong. (Jim Bish)
      - Added comments to clear up the meaning of the tables (Jim Bish)
      Signed-off-by: NPeter Antoine <peter.antoine@intel.com>
      
      v7 (Francisco Jerez):
      - Don't write L3-specific MOCS_ESC/SCC values into the e/LLC control
        tables.  Prefix L3-specific defines consistently with L3_ and
        e/LLC-specific defines with LE_ to avoid this kind of confusion in
        the future.
      - Change L3CC WT define back to RESERVED (matches my hardware
        documentation and the original patch, probably a misunderstanding
        of my own previous comment).
      - Drop Android tables, define new minimal tables more suitable for the
        open source stack.
      - Add comment that the MOCS tables are part of the kernel ABI.
      - Move intel_logical_ring_begin() and _advance() calls one level down
        (Chris Wilson).
      - Minor formatting and style fixes.
      v8 (Francisco Jerez):
      - Add table size sanity check to emit_mocs_control/l3cc_table() (Chris
        Wilson).
      - Add comment about undefined entries being implicitly set to uncached
        for forwards compatibility.
      v9 (Francisco Jerez):
      - Minor style fixes.
      Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
      Acked-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3bbaba0c
  13. 13 7月, 2015 1 次提交
  14. 06 7月, 2015 4 次提交
  15. 30 6月, 2015 3 次提交
  16. 29 6月, 2015 2 次提交
    • J
      drm/i915: fix backlight after resume on 855gm · 2059ac3b
      Jani Nikula 提交于
      Some 855gm models (at least ThinkPad X40) regressed because of
      
      commit b0cd324f
      Author: Jani Nikula <jani.nikula@intel.com>
      Date:   Wed Nov 12 16:25:43 2014 +0200
      
          drm/i915: don't save/restore backlight hist ctl registers
      
      which tried to make our driver more robust by not blindly saving and
      restoring registers, but it failed to take into account
      
      commit 0eb96d6e
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Wed Oct 14 12:33:41 2009 -0700
      
          drm/i915: save/restore BLC histogram control reg across suspend/resume
      
      Fix the regression by enabling hist ctl on gen2.
      
      v2: Improved the comment.
      
      v3: Improved the comment, again.
      Reported-and-tested-by: NPhilipp Gesang <phg@phi-gamma.net>
      References: http://mid.gmane.org/20150623222648.GD12335@acheron
      Fixes: b0cd324f ("drm/i915: don't save/restore backlight hist ctl registers")
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: stable@vger.kernel.org
      Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      2059ac3b
    • V
      drm/i915: Compute display FIFO split dynamically for CHV · 54f1b6e1
      Ville Syrjälä 提交于
      Consider which planes are active and compute the FIFO split based on the
      relative data rates. Since we only consider the pipe src width rather
      than the plane width when computing watermarks it seems best to do the
      same when computing the FIFO split as well. This means the only thing we
      actually have to consider for the FIFO splut is the bpp, and we can
      ignore the rest.
      
      I've just stuffed the logic into the watermark code for now. Eventually
      it'll need to move into the atomic update for the crtc.
      
      There's also one extra complication I've not yet considered; Some of the
      DSPARB registers contain bits related to multiple pipes. The registers
      are double buffered but apparently they update on the vblank of any
      active pipe. So doing the FIFO reconfiguration properly when multiple
      pipes are active is not going to be fun. But let's ignore that mess for
      now.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      54f1b6e1
  17. 27 6月, 2015 1 次提交
  18. 24 6月, 2015 1 次提交
  19. 23 6月, 2015 1 次提交