- 05 May, 2014 40 commits
-
-
Chris Wilson authored
lib/interval_tree.c provides a simple interface for an interval-tree (an augmented red-black tree) but is only built when testing the generic macros for building interval-trees. For drivers with modest needs, export the simple interval-tree library as is. v2: Lots of help from Michel Lespinasse to only compile the code as required: - make INTERVAL_TREE a config option - make INTERVAL_TREE_TEST select the library functions and sanitize the filenames & Makefile - prepare interval_tree for being built as a module if required Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Lespinasse <walken@google.com> Cc: Rik van Riel <riel@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Reviewed-by:
Michel Lespinasse <walken@google.com> [Acked for inclusion via drm/i915 by Andrew Morton.] [danvet: switch to _GPL as per the mailing list discussion.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
I've seen latencies up to 15msec, so increase the timeout to 20msec. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
This will be needed by the VLV runtime PM helpers too, so factor it out. Also add a safety check for the case where the previous force-off is still pending, since I'm not sure if Punit can handle a new setting while the previous one hasn't settled yet. v2: - unchanged v3: - add a note to the commit message about the safety check (Ville) Signed-off-by:
-
Imre Deak authored
When enabling runtime PM on VLV, GT power save enabling becomes relatively frequent, so optimize it a bit. Signed-off-by:
-
Imre Deak authored
During runtime suspend there can be a last pending rps.work, so make sure it's canceled. Note that in the runtime suspend callback we can't get any RPS interrupts since it's called only after the GPU goes idle and we set the minimum RPS frequency. The next possibility for an RPS interrupt is only after getting an RPM ref (for example because of a new GPU command) and calling the RPM resume callback. v2: - patch introduced in v2 of the patchset v3: - Change the order of canceling the rps.work and disabling interrupts to avoid the race between interrupt disabling and the the rps.work. Race spotted by Ville. Signed-off-by:
-
Imre Deak authored
We need to re-init sizzling on all platforms so move it to the platform independent runtime resume callback. The ring frequency reinit is also needed everywhere except on VLV, but gen6_update_ring_freq() will be a noop on VLV, so we can move this function too to platform independent code. Signed-off-by:
-
Imre Deak authored
This is needed by the next patch moving the call out from platform specific RPM callbacks to platform independent code. No functional change. v2: - patch introduce in v2 of the patchset v3: - simplify platform check condition (Ville) Signed-off-by:
-
Imre Deak authored
We need to disable the interrupts for all platforms, so make the helpers for this platform independent and call them from them platform independent runtime suspend/resume callbacks. On HSW/BDW this will move interrupt disabling/re-enabling at the beginning/end of runtime suspend/resume respectively, but I don't see any reason why this would cause a problem there. In any case this seems to be the correct thing to do even on those platforms. Signed-off-by:
-
Imre Deak authored
On VLV we depend on RC6 to save the GT render and media HW context before going to the D3 state via RPM, so as a preparation for the VLV RPM support (added in an upcoming patch) disable RPM if RC6 is disabled. There is probably a similar dependency on other platforms too, so for safety require RC6 for those too. For these platforms (SNB, HSW, BDW) this is then a possible fix. v2: - require RC6 for all RPM platforms, not just for VLV (Paulo, Daniel) Signed-off-by:
-
Imre Deak authored
Atm, an invalid enable_rc6 module option will be silently ignored, so emit an info message about it. Doing an early sanitization we can also reuse intel_enable_rc6() in a follow-up patch to see if RC6 is actually enabled. Currently the caller would have to filter a non-zero return value based on the platform we are running on. For example on VLV with i915.enable_rc6 set to 2, RC6 won't be enabled but atm intel_enable_rc6() would still return 2 in this case. v2: - simplify the platform check condition (Ville) Signed-off-by:
-
Imre Deak authored
Atm, we call intel_gt_powersave_enable() for GEN6 and GEN7 but disable it for everything starting from GEN6. This is a problem in case of BDW. Since I don't have a BDW to test if RC6 works properly, just keep it disabled for now and fix only the disable function. Signed-off-by:
-
Imre Deak authored
Some platforms need additional power domains to be on in addition to the device D0 state to access the panel registers. Suggested by Daniel. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76987Signed-off-by:
-
Imre Deak authored
While checking the error capture path I noticed that we lacked the power domain-on check for PIPESTAT so fix this by moving that to where the rest of pipe registers are captured. The move also revealed that we actually don't include this register in the error report, so fix that too. v2: - patch introduced in v2 of the patchset v3: - add back !HAS_PCH_SPLIT check (Ville) [ Ignore my previous comment about the gen<=5 || vlv check, I realized that it's the same as !HAS_PCH_SPLIT. ] Signed-off-by:
-
Imre Deak authored
While checking the error capture path I noticed that this register is read twice for GEN2, so fix this and also move the read where it's done for other platforms. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Imre Deak authored
Atm we can end up in the GPU reset deferred work in D3 state if the last runtime PM reference is dropped between detecting a hang/scheduling the work and executing the work. At least one such case I could trigger is the simulated reset via the i915_wedged debugfs entry. Fix this by getting an RPM reference around accessing the HW in the reset work. v2: - Instead of getting/putting the RPM reference in the reset work itself, get it already before scheduling the work. By this we also prevent going to D3 before the work gets to run, in addition to making sure that we run the work itself in D0. (Ville, Daniel) v3: - fix inverted logic fail when putting the RPM ref on behalf of a cancelled GPU reset work (Ville) v4: - Taking the RPM ref in the interrupt handler isn't really needed b/c it's already guaranteed that we hold an RPM ref until the end of the reset work in all cases we care about. So take the ref in the reset work (for cases like i915_wedged_set). (Daniel) Signed-off-by:
-
Chris Wilson authored
Be we read and chase pointers from the VBT, it is prudent to make sure that those accesses are wholly contained within the MMIO region, or else we may cause a kernel panic during boot. Signed-off-by:
Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by:
-
Chris Wilson authored
Make sure that the whole BDB section is within the MMIO region prior to accessing it contents. That we don't read outside of the secion is left up to the individual section parsers. Signed-off-by:
-
Imre Deak authored
At least on VLV but probably on other platforms too we depend on RC6 being enabled for RPM, so disable RPM until the delayed RC6 enabling completes. v2: - explain the reason for the _noresume version of RPM get (Daniel) - use the simpler 'if (schedule_work()) rpm_get();' instead of 'if (!cancel_work_sync()) rpm_get(); schedule_work();' Signed-off-by:
-
Imre Deak authored
Getting struct_mutex around the whole intel_enable_gt_powersave() function is not necessary, since it's only needed for the ILK path therein. This will make intel_enable_gt_powersave() useable on the RPM resume path for >=GEN6 (added in an upcoming patch to reset the RPS state during RPM resume), where we can't (and need not) get this mutex. Signed-off-by:
-
Imre Deak authored
These debugfs entries access registers that need the D0 power state so get an RPM ref for them. v2: - for all these entries we only need D0 state, so get only an RPM ref, not a power domain ref (Daniel, Paulo) - the dpio entry is not an issue any more as it got removed (Ville) - restore commit message from v1 (Paulo) Signed-off-by:
-
Imre Deak authored
There are igt tools that can read/write the DPIO registers, so having a debugfs entry for only some of those registers is somewhat arbitrary / redundant. Remove it. v2: - instead of fixing the entry by taking a power domain reference around the register accesses, remove the entry (Ville) Signed-off-by:
-
Imre Deak authored
The parsing was incorrect for ILK and VLV. Signed-off-by:
-
Imre Deak authored
Signed-off-by:
-
Imre Deak authored
Not clearing this flag causes spurious interrupts at least in D3 state, so before enabling RPM we need to fix this. We were already setting this flag when enabling interrupts, only clearing it was missing. Signed-off-by:
-
Imre Deak authored
These will be needed by the upcoming VLV RPM helpers. Signed-off-by:
-
Zhao Yakui authored
The BDW GT3 has two independent BSD rings, which can be used to process the video commands. To be simpler, it is transparent to user-space driver/middle. Instead the kernel driver will decide which ring is to dispatch the BSD video command. As every BSD ring is powerful, it is enough to dispatch the BSD video command based on the drm fd. In such case it can play back video stream while encoding another video stream. The coarse ping-pong mechanism is used to determine which BSD ring is used to dispatch the BSD video command. V1->V2: Follow Daniel's comment and use the simple ping-pong mechanism. This is only to add the support of dual BSD rings on BDW GT3 machine. The further optimization will be considered in another patch set. V2->V3: Follow Daniel's comment to use the struct_mutext instead of atomic_t during determining which ring can be used to dispatch Video command. Reviewed-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
-
Zhao Yakui authored
The Gen7 doesn't have the second BSD ring. But it will complain the switch check warning message during compilation. So just add it to remove the switch check warning. V1->V2: Follow Daniel's comment to update the comment Reviewed-by:
-
Zhao Yakui authored
Reviewed-by:
-
Zhao Yakui authored
Based on the hardware spec, the BDW GT3 machine has two independent BSD ring that can be used to dispatch the video commands. So just initialize it. V3->V4: Follow Imre's comment to do some minor updates. For example: more comments are added to describe the semaphore between ring. Reviewed-by:
-
Zhao Yakui authored
Signed-off-by:
-
Zhao Yakui authored
Based on the hardware spec, the BDW GT3 has the different configuration with the BDW GT1/GT2. So split the BDW device info definition. This is to do the preparation for adding the Dual BSD rings on BDW GT3 machine. V1->V2: Follow Daniel's comment to pay attention to the stolen check for BDW in kernel/early-quirks.c Reviewed-by:
-
Daniel Vetter authored
We need to make sure that userspace keeps on following the contract, otherwise we won't be able to use the reserved fields at all. v2: Add DRM_DEBUG (Chris) Testcase: igt/gem_exec_params/*-dirt Reviewed-by:
-
Daniel Vetter authored
A bit tricky since 0 is also a valid constant ... v2: Add DRM_DEBUG (Chris) Testcase: igt/gem_exec_params/rel-constants-* Reviewed-by:
-
Daniel Vetter authored
Currently we catch it, but silently succeed. Our userspace is better than this. v2: Add DRM_DEBUG (Chris) Testcase: igt/gem_exec_params/sol-reset-* Reviewed-by:
-
Chris Wilson authored
If we include the expected values for the failing ring register checks, it makes it marginally easier to see which is the culprit. Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
-
Chris Wilson authored
During module load, if we fail to initialise the rings, we abort the load reporting EIO. However during resume, even though we report EIO as we fail to reinitialize the ringbuffers, the resume continues and the device is restored - albeit in a non-functional state. As we cannot execute any commands on the GPU, it is effectively wedged, mark it so. As we now preserve the ringbuffers across resume, this should prevent UXA from falling into the trap of repeatedly sending invalid batchbuffers and dropping all further rendering into /dev/null. Reported-and-tested-by:
Jiri Kosina <jkosina@suse.cz> References: https://bugs.freedesktop.org/show_bug.cgi?id=76554Signed-off-by:
-
Chris Wilson authored
Even without enabling the ringbuffers to allow command execution, we can still control the display engines to enable modesetting. So make the ringbuffer initialization failure soft, and mark the GPU as wedged instead. v2: Only treat an EIO from ring initialisation as a soft failure, and abort module load for any other failure, such as allocation failures. v3: Add an *ERROR* prior to declaring the GPU wedged so that it stands out like a sore thumb in the logs Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
-
Chris Wilson authored
Tearing down the ring buffers across resume is overkill, risks unnecessary failure and increases fragmentation. After failure, since the device is still active we may end up trying to write into the dangling iomapping and trigger an oops. v2: stop_ringbuffers() was meant to call stop(ring) not cleanup(ring) during resume! Reported-by:
Jae-hyeon Park <jhyeon@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=72351 References: https://bugs.freedesktop.org/show_bug.cgi?id=76554Signed-off-by:
-
Chris Wilson authored
For readibility and guess at the meaning behind the constants. v2: Claim only the meagerest connections with reality. Signed-off-by:
-
Jesse Barnes authored
I don't think this is necessary; at least it doesn't appear to be on my BYT. Dropping it speeds up our shutdown code a little, in some cases resulting in faster init times. Signed-off-by:
-
