1. 05 5月, 2014 1 次提交
  2. 23 4月, 2014 1 次提交
  3. 22 4月, 2014 1 次提交
    • D
      drm/irq: remove cargo-culted locking from irq_install/uninstall · e090c53b
      Daniel Vetter 提交于
      The dev->struct_mutex locking in drm_irq.c only protects
      dev->irq_enabled. Which isn't really much at all and only prevents
      especially nasty ums userspace from concurrently installing the
      interrupt handling a few times. Or at least trying.
      
      There are tons of unlocked readers of dev->irqs_enabled in the vblank
      wait code (and by extension also in the pageflip code since that uses
      the same vblank timestamp engine).
      
      Real modesetting drivers should ensure that nothing can go haywire
      with a sane setup teardown sequence. So we only really need this for
      the drm_control ioctl, everywhere else this will just paper over
      nastiness.
      
      Note that drm/i915 is a bit specially due to the gem+ums combination.
      So there we also need to properly protect the entervt and leavevt
      ioctls. But it's definitely saner to do everything in one go than to
      drop the lock in-between.
      
      Finally there's the gpu reset code in drm/i915. That one's just race
      (concurrent userspace calls to for vblank waits of pageflips could
      spuriously fail). So wrap it up in with a nice comment since fixing
      this is more involved.
      
      v2: Rebase and fix commit message (Thierry)
      Reviewed-by: NThierry Reding <treding@nvidia.com>
      Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e090c53b
  4. 04 4月, 2014 1 次提交
    • I
      drm/i915: move power domain init earlier during system resume · 76c4b250
      Imre Deak 提交于
      During resume the intel hda audio driver depends on the i915 driver
      reinitializing the audio power domain. Since the order of calling the
      i915 resume handler wrt. that of the audio driver is not guaranteed,
      move the power domain reinitialization step to the resume_early
      handler. This is guaranteed to run before the resume handler of any
      other driver.
      
      The power domain initialization in turn requires us to enable the i915
      pci device first, so move that part earlier too.
      
      Accordingly disabling of the i915 pci device should happen after the
      audio suspend handler ran. So move the disabling later from the i915
      resume handler to the resume_late handler.
      
      v2:
      - move intel_uncore_sanitize/early_sanitize earlier too, so they don't
        get reordered wrt. intel_power_domains_init_hw()
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76152Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NTakashi Iwai <tiwai@suse.de>
      Cc: stable@vger.kernel.org
      [danvet: Add cc: stable and loud comments that this is just a hack.]
      [danvet: Fix "Should it be static?" sparse warning reported by Wu
      Fengguang's kbuilder.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      76c4b250
  5. 02 4月, 2014 4 次提交
  6. 31 3月, 2014 1 次提交
  7. 19 3月, 2014 3 次提交
    • P
      drm/i915: rename __hsw_do_{en, dis}able_pc8 · a14cb6fc
      Paulo Zanoni 提交于
      After we removed all the intermediate abstractions, we can rename
      these functions to just hsw_{en,dis}able_pc8.
      
      v2: - Rebase.
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a14cb6fc
    • P
      drm/i915: don't get/put PC8 reference on freeze/thaw · db8384f2
      Paulo Zanoni 提交于
      We already get runtime PM references, and PC8 is now part of runtime
      PM, so this is enough.
      
      v2: - Rebase.
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      db8384f2
    • P
      drm/i915: make PC8 be part of runtime PM suspend/resume · a8a8bd54
      Paulo Zanoni 提交于
      Currently, when our driver becomes idle for i915.pc8_timeout (default:
      5s) we enable PC8, so we save some power, but not everything we can.
      Then, while PC8 is enabled, if we stay idle for more
      autosuspend_delay_ms (default: 10s) we'll enter runtime PM and put the
      graphics device in D3 state, saving even more power. The two features
      are separate things with increasing levels of power savings, but if we
      disable PC8 we'll never get into D3.
      
      While from the modularity point of view it would be nice to keep these
      features as separate, we have reasons to merge them:
       - We are not aware of anybody wanting a "PC8 without D3" environment.
       - If we keep both features as separate, we'll have to to test both
         PC8 and PC8+D3 code paths. We're already having a major pain to
         make QA do automated testing of just one thing, testing both paths
         will cost even more.
       - Only Haswell+ supports PC8, so if we want to add runtime PM support
         to, for example, IVB, we'll have to copy some code from the PC8
         feature to runtime PM, so merging both features as a single thing
         will make it easier for enabling runtime PM on other platforms.
      
      This patch only does the very basic steps required to have PC8 and
      runtime PM merged on a single feature: the next patches will take care
      of cleaning up everything.
      
      v2: - Rebase.
      v3: - Rebase.
          - Fully remove the deprecated i915 params since Daniel doesn't
            consider them as part of the ABI.
      v4: - Rebase.
          - Fix typo in the commit message.
      v5: - Rebase, again.
          - Add a huge comment explaining the different forcewake usage
            (Chris, Daniel).
          - Use open-coded forcewake functions (Daniel).
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a8a8bd54
  8. 13 3月, 2014 1 次提交
  9. 06 3月, 2014 5 次提交
  10. 03 3月, 2014 1 次提交
    • I
      drm/i915: fix pch pci device enumeration · bcdb72ac
      Imre Deak 提交于
      pci_get_class(class, from) drops the refcount for 'from', so the
      extra pci_dev_put we do on it will result in a use after free bug
      starting with the WARN below.
      
      Regression introduced in
      
      commit 6a9c4b35
      Author: Rui Guo <firemeteor@users.sourceforge.net>
      Date:   Wed Jun 19 21:10:23 2013 +0800
      
          drm/i915: Fix PCH detect with multiple ISA bridges in VM
      
      [  164.338460] WARNING: CPU: 1 PID: 2094 at include/linux/kref.h:47 klist_next+0xae/0x110()
      [  164.347731] CPU: 1 PID: 2094 Comm: modprobe Tainted: G           O 3.13.0-imre+ #354
      [  164.356468] Hardware name: Intel Corp. VALLEYVIEW B0 PLATFORM/NOTEBOOK, BIOS BYTICRB1.X64.0062.R70.1310112051 10/11/2013
      [  164.368796] Call Trace:
      [  164.371609]  [<ffffffff816a32a6>] dump_stack+0x4e/0x7a
      [  164.377447]  [<ffffffff8104f75d>] warn_slowpath_common+0x7d/0xa0
      [  164.384238]  [<ffffffff8104f83a>] warn_slowpath_null+0x1a/0x20
      [  164.390851]  [<ffffffff8169aeae>] klist_next+0xae/0x110
      [  164.396777]  [<ffffffff8130a110>] ? pci_do_find_bus+0x70/0x70
      [  164.403286]  [<ffffffff813cb4a9>] bus_find_device+0x89/0xc0
      [  164.409719]  [<ffffffff8130a373>] pci_get_dev_by_id+0x63/0xa0
      [  164.416238]  [<ffffffff8130a4e4>] pci_get_class+0x44/0x50
      [  164.422433]  [<ffffffffa034821f>] intel_dsm_detect+0x16f/0x1f0 [i915]
      [  164.429801]  [<ffffffffa03482ae>] intel_register_dsm_handler+0xe/0x10 [i915]
      [  164.437831]  [<ffffffffa02d30fe>] i915_driver_load+0xafe/0xf30 [i915]
      [  164.445126]  [<ffffffff8158a150>] ? intel_alloc_coherent+0x110/0x110
      [  164.452340]  [<ffffffffa0148c07>] drm_dev_register+0xc7/0x150 [drm]
      [  164.459462]  [<ffffffffa014b23f>] drm_get_pci_dev+0x11f/0x1f0 [drm]
      [  164.466554]  [<ffffffff816abb81>] ? _raw_spin_unlock_irqrestore+0x51/0x70
      [  164.474287]  [<ffffffffa02cf7a6>] i915_pci_probe+0x56/0x60 [i915]
      [  164.481185]  [<ffffffff8130a028>] pci_device_probe+0x78/0xf0
      [  164.487603]  [<ffffffff813cd495>] driver_probe_device+0x155/0x350
      [  164.494505]  [<ffffffff813cd74e>] __driver_attach+0x6e/0xa0
      [  164.500826]  [<ffffffff813cd6e0>] ? __device_attach+0x50/0x50
      [  164.507333]  [<ffffffff813cb2be>] bus_for_each_dev+0x6e/0xc0
      [  164.513752]  [<ffffffff813ccefe>] driver_attach+0x1e/0x20
      [  164.519870]  [<ffffffff813cc958>] bus_add_driver+0x138/0x260
      [  164.526289]  [<ffffffffa0188000>] ? 0xffffffffa0187fff
      [  164.532116]  [<ffffffff813cde78>] driver_register+0x98/0xe0
      [  164.538558]  [<ffffffffa0188000>] ? 0xffffffffa0187fff
      [  164.544389]  [<ffffffff813087b0>] __pci_register_driver+0x60/0x70
      [  164.551336]  [<ffffffffa014b37d>] drm_pci_init+0x6d/0x120 [drm]
      [  164.558040]  [<ffffffffa0188000>] ? 0xffffffffa0187fff
      [  164.563928]  [<ffffffffa018806a>] i915_init+0x6a/0x6c [i915]
      [  164.570363]  [<ffffffff810002da>] do_one_initcall+0xaa/0x160
      [  164.576783]  [<ffffffff8103b140>] ? set_memory_nx+0x40/0x50
      [  164.583100]  [<ffffffff810ce7f5>] load_module+0x1fb5/0x2550
      [  164.589410]  [<ffffffff810caab0>] ? store_uevent+0x40/0x40
      [  164.595628]  [<ffffffff810cee7d>] SyS_init_module+0xed/0x100
      [  164.602048]  [<ffffffff816b3c52>] system_call_fastpath+0x16/0x1b
      
      v2: simplify the loop further (Chris)
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Reported-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65652
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74161Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      bcdb72ac
  11. 07 2月, 2014 1 次提交
    • J
      drm/i915: Restore rps/rc6 on reset · dd0a1aa1
      Jeff McGee 提交于
      A check of rps/rc6 state after i915_reset determined that the ring
      MAX_IDLE registers were returned to their hardware defaults and that
      the GEN6_PMIMR register was set to mask all interrupts. This change
      restores those values to their pre-reset states by re-initializing
      rps/rc6 in i915_reset. A full re-initialization was opted for versus
      a targeted set of restore operations for simplicity and maintain-
      ability. Note that the re-initialization is not done for Ironlake,
      due to a past comment that it causes problems.
      
      Also updated the rps initialization sequence to preserve existing
      min/max values in the case of a re-init. We assume the values were
      validated upon being set and do not do further range checking. The
      debugfs interface for changing min/max was updated with range
      checking to ensure this condition (already present in sysfs
      interface).
      
      v2: fix rps logging to output hw_max and hw_min, not rps.max_delay
          and rps.min_delay which don't strictly represent hardware limits.
          Add igt testcase to signed-off-by section.
      
      Testcase: igt/pm_rps/reset
      Signed-off-by: NJeff McGee <jeff.mcgee@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      dd0a1aa1
  12. 05 2月, 2014 1 次提交
    • A
      drm/i915: Reorganize display pipe register accesses · a57c774a
      Antti Koskipaa 提交于
      RFCv2: Reorganize array indexing so that full offsets can be used as
      is. It makes grepping for registers in i915_reg.h much easier. Also
      move offset arrays to intel_device_info.
      
      v1: Fixed offsets for VLV, proper eDP handling
      
      v2: Fixed BCLRPAT, PIPESRC, PIPECONF and DSP* macros.
      
      v3: Added EDP pipe comment, removed redundant offset arrays for
          MSA_MISC and DDI_FUNC_CTL.
      
      v4: Rename patch and report object size increase.
      
      v5: Change location of commas, add PIPE_EDP into enum pipe
      
      v6: Insert PIPE_EDP_OFFSET into pipe offset array
      
      v7: Set I915_MAX_PIPES back to 3, change more registers accessors
          to use the new macros, get rid of _PIPE_INC and add dev_priv
          as a parameter where required by the new macros.
      
      Upcoming hardware will not have the various display pipe register
      ranges evenly spaced in memory. Change register address calculations
      into array lookups.
      
      Tested on SNB, VLV, IVB, Gen2 and HSW w/eDP.
      
      I left the UMS cruft untouched.
      
      Size differences:
         text    data     bss     dec     hex filename
       596431    4634      56  601121   92c21 i915.ko (new)
       593199    4634      56  597889   91f81 i915.ko (old)
      Signed-off-by: NAntti Koskipaa <antti.koskipaa@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a57c774a
  13. 28 1月, 2014 1 次提交
    • J
      drm/i915: move module parameters into a struct, in a new file · d330a953
      Jani Nikula 提交于
      With 20+ module parameters, I think referring to them via a struct
      improves clarity over just having a bunch of globals. While at it, move
      the parameter initialization and definitions into a new file
      i915_params.c to reduce clutter in i915_drv.c.
      
      Apart from the ill-named i915_enable_rc6, i915_enable_fbc and
      i915_enable_ppgtt parameters, for which we lose the "i915_" prefix
      internally, the module parameters now look the same both on the kernel
      command line and in code. For example, "i915.modeset".
      
      The downsides of the change are losing static on a couple of variables
      and not having the initialization and module_param_named() right next to
      each other. On the other hand, all module parameters are now defined in
      one place at i915_params.c. Plus you can do this to find all module
      parameter references:
      
      $ git grep "i915\." -- drivers/gpu/drm/i915
      
      v2:
      - move the definitions into a new file
      - s/i915_params/i915/
      - make i915_try_reset i915.reset, for consistency
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d330a953
  14. 25 1月, 2014 2 次提交
  15. 22 1月, 2014 3 次提交
  16. 18 12月, 2013 2 次提交
    • B
      drm/i915: Use multiple VMs -- the point of no return · 7e0d96bc
      Ben Widawsky 提交于
      As with processes which run on the CPU, the goal of multiple VMs is to
      provide process isolation. Specific to GEN, there is also the ability to
      map more objects per process (2GB each instead of 2Gb-2k total).
      
      For the most part, all the pipes have been laid, and all we need to do
      is remove asserts and actually start changing address spaces with the
      context switch. Since prior to this we've converted the setting of the
      page tables to a streamed version, this is quite easy.
      
      One important thing to point out (since it'd been hotly contested) is
      that with this patch, every context created will have it's own address
      space (provided the HW can do it).
      
      v2: Disable BDW on rebase
      
      NOTE: I tried to make this commit as small as possible. I needed one
      place where I could "turn everything on" and that is here. It could be
      split into finer commits, but I didn't really see much point.
      
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7e0d96bc
    • D
      drm: kill DRIVER_REQUIRE_AGP · 24986ee0
      Daniel Vetter 提交于
      Only the two intel drivers need this and they can easily check for
      working agp support in their driver ->load callbacks.
      
      This is the only reason why agp initialization could fail, so allows
      us to rip out a bit of error handling code in the next patch.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      24986ee0
  17. 17 12月, 2013 1 次提交
  18. 14 12月, 2013 2 次提交
  19. 12 12月, 2013 1 次提交
  20. 11 12月, 2013 2 次提交
    • P
      drm/i915: do adapter power state notification at runtime PM · cd2e9e90
      Paulo Zanoni 提交于
      Now that we are actually setting the device to the D3 state, we should
      issue the notification.
      
      The opregion spec says we should send the message before the adapter
      is about to be placed in a lower power state, and after the adapter is
      placed in a higher power state.
      
      Jani originally wrote a similar patch for PC8, but then we discovered
      that we were not really changing the PCI D states when
      enabling/disabling PC8, so we had to postpone his patch.
      
      v2: - Improve commit message, explaining the expected state.
      
      v3: - Rebase.
      
      Cc: Jani Nikula <jani.nikula@intel.com>
      Credits-to: Jani Nikula <jani.nikula@intel.com>
      Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2)
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      cd2e9e90
    • P
      drm/i915: add initial Runtime PM functions · 8a187455
      Paulo Zanoni 提交于
      This patch adds the initial infrastructure to allow a Runtime PM
      implementation that sets the device to its D3 state. The patch just
      adds the necessary callbacks and the initial infrastructure.
      
      We still don't have any platform that actually uses this
      infrastructure, we still don't call get/put in all the places we need
      to, and we don't have any function to save/restore the state of the
      registers. This is not a problem since no platform uses the code added
      by this patch. We have a few people simultaneously working on runtime
      PM, so this initial code could help everybody make their plans.
      
      V2: - Move some functions to intel_pm.c
          - Remove useless pm_runtime_allow() call at init
          - Remove useless pm_runtime_mark_last_busy() call at get
          - Use pm_runtime_get_sync() instead of 2 calls
          - Add a WARN to check if we're really awake
      
      V3: - Rebase.
      
      V4: - Don't need to call pci_{save,restore}_state and
            pci_set_power_sate, since they're already called by the PCI
            layer
          - Remove wrong pm_runtime_enable() call at init_runtime_pm
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8a187455
  21. 04 12月, 2013 1 次提交
    • C
      drm/i915: Do not clobber config status after a forced restore of hw state · edd5b133
      Chris Wilson 提交于
      We call intel_modeset_setup_hw_state() along two paths, driver
      load/resume and after a lid event notification. During initialisation of
      the driver, it is imperative that we reset the config state. This
      correctly sets up the initial connector statuses and prepares the
      hardware for a thorough probing. However, during a lid event, we only
      want to undo the damage caused by the bios by resetting our last known
      mode. In this cirumstance, we do not want to clobber our desired state.
      
      In order to try and keep sanity between the config state and our own
      tracking, do the drm_mode_config_reset() first along the load/resume
      paths before reading out the hw state and apply any definite known
      corrections.
      
      v2: "As discussed on irc I don't think we should force the connector
      state to anything here: Imo connector->status should reflect what we
      believe to be the true output connection state, whereas connector->encoder
      reflects whether this connector is wired up to a pipe. And since we no
      longer reject modeset on disconnected connectors and never nuked the pipe
      if the connector gets disconnected there's no reason for that - such policy
      is userspace's job.
      
      This regression has been introduced in
      
      commit 2e938892
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Oct 11 20:08:24 2012 +0200
      
          drm/i915/crt: explicitly set up HOTPLUG_BITS on resume"
      so sayeth Daniel.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: stable@vger.kernel.org (v3.8 and later)
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      edd5b133
  22. 27 11月, 2013 1 次提交
  23. 26 11月, 2013 1 次提交
  24. 25 11月, 2013 1 次提交
  25. 21 11月, 2013 1 次提交