summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)Author
2010-09-08drm/i915: die, i915_probe_agp, dieDaniel Vetter
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 <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915: drop prealloc_start from i915_dma gtt initDaniel Vetter
Not used and simply confusing. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: use chipset generation number some moreDaniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: call init_gtt_init in probe functionDaniel Vetter
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 <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: consolidate i9xx setupDaniel Vetter
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 <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: consolidate i830 setupDaniel Vetter
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 <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: consolidate the gtt ioremap callsDaniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: i830: adjust ioremap of regs and gtt to i9xxDaniel Vetter
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 <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: i965: use detected gtt size for mappingDaniel Vetter
Also move the Sandybdridge size detection into gtt_total_entries, like the rest. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: i915: use detected gtt size for mappingDaniel Vetter
Slight reordering of the init sequence required. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: introduce intel_gtt_driverDaniel Vetter
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 <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: fix gtt_total_entries detectionDaniel Vetter
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: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: s/i8[13]0/fake_agp for generic functionsDaniel Vetter
Start to separate the fake agp driver from the rest of intel-gtt.c Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: adjust overhead entries in intel_gtt_stolen_entriesDaniel Vetter
agp/intel_gtt.c and drm/i915/i915_dma.c don't calculate this the same way: The intel-gtt code seems to use the actual gtt size, the drm module just the mappable. Go with the logic from the drm module because that's the more conservative choice. But conserve the original code in intel_gtt_total_size for later use. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: drop unnecessary conditions in intel_gtt_stolen_entriesDaniel Vetter
The dedection function in drm/i915/i915_dma.c works without it, so drop it here, too. All the values are disdinct, anyway. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: sane variable names for intel_gtt_stolen_entriesDaniel Vetter
This somewhat aligns it with the version in drm/i915/i915_dma.c. Changes: - s/gtt_entries/stolen_size - track overhead entries in a seperate var (the effective gtt size calculation will be extracted later on). - subtract the overhead at the end instead of in each clause. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: generic intel_fake_agp_fetch_sizeDaniel Vetter
This uses the new mappable gtt size detection from the previous patch. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: new function intel_gtt_mappable_entriesDaniel Vetter
This implementation is stolen from drm/i915, but is equivalent to the code sprinkled over intel-gtt.c in the various fetch_size functions. It's not yet used anywhere, though. Also introduce intel_gtt_init which only calls intel_gtt_stolen_entries. Over the course of the next patches, this will grow untill it contains the complete init sequence starting from the call to gtt_mappable_entries. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: s/intel_i830_init_gtt_entries/intel_gtt_stolen_entriesDaniel Vetter
First simple step towards a more generic initialization. This is needed to disentangle the agp stuff from the stuff that is actually needed by drm/i915. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: store a local pointer to the bridge pci devDaniel Vetter
When the intel-gtt code now longer depends on agp, we cannot rely on this. So store a local reference in intel-gtt.c. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08intel-gtt: introduce drm/intel-gtt.hDaniel Vetter
Add a few definitions to it that are already shared and that will be shared in the future (like the number of stolen entries). No functional changes in here. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08agp/intel: make intel-gtt.c into a real source fileDaniel Vetter
Now that the disentangling is complete, stop including intel-gtt.c from intel-agp.c. The linux build system _really_ doesn't allow .c source files with the same name as the module. It fails with the following message when trying to build such a bugger: make[3]: Circular drivers/char/agp/intel-agp.o <- drivers/char/agp/intel-agp.o dependency dropped. Instead of renameing intel-agp.c I've simply created a new module out of intel-gtt.c. Renaming intel-agp.ko to something else is not an option for it will surely kill someones boot process. This also paves the way to use the gtt code without loading the agp driver. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08agp/intel: split out gmch/gtt probe, part 2Daniel Vetter
This just splits the device list into two and moves the gtt related stuff to intel-gtt.c. The two new devices lists also lose the not longer needed fields. There where only about 5 cases anyway with both a gmch and a possible agp port, so the duplication of entries is rather small. Additionally kill 2 out of the three Ironlake mobile entries that only differed in host bridge pci id. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915: Don't disable panel for modesetting if pfit hasn't changedMatthew Garrett
It seems to be possible to program a new mode without disabling the panel if the panel fitter setup doesn't change. Add support for that. Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915: set dither bits on eDP panels tooJesse Barnes
We really need a macro to test whether a given connector has a panel attached rather than sprinkling HAS_PCH_SPLIT/IS_eDP/has_edp_encoder etc all over. In the meantime, fix the bug... Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [ickle: tidy up the duplicity in the conditionals] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915: fix pipeconf dither bit definitionsJesse Barnes
Make them match the others and add BPP definitions. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915: Remove impossible error handling from bit17 swizzlingChris Wilson
Our usage of kmap() cannot return NULL here, so remove the unnecessary error handling. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915: Add ringbuffer wait reset to hangcheckChris Wilson
The GPU records whether it is currently waiting for a completion of a WAIT_FOR_EVENT in the RB_WAIT bit in the ringbuffer control registers. On third generation chipsets and later, a write of 1 to this bit breaks the hang and returns the GPU to arbitration, i.e. the GPU should continue executing the reminder of the batchbuffer and return to normal operations. By adding this to hangcheck we can avoid a full GPU reset under these conditions. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915: Clear scanline waits after disabling the pipe.Chris Wilson
If we disable the pipe and the GPU is currently waiting on a scanline WAIT_FOR_EVENT, the GPU will hang. Fortunately, there is a magic bit which we can write on i915+ to break this wait after disabling the pipe. References: Bug 29252 - [Arrandale] Hung WAIT_FOR_EVENT when running rss-glx-skyrocket https://bugs.freedesktop.org/show_bug.cgi?id=29252 Bug 28964 - [i965gm] GPU infinite MI_WAIT_FOR_EVENT while watching video in Totem https://bugs.freedesktop.org/show_bug.cgi?id=28964 and many others. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-09-08drm/i915: Show framebuffer info in debugfsChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915: Show device capabilities in debugfsChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915/tv: After disabling the pipe, use wait_for_vblank_off()Chris Wilson
Hopefully this is a contributing factor to the spurious TV detection repoted by Ivan Bulatovic and others. References: Bug 16871 - "TV1 connected" with no tv https://bugzilla.kernel.org/show_bug.cgi?id=16871 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Ivan Bulatovic <combuster@gmx.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-09-08drm/i915: Refactor panel backlight controlsChris Wilson
There were two instances of code to control the panel backlight and neither handled the complete set of device variations. Fixes: Bug 29716 - [GM965] Regression: Backlight resets to minimum when changing resolution https://bugs.freedesktop.org/show_bug.cgi?id=29716 And a bug on one of my PineView boxes which overflowed the backlight value. Incorporates part of a similar patch by Matthew Garrett that exposes a native Intel backlight controller. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915: Remove redundant initialisation of fb_baseChris Wilson
We do it whilst configuring dev->mode_config, so remove the out-of-place earlier initialisation. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915: Quieten sparse warnings for missing prototypes.Chris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915: Kill the active list spinlockChris Wilson
This spinlock only served debugging purposes in a time when we could not be sure of the mutex ever being released upon a GPU hang. As we now should be able rely on hangcheck to do the job for us (and that error reporting should not itself require the struct mutex) we can kill the incomplete attempt at protection. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915: Remove the random SyncFlush during initialisationChris Wilson
We have no idea why we request a SyncFlush via INSTPM at that point in time -- we certainly never check for its completion... Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915: Compile out error state without DEBUG_FSChris Wilson
Alexander reported that the compilation of intel_overlay.c was failing due to an inclusion that was only valid with CONFIG_DEBUG_FS. As the whole error reporting is only useful with debugfs enabled, remove all the redundant error state collection code when compiling without CONFIG_DEBUG_FS. Reported-by: Alexander Lam <lambchop468@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915/overlay: Use a continuation hook to finish work after a flip.Chris Wilson
Slightly easier to follow than the state machine and now possible as the control structure is opaque and hw_wedged is no longer interferred with. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2010-09-08drm/i915/overlay: Make the overlay control struct opaque.Chris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2010-09-08drm/i915/overlay: Pass interruptible to switch_off()Chris Wilson
During DPMS we currently do not want the overlay code to be interruptible, so pass that information down and only take the uninterrruptible paths. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2010-09-08drm/i915/overlay: Workaround i830 overlay activation bug.Chris Wilson
On i830, there exists a bug where an overlay on pipe B requires the mode clock on pipe A in order to activate. So workaround this by activating pipe A when trying to enable the overlay on pipe B. References: [Bug 29007] GPU hang on video playback with overlay https://bugs.freedesktop.org/show_bug.cgi?id=29007 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-09-08drm/i915/overlay: Make do_put_image() as staticChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2010-09-08drm/i915: Preallocate requestsChris Wilson
By allocating the request prior to writing to the ringbuffer, we can abort the operation without leaving the GPU in an inconsistent state. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2010-09-08drm/i915/overlay: Tidy release_old_vid()Chris Wilson
Inline the call to wait_flip() and simplify the resulting code. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2010-09-08drm/i915/overlay: Combine SWITCH_OFF into a single stepChris Wilson
We can program the h/w to first wait on the flip and then switch off without relying on s/w intervention. This removes the need for a double step switch off, bringing much rejoicing. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2010-09-08drm/i915/overlay: Explicitly pass regs from map to unmapChris Wilson
The scoping of the validity of the mapping is thus clarified. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2010-09-08drm/i915/overlay: Refactor do_wait_request()Chris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2010-09-08drm/i915/overlay: Tidy check_overlay_dst()Chris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2010-09-08drm/i915/overlay: Tidy update_pfit_vscale_ratio()Chris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2025-02-08 19:26:34 +0000