- 27 Mar, 2012 5 commits
-
-
Chris Wilson authored
We try to avoid writing the relocations through the uncached GTT, if the buffer is currently in the CPU write domain and so will be flushed out to main memory afterwards anyway. Also on SandyBridge we can safely write to the pages in cacheable memory, so long as the buffer is LLC mapped. In either of these cases, we therefore do not need to force the reallocation of the buffer into the mappable region of the GTT, reducing the aperture pressure. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
We've lost our guard page somewhere in the gtt rewrite, this patch here will restore it. Exercised by i-g-t/tests/gem_cs_prefetch. v2: Substract the guard page from the range we're supposed to manage with gem. Suggested by Chris Wilson to increase the odds of old ums + gem userspace not blowing up. To compensate for the loss of a page, don't substract the guard page in the modeset init code any longer. Tested-by:
-
Daniel Vetter authored
So don't call it like that. Also rip out a confusing comment and instead explain what's really going on. Reviewed-by:
-
Daniel Vetter authored
... because this is what it actually doesn now that we have the global gtt vs. ppgtt split. Also move it to the other global gtt functions in i915_gem_gtt.c Signed-Off-by: -
Daniel Vetter authored
This reverts commmit d4b74bf0 which reverted the origin fix fb8b5a39. We have at least 3 different bug reports that this fixes things and no indication what is exactly wrong with this. So try again. To make matters slightly more fun, the commit itself was cc: stable whereas the revert has not been. According to Peter Clifton he discussed this with Zhao Yakui and this seems to be in contradiction of the GM45 PRM, but rumours have it that this is how the BIOS does it ... let's see. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Tested-by:
Peter Clifton <Peter.Clifton@clifton-electronics.com> Cc: Zhao Yakui <yakui.zhao@intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Eric Anholt <eric@anholt.net> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16236 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=25913 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=14792Signed-Off-by:
-
- 26 Mar, 2012 1 commit
-
-
Chris Wilson authored
Originally the code tried to allocate a large enough array to perform the copy using vmalloc, performance wasn't great and throughput was improved by processing each individual relocation entry separately. This too is not as efficient as one would desire. A compromise would be to allocate a single page, or to allocate a few entries on the stack, and process the copy in batches. The latter gives simpler code and more consistent performance due to a lack of heuristic. x11perf -copywinwin10: n450/pnv i3-330m i5-2520m (cpu) before: 249000 785000 1280000 (80%) page: 264000 896000 1280000 (65%) on-stack: 264000 902000 1280000 (67%) v2: Use 512-bytes of stack for batching rather than allocate a page. v3: Tidy the code slightly with more descriptive variable names Signed-off-by:
-
- 25 Mar, 2012 2 commits
-
-
Daniel Vetter authored
With the recent set of gmbus fixes, this seems to work on my i855gm. Acked-by:
-
Daniel Vetter authored
Again, Valleyview modes these around, so make the mmio base more explicit to consolidate the base address computations to one HAS_PCH_SPLIT check. v2: Fix up the PCH_SPLIT braino ... it actually works that way round. Reviewed-by:
-
- 24 Mar, 2012 1 commit
-
-
Daniel Vetter authored
With valleyview we'll have these at yet another address, so keeping track of this with an ever-growing list of registers will get ugly. This way intel_sdvo.c is fully independent of the base address of the output ports display register blocks. While at it, do 2 closely related cleanups: - use SDVO_NAME some more - change the sdvo_reg variables to uint32_t like other registers. Reviewed-by:
-
- 23 Mar, 2012 3 commits
-
-
Jesse Barnes authored
They were all over the place, order them by position and add a few. v2: add gen indications to the new bits (Ben) Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Jesse Barnes authored
It's only used by the main read/write functions, so we can keep it with them. Signed-off-by:
-
Chris Wilson authored
If we discard a buffer due to memory pressure, also release its alloted mmap address space. As it may be sometime before userspace wakes up and notices that it has buffers to purge from its cache, we may waste valuable address space on unusable objects for a period of time. Signed-off-by:
-
- 22 Mar, 2012 4 commits
-
-
Takashi Iwai authored
Add a new module optoin lvds_channel to specify the LVDS channel mode explicitly instead of probing the LVDS register value set by BIOS. This will be helpful when VBT is broken or incompatible with the current code. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42842Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
Currently i915 driver checks [PCH_]LVDS register bits to decide whether to set up the dual-link or the single-link mode. This relies implicitly on that BIOS initializes the register properly at boot. However, BIOS doesn't initialize it always. When the machine is booted with the closed lid, BIOS skips the LVDS reg initialization. This ends up in blank output on a machine with a dual-link LVDS when you open the lid after the boot. This patch adds a workaround for that problem by checking the initial LVDS register value in VBT. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37742Tested-By:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Ben Widawsky authored
Introduced in commits c1cd90ed and d27b1e0eSigned-off-by:
-
Ben Widawsky authored
Introduced in commit 8461d226 and 8c59967cSigned-off-by:
-
- 20 Mar, 2012 5 commits
-
-
Daniel Vetter authored
On Sanybridge a few MI read/write commands only work when ppgtt is enabled. Userspace therefore needs to be able to check whether ppgtt is enabled. For added hilarity, you need to reset the "use global GTT" bit on snb when ppgtt is enabled, otherwise it won't work. Despite what bspec says about automatically using ppgtt ... Luckily PIPE_CONTROL (the only write cmd current userspace uses) is not affected by all this, as tested by tests/gem_pipe_control_store_loop. Reviewed-and-tested-by:
-
Daniel Vetter authored
Now that everything is in place, only bind to the global gtt when actually required. Patch split-up suggested by Chris Wilson. Reviewed-and-tested-by:
-
Daniel Vetter authored
PIPE_CONTROL on snb needs global gtt mappings in place to workaround a hw gotcha. No other commands need such a workaround. Luckily we can detect a PIPE_CONTROL commands easily because they have a write_domain = I915_GEM_DOMAIN_INSTRUCTION (and nothing else has that). v2: Binding the target of such a reloc into the global gtt actually works instead of binding the source, which is rather pointless ... v3: Kill a superflous has_global_gtt_mapping assignement noticed by Chris Wilson. Reviewed-and-tested-by:
-
Daniel Vetter authored
And track the existence of such a binding similar to the aliasing ppgtt case. Speeds up binding/unbinding in the common case where we only need a ppgtt binding (which is accessed in a cpu coherent fashion by the gpu) and no gloabl gtt binding (which needs uc writes for the ptes). This patch just puts the required tracking in place. v2: Check that global gtt mappings exist in the error_state capture code (with Chris Wilson's llc reloc patches batchbuffers are no longer relocated as mappable in all situations, so this matters). Suggested by Chris Wilson. v3: Adapted to Chris' latest llc-reloc patches. v4: Fix a bug in the i915 error state capture code noticed by Chris Wilson. Reviewed-and-tested-by:
-
Daniel Vetter authored
Note that there's a functional change buried in this patch wrt the ilk dmar workaround: We now only idle the gpu while tearing down the dmar mappings, not while clearing the gtt. Keeping the current semantics would have made for some really ugly code and afaik the issue is only with the dmar unmapping that needs a fully idle gpu. Reviewed-and-tested-by:
-
- 18 Mar, 2012 7 commits
-
-
Joe Perches authored
Use a more current logging style. Ensure that appropriate logging messages are prefixed with "i915: ". Convert printks to pr_<level>. Align arguments. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Carsten Emde authored
Mark the Acer Aspire 5734Z that this machines requires the module to invert the panel backlight brightness value after reading from and prior to writing to the PCI configuration space. Signed-off-by:
Carsten Emde <C.Emde@osadl.org> Acked-by:
-
Carsten Emde authored
A machine may need to invert the panel backlight brightness value. This patch adds the infrastructure for a quirk to do so. Signed-off-by:
-
Carsten Emde authored
Following the documentation of the Legacy Backlight Brightness (LBB) Register in the configuration space of some Intel PCI graphics adapters, setting the LBB register with the value 0x0 causes the backlight to be turned off, and 0xFF causes the backlight to be set to 100% intensity (http://download.intel.com/embedded/processors/Whitepaper/324567.pdf). The Acer Aspire 5734Z, however, turns the backlight off at 0xFF and sets it to maximum intensity at 0. In consequence, the screen of this systems becomes dark at an early boot stage which makes it unusable. The same inversion applies to the BLC_PWM_CTL I915 register. This problem was introduced in kernel version 2.6.38 when the PCI device of this system was first supported by the i915 KMS module. This patch adds a parameter to the i915 module to enable inversion of the brightness variable (i915.invert_brightness). Signed-off-by:
-
Sean Paul authored
I have seen a number of "blt ring initialization failed" messages where the ctl or start registers are not the correct value. Upon further inspection, if the code just waited a little bit, it would read the correct value. Adding the wait_for to these reads should eliminate the issue. Signed-off-by:
Sean Paul <seanpaul@chromium.org> Reviewed-by:
-
Adam Jackson authored
Some newer BIOSes are shipping with all MTRRs already populated. These BIOSes are all on machines with sufficiently new CPUs that the referenced errata doesn't apply anyway, so just don't try to claim the MTRR. Signed-off-by:
-
Adam Jackson authored
No functional change here, just clarifying code flow. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
- 02 Mar, 2012 2 commits
-
-
Sean Paul authored
According to the PRM (Vol3P2), the PCH FDI receiver ISR read for bit lock should be retried at least once. This patch retries the read 5 times with a small delay in between reads. I've had reports of display corruption on resume with "FDI train 1 fail!", so I'm hoping that adding this retry will mitigate the issue. Signed-off-by:
-
Jesse Barnes authored
They're not really errors (well actually I don't know; I don't understand _DSM and _MUX well enough to say, but I do know they spam people's logs and seem to be harmless). Signed-off-by:
-
- 01 Mar, 2012 2 commits
-
-
Mathias Fröhlich authored
This change enables the use of displays where the vbt table just contains inappropriate values, but either the vesa defaults or the video=... modes do something sensible with the attached display. The problem happens with an embedded board that contains vbt bios tables that do not match the attached display. Using this change and the appropriate kernel boot command line they are able to use an otherwise completely unusable secondary display on that embedded board. Reviewed-by:
Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by:
Mathias Froehlich <Mathias.Froehlich@web.de> Signed-off-by:
-
Chris Wilson authored
By clearing the GPU read domains before waiting upon the buffer, we run the risk of the wait being interrupted and the domains prematurely cleared. The next time we attempt to wait upon the buffer (after userspace handles the signal), we believe that the buffer is idle and so skip the wait. There are a number of bugs across all generations which show signs of an overly haste reuse of active buffers. Such as: https://bugs.freedesktop.org/show_bug.cgi?id=29046 https://bugs.freedesktop.org/show_bug.cgi?id=35863 https://bugs.freedesktop.org/show_bug.cgi?id=38952 https://bugs.freedesktop.org/show_bug.cgi?id=40282 https://bugs.freedesktop.org/show_bug.cgi?id=41098 https://bugs.freedesktop.org/show_bug.cgi?id=41102 https://bugs.freedesktop.org/show_bug.cgi?id=41284 https://bugs.freedesktop.org/show_bug.cgi?id=42141 A couple of those pre-date i915_gem_object_finish_gpu(), so may be unrelated (such as a wild write from a userspace command buffer), but this does look like a convincing cause for most of those bugs. Signed-off-by:
-
- 29 Feb, 2012 8 commits
-
-
Daniel Vetter authored
With the rework to merge the bit-banging fallback into the gmbus i2c adapter we've gotten rid of the deadlock possibility that originally lead to the disabling of this code. This reverts the revert commit 826c7e41 Author: Jean Delvare <khali@linux-fr.org> Date: Sat Jun 4 19:34:56 2011 +0000 Revert "drm/i915: Enable GMBUS for post-gen2 chipsets" Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=35572Reviewed-by:
-
Daniel Vetter authored
This way we can simplify the setup and teardown a bit. Because we don't actually allocate anything anymore for the force_bit case, we can now convert that into a boolean. Also and the functionality supported by the bit-banging together with what gmbus can do, so that this doesn't randomly change any more. v2: Chris Wilson noticed that I've mixed up && and & ... v3: Clarify an if block as suggested by Eugeni Dodonov. Reviewed-by:
-
Daniel Vetter authored
... and directly call the newly exported i2c bit-banging functions. The code is still pretty convoluted because we only set up the gpio i2c stuff when actually falling back, resulting in more complexity than necessary. This will be fixed up in the next patch. v2: Use exported i2c_bit_algo vtable instead of exported functions. Reviewed-by:
-
Daniel Vetter authored
When we set up the gpio fallback, we always have a 1:1 relationship with an intel_gmbus. Exploit that to store all gpio related data in there, too. This is a preparation step to merge the tw i2c adapters controlling the same bus into one. Just mundane code-munging in this patch. Reviewed-by:
-
Daniel Vetter authored
i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons we need to be able to fall back to the bit-banging algo on gpio pins. The current code sets up a 2nd i2c controller for the same i2c bus using the bit-banging algo. This has a bunch of issues, the major one being that userspace can directly access this fallback i2c adaptor behind the drivers back. But we need to frob a few registers before and after using fallback gpio bit-banging, so this horribly fails. The new plan is to only set up one i2c adaptor and transparently fall back to bit-banging by directly calling the xfer function of the bit- banging algo in the i2c core. To make that possible, export the 2 i2c algo functions. v2: As suggested by Jean Delvare, simply export the i2c_bit_algo vtable instead of the individual functions. Acked-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Daniel Vetter authored
I'd like to export the corresponding functions from the i2c core so that I can use them in fallback bit-banging in i915.ko v2: Adapt to new i2c export patch. Cc: nouveau@lists.freedesktop.org Acked-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Daniel Vetter authored
This way we can free up the bus->adaptor.algo_data pointer and make it available for use with the bitbanging fallback algo. Reviewed-by:
-
Benson Leung authored
gmbus_xfer with a single message (particularly a single message write) would set Bus Cycle Select to 100b, the Gen Stop cycle, instead of 101b, No Index, Stop cycle. This would not start single message i2c transactions. Also, gmbus_xfer done: will disable the interface without checking if it is idle. In the case of writes, there will be no wait on status or delay to ensure the write starts and completes before the interface is turned off. Fixed the former issue by using the same cycle selection as used in the I2C_M_RD for the write case. GMBUS_CYCLE_WAIT | (i + 1 == num ? GMBUS_CYCLE_STOP : 0) Fixed the latter by waiting on GMBUS_ACTIVE to deassert before disable. Note from the grumpy d-i-n maintainer: The first hunk that changes the gmbus read path is just cosmetics to align the code with the write path. I.e. the commit message above is slightly lying because the first issue is _only_ with writes (and not simply "particularly"). Signed-off-by:
Benson Leung <bleung@chromium.org> Reviewed-by:
Daniel Kurtz <djkurtz@chromium.org> Signed-off-by:
-
