- 11 Sep, 2010 1 commit
-
-
Chris Wilson authored
-
- 10 Sep, 2010 13 commits
-
-
Chris Wilson authored
Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Jesse Barnes authored
This allows FDI error checking to work. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Jesse Barnes authored
TU size is only part of the M1 and M2 regs, not the N regs. This keeps us from overwriting a reserved field. Signed-off-by:
-
Jesse Barnes authored
Easier to read, and will pair up with a disable function. Signed-off-by:
-
Jesse Barnes authored
eDP panels require these to be set up prior to panel power sequencing, or they'll fail to power on due to an "asset not ready" check. And of course, eDP panels attached to anything other than DP_A need them enabled regardless, since they'll be driven from the CPU through FDI out to the PCH. Signed-off-by:
-
Jesse Barnes authored
This will allow us to optimize our prepare/commit paths a bit better. Signed-off-by:
-
Jesse Barnes authored
This was just a workaround for some broken Ironlake CRTC code. Signed-off-by:
-
Jesse Barnes authored
So we can use it for CRTC prepare/commit. Signed-off-by:
-
Jesse Barnes authored
This way we can also use it in CRTC prepare/commit. Also makes it easier to split out FDI and other code. Signed-off-by:
-
Chris Wilson authored
create_singlethreaded_workqueue() is being phased out for a new concurrency managed task infrastructure. Adapt our workqueue constructor to explicitly create a domain that only allows the execution of a single task at any time. All the tasks are expected to require the dev->struct_mutex, so would block concurrency of other tasks if we allow more than a single i915 task to be run at once. Signed-off-by: -
Jesse Barnes authored
We don't know how to enable it safely, especially as outputs turn on and off. When disabling LP1 we also need to make sure LP2 and 3 are already disabled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29173 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29082Reported-by:
Chris Lord <chris@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@kernel.org Signed-off-by:
-
- 09 Sep, 2010 5 commits
-
-
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
Currently we have a exact mapping of a connector onto an encoder for its whole lifetime. Make this an explicit property of the structure and so simplify the code. Signed-off-by:
-
Chris Wilson authored
Why iterate all the crtcs to find the pipe, when we already know which crtc is attached to which pipe? Signed-off-by:
-
Chris Wilson authored
[Patch is slightly larger than is strictly necessary to fixup surrounding checkpatch.pl errors.] Signed-off-by:
-
Chris Wilson authored
If we are busy, then we may have woken up the wait_request handler but not yet serviced it before the hang check fires. So in hang check, double check that the i915_gem_do_wait_request() is still pending the wake-up before declaring all hope lost. Fixes regression with e78d73b1. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30073Reported-and-tested-by:
Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by:
-
- 08 Sep, 2010 21 commits
-
-
Chris Wilson authored
Signed-off-by: -
Jesse Barnes authored
Otherwise we may not be able to train the DP link. Signed-off-by:
-
Jesse Barnes authored
When turning on or off the VDD AUX bit, we need to give the panel time to start or stop or AUX transactions may fail. Signed-off-by:
-
Jesse Barnes authored
Mode set sequence outlines when the AUX VDD bit should be set and cleared, and it's separate from the panel power sequence. Signed-off-by:
-
Jesse Barnes authored
Mode set sequence requires that we start training, then enable the panel, then complete training. So split the DP training function into two parts; the first enables the DP port and sets training pattern 1 and the second completes the training. As part of this, remove some redundant function args from the various DP handling functions and use the intel_dp fields everywhere we can. Signed-off-by:
-
Jesse Barnes authored
Mode setting sequence specifies that we use VDD AUX for configuration and detection, and early in the mode set sequence. Only later (after DP_A has started training) should we actually enable panel power. Signed-off-by:
-
Jesse Barnes authored
Fix the test so we don't try to use the 450MHz refclk on PCH attached eDP. References: https://bugs.freedesktop.org/show_bug.cgi?id=29141Signed-off-by:
-
Jesse Barnes authored
Panel needs to be powered up. Signed-off-by:
-
Dan Carpenter authored
snprintf() returns the number of bytes which would have been used if there was enough space. It can be larger than the size of the buffer. Obviously in this case the buffer is large enough but everyone just copy and pastes this code so it's better to limit it and set a good example. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Use the detection from intel-gtt.ko instead. Hooray! Also move the stolen mem allocator to the other gtt stuff in dev_prv->mem. v2: Chris Wilson noted that my error handling was crap. Fix it. He also said that this fixes a problem on his i845. Indeed, i915_probe_agp misses a special case for i830/i845 stolen mem detection. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=25476 Cc: stable@kernel.org Signed-off-by:
-
Daniel Vetter authored
Not used and simply confusing. Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:
-
Daniel Vetter authored
This way create_gatt_table become dummy glue functions for the fake agp driver - rename them accordingly (and kill the now unnecessary i9xx copy). With this change, the gtt initialization code is almost independant from the agp stuff. Two things are still missing: - the scratch page is created by the generic agp code. - filling the whole gtt with scratch_page ptes is not yet consolidated - this needs abstracted pte handling, first. Signed-off-by:
-
Daniel Vetter authored
The only difference between i915 and i965 was the calculation of the gtt address. So merge these two paths into one. Otherwise the same changes as in the i830 setup consolidation. Signed-off-by:
-
Daniel Vetter authored
Slighlty reordered sequence was necessary. Also don't set agp_bridge->gatt_bus_addr anymore. Only used by generic agp helper functions, hence unnecessary for the intel fake agp driver. Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:
-
Daniel Vetter authored
This way around this can be extracted into common code. Also use a common cleanup function (and give it a generic name). Signed-off-by:
-
Daniel Vetter authored
Also move the Sandybdridge size detection into gtt_total_entries, like the rest. Signed-off-by:
-
Daniel Vetter authored
Slight reordering of the init sequence required. Signed-off-by:
-
Daniel Vetter authored
Same idea as INTEL_INFO from drm/i915. This - reduces the dependancy on agp_driver - stops the what-does-IS_I965G-mean confusion (here it's just gen4, in drm/i915 it's gen >=4) - further prepares the separation of the fake agp driver from the rest. Signed-off-by:
-
Daniel Vetter authored
In commit f1befe71 Chris Wilson added some code to clear the full gtt on g33/pineview instead of just the mappable part. The code looks like it was copy-pasted from agp/intel-gtt.c, at least an identical piece of code is still there (in intel_i830_init_gtt_entries). This lead to a regression in 2.6.35 which was supposedly fixed in commit e7b96f28 Now this commit makes absolutely no sense to me. It seems to be slightly confused about chipset generations - it references docs for 4th gen but the regression concerns 3rd gen g33. Luckily the the g33 gmch docs are available with the GMCH Graphics Control pci config register definitions. The other (bigger problem) is that the new check in there uses the i830 stolen mem bits (.5M, 1M or 8M of stolen mem). They are different since the i855GM. The most likely case is that it hits the 512M fallback, which was probably the right thing for the boxes this was tested on. So the original approach by Chris Wilson seems to be wrong and the current code is definitely wrong. There is a third approach by Jesse Barnes from his RFC patch "Who wants a bigger GTT mapping range?" where he simply shoves g33 in the same clause like later chipset generations. I've asked him and Jesse confirmed that this should work. So implement it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16891$Tested-by:
Anisse Astier <anisse@astier.eu> Cc: stable@kernel.org Signed-off-by:
-
