1. 05 12月, 2014 1 次提交
  2. 21 11月, 2014 2 次提交
  3. 20 11月, 2014 7 次提交
  4. 19 11月, 2014 2 次提交
    • I
      drm/i915: sanitize rps irq disabling · d4d70aa5
      Imre Deak 提交于
      When disabling the RPS interrupts there is a tricky dependency between
      the thread disabling the interrupts, the RPS interrupt handler and the
      corresponding RPS work. The RPS work can reenable the interrupts, so
      there is no straightforward order in the disabling thread to (1) make
      sure that any RPS work is flushed and to (2) disable all RPS
      interrupts. Currently this is solved by masking the interrupts using two
      separate mask registers (first level display IMR and PM IMR) and doing
      the disabling when all first level interrupts are disabled.
      
      This works, but the requirement to run with all first level interrupts
      disabled is unnecessary making the suspend / unload time ordering of RPS
      disabling wrt. other unitialization steps difficult and error prone.
      Removing this restriction allows us to disable RPS early during suspend
      / unload and forget about it for the rest of the sequence. By adding a
      more explicit method for avoiding the above race, it also becomes easier
      to prove its correctness. Finally currently we can hit the WARN in
      snb_update_pm_irq(), when a final RPS work runs with the first level
      interrupts already disabled. This won't lead to any problem (due to the
      separate interrupt masks), but with the change in this and the next
      patch we can get rid of the WARN, while leaving it in place for other
      scenarios.
      
      To address the above points, add a new RPS interrupts_enabled flag and
      use this during RPS disabling to avoid requeuing the RPS work and
      reenabling of the RPS interrupts. Since the interrupt disabling happens
      now in intel_suspend_gt_powersave(), we will disable RPS interrupts
      explicitly during suspend (and not just through the first level mask),
      but there is no problem doing so, it's also more consistent and allows
      us to unify more of the RPS disabling during suspend and unload time in
      the next patch.
      
      v2/v3:
      - rebase on patch "drm/i915: move rps irq disable one level up" in the
        patchset
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d4d70aa5
    • T
      drm/i915: Extend pcode mailbox interface · 151a49d0
      Tom O'Rourke 提交于
      In sandybridge_pcode_read and sandybridge_pcode_write,
      extend the mbox parameter from u8 to u32.
      
      On Haswell and Sandybridge, bits 7:0 encode the mailbox
      command and bits 28:8 are used for address control for
      specific commands.
      
      Based on suggestion from Ville Syrjälä.
      Signed-off-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      151a49d0
  5. 14 11月, 2014 5 次提交
    • S
      drm/i915/skl: Define shared DPLLs for Skylake · d1a2dc78
      Satheeshakrishna M 提交于
      On skylake, DPLL 1, 2 and 3 can be used for DP and HDMI. The shared dpll
      framework allows us to share those DPLLs among DDIs when possible.
      
      The most tricky part is to provide a DPLL state that can be easily
      compared. DPLL_CRTL1 is shared by all the DPLLs, 6 bits each. The
      per-dpll crtl1 field of the hw state is then normalized to be the same
      value if 2 DPLLs do indeed have identical values for those 6 bits.
      
      v2: Port the code to the shared DPLL infrastructure (Damien)
      
      v3: Rebase on top of Ander's clock computation staging work for atomic (Damien)
      
      Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v2)
      Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v1)
      Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d1a2dc78
    • S
      drm/i915/skl: Structure/enum definitions for SKL clocks · 429d47d5
      Satheeshakrishna M 提交于
      Adding structure/enum for SKL clocking implementation.
      
      v2: Addressed Damien's comment
      	- Removed internal structure from this header file
      
      v3: Stove this into the generic intel_dpll_id enum and give them the established
      DPLL_ID_ prefixes. (Daniel)
      
      v4: - We'll only try to share DPLL1/2/3, leaving DPLL0 to eDP
          - Use SKL in the skylake shared DPLL names
          - Re-add the skl_dpll enum
          (Damien)
      
      v5: Remove SKL_DPLL_NONE (Daniel)
      
      v6: Modified as per review comments from Paulo
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v2)
      Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v4,v5)
      Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v3)
      Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      429d47d5
    • J
      drm/i915: don't save/restore backlight hist ctl registers · b0cd324f
      Jani Nikula 提交于
      This is not used within the driver, and merely saving/restoring these
      registers isn't going to do any good anyway. In fact, it's possible it's
      actively harmful. Any code enabling the feature should handle this
      completely in the regular platform specific enable/disable backlight
      functions.
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b0cd324f
    • V
      drm/i915: Pass the current pipe from eDP init to backlight setup · 6517d273
      Ville Syrjälä 提交于
      On VLV/CHV both pipes A and B have their own backlight control
      registers. In order to correctly read out the current hardware state at
      init we need to know which pipe is driving the eDP port. Pass that
      information down from the eDP init code into the backlight code.
      
      To determine the correct pipe we first look at which pipe is currently
      configured in the port control register, if that look invalid we look
      at which pipe's PPS is currently controlling the port, and if that
      too looks invalid we just assume pipe A.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6517d273
    • C
      drm/i915: Make the physical object coherent with GTT · 6a2c4232
      Chris Wilson 提交于
      Currently objects for which the hardware needs a contiguous physical
      address are allocated a shadow backing storage to satisfy the contraint.
      This shadow buffer is not wired into the normal obj->pages and so the
      physical object is incoherent with accesses via the GPU, GTT and CPU. By
      setting up the appropriate scatter-gather table, we can allow userspace
      to access the physical object via either a GTT mmaping of or by rendering
      into the GEM bo. However, keeping the CPU mmap of the shmemfs backing
      storage coherent with the contiguous shadow is not yet possible.
      Fortuituously, CPU mmaps of objects requiring physical addresses are not
      expected to be coherent anyway.
      
      This allows the physical constraint of the GEM object to be transparent
      to userspace and allow it to efficiently render into or update them via
      the GTT and GPU.
      
      v2: Fix leak of pci handle spotted by Ville
      v3: Remove the now duplicate call to detach_phys_object during free.
      v4: Wait for rendering before pwrite. As this patch makes it possible to
      render into the phys object, we should make it correct as well!
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6a2c4232
  6. 08 11月, 2014 18 次提交
  7. 05 11月, 2014 3 次提交
  8. 04 11月, 2014 1 次提交
  9. 24 10月, 2014 1 次提交