Daniel Vetter [Sun, 25 Mar 2012 17:47:28 +0000 (19:47 +0200)]
drm/i915: merge shmem_pwrite slow&fast-path
With the previous rewrite, they've become essential identical.
v2: Simplify the page_do_bit17_swizzling logic as suggested by Chris
Wilson.
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Mon, 26 Mar 2012 08:10:27 +0000 (10:10 +0200)]
drm/i915: Avoid using mappable space for relocation processing through the CPU
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 <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 26 Mar 2012 07:45:42 +0000 (09:45 +0200)]
drm/i915: clear the entire gtt when using gem
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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44748 Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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=14792 Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sat, 24 Mar 2012 20:12:53 +0000 (20:12 +0000)]
drm/i915: Batch copy_from_user for relocation processing
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.
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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Fri, 24 Feb 2012 21:13:38 +0000 (21:13 +0000)]
drm/i915: Release the mmap offset when purging a buffer
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: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47738 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Takashi Iwai [Tue, 20 Mar 2012 12:07:06 +0000 (13:07 +0100)]
drm/i915: Add lvds_channel module option
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=42842 Reviewed-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: Daniel Vetter <daniel.vetter@ffwll.ch>
Takashi Iwai [Tue, 20 Mar 2012 12:07:05 +0000 (13:07 +0100)]
drm/i915: Check VBIOS value for determining LVDS dual channel mode, too
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=37742 Tested-By: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: s/fix/shut up in the commit msg and add a comment to the
BUG_ON.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 15 Feb 2012 22:50:25 +0000 (23:50 +0100)]
drm/i915: add HAS_ALIASING_PPGTT parameter for userspace
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: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 15 Feb 2012 22:50:23 +0000 (23:50 +0100)]
drm/i915: implement SNB workaround for lazy global gtt
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: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 15 Feb 2012 22:50:22 +0000 (23:50 +0100)]
drm/i915: bind objects to the global gtt only when needed
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: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 15 Feb 2012 22:50:21 +0000 (23:50 +0100)]
drm/i915: split out dma mapping from global gtt bind/unbind functions
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: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Carsten Emde [Thu, 15 Mar 2012 14:56:26 +0000 (15:56 +0100)]
drm/i915: panel: invert brightness via quirk
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 <C.Emde@osadl.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Carsten Emde [Thu, 15 Mar 2012 14:56:25 +0000 (15:56 +0100)]
drm/i915: panel: invert brightness via parameter
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: Carsten Emde <C.Emde@osadl.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Sean Paul [Fri, 16 Mar 2012 16:43:22 +0000 (12:43 -0400)]
drm/i915: Add wait_for in init_ring_common
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: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Adam Jackson [Wed, 14 Mar 2012 15:22:11 +0000 (11:22 -0400)]
drm/i915: Don't do MTRR setup if PAT is enabled
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 <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41648 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Adam Jackson [Wed, 14 Mar 2012 15:22:10 +0000 (11:22 -0400)]
drm/i915: Pull MTRR setup to its own function
No functional change here, just clarifying code flow.
Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Sean Paul [Fri, 2 Mar 2012 17:53:39 +0000 (12:53 -0500)]
drm/i915: Retry reading the PCH FDI receiver ISR
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: Sean Paul <seanpaul@chromium.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jesse Barnes [Thu, 12 Jan 2012 17:03:14 +0000 (09:03 -0800)]
drm/i915: remove ACPI related DRM_ERRORs
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: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: The _DSM error got remove in another patch already]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44250 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Wed, 14 Dec 2011 12:57:23 +0000 (13:57 +0100)]
drm/i915: Only clear the GPU domains upon a successful finish
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.
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 14 Feb 2012 21:37:25 +0000 (22:37 +0100)]
drm/i915: reenable gmbus on gen3+ again
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.
Daniel Vetter [Mon, 27 Feb 2012 23:43:09 +0000 (00:43 +0100)]
drm/i915: merge gmbus and gpio i2c adpater into one
... 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: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 14 Feb 2012 21:37:22 +0000 (22:37 +0100)]
drm/i915: merge struct intel_gpio into struct intel_gmbus
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: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 27 Feb 2012 23:39:39 +0000 (00:39 +0100)]
i2c: export bit-banging algo functions
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 <daniel.vetter@ffwll.ch>
Benson Leung [Thu, 9 Feb 2012 20:03:17 +0000 (12:03 -0800)]
drm/i915: Fix single msg gmbus_xfers writes
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: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 16 Feb 2012 10:03:29 +0000 (11:03 +0100)]
drm/i915: error_buffer->ring should be signed
gcc seems to get uber-anal recently about these things.
Clarification from Dan Carpenter:
"Sorry, I should have said that it's not a gcc warning, it's a smatch
thing. But also it's not uber-anal. It's the exact level of anality
which is required to make the == -1 test work. You can compare
unsigned int and longs to -1 and it works but for smaller types it
doesn't."
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Wed, 22 Feb 2012 20:39:12 +0000 (20:39 +0000)]
drm/i915: Silence the error message from i915_wait_request()
This error message has since been superseded by the hangcheck, and does
not add any salient information beyond that already printed by hangcheck
discovering the GPU hang that lead to i915_wait_request() bombing out in
the first place.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 23 Feb 2012 16:14:47 +0000 (17:14 +0100)]
drm/i915: use the new hdmi_force_audio enum more
While fixing up a merge conflict with drm-next I've noticed that we
use the same audio drm connector property also for dp and sdvo
outputs.
So put the new enum to some good use and convert these paths, too. The
HDMI_AUDIO_ prefix is a bit a misnomer. But at least for sdvo it makes
sense (and you can also connect a hdmi monitor with a dp->hdmi cable),
so I've decided to stick with it.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Wu Fengguang <fengguang.wu@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Fri, 24 Feb 2012 00:27:21 +0000 (00:27 +0000)]
drm/i915: Only bump refcnt on objects scheduled for eviction
Incrementing the reference count on all objects walked when searching
for space in the aperture is a non-neglible amount of overhead. In fact,
we only need to hold on to a reference for objects that we will evict,
so we can therefore delay the referencing until we find a suitable hole
and only add those objects that fall inside.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Fri, 24 Feb 2012 16:53:28 +0000 (16:53 +0000)]
drm/i915/bios: Downgrade the "signature missing" DRM_ERROR to debug
As we warn the user later that we cannot find or load the VBIOS,
explaining why is an exercise in debugging. Shouting *ERROR* upsets
people and produces bug reports.
Reported-by: Michael Rieder <mr@student.ethz.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43751 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Marc Gariepy [Thu, 9 Feb 2012 14:35:21 +0000 (09:35 -0500)]
drm/i915: Ignore LVDS on hp t5745 and hp st5747 thin client
Add a no_lvds quirk for the HP t5745 and HP st5747 thin clients
dmidecode for those thin clients are attached in thoses bugs:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911916
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911920
Signed-off-by: Marc Gariepy <mgariepy@ubuntu.com> Acked-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Philipp Grete [Tue, 21 Feb 2012 11:40:20 +0000 (12:40 +0100)]
drm/i915: Fixes distorted external screen image on HP 2730p
Fixes LP: #796030 by removing forced pipe A on HP 2730p. Quirk has
previously been introduced to fix a sleep mode problem that does not
exist any more.
v2: Added Tested-by and Bugzilla Link
Bugzilla: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796030 Tested-by: Ronny Standtke <ronny.standtke@gmx.net> Signed-off-by: Philipp Grete <mail@pgrete.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 23 Feb 2012 13:54:20 +0000 (14:54 +0100)]
Merge remote-tracking branch 'airlied/drm-next' into for-airlied
Manually resolve the conflict between the new enum drm property
helpers in drm-next and the new "force-dvi" option that the "audio" output
property gained in drm-intel-next.
While resolving this conflict, switch the new drm_prop_enum_list to
use the newly introduced enum defines instead of magic values.
Conflicts:
drivers/gpu/drm/i915/intel_modes.c
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dave Airlie [Thu, 29 Sep 2011 15:20:42 +0000 (16:20 +0100)]
drm: add some caps for userspace to discover more info for dumb KMS driver (v2)
For the simple KMS driver case we need some more info about what the preferred
depth and if a shadow framebuffer is preferred.
I've only added this for intel/radeon which support the dumb ioctls so far.
If you need something really fancy you should be writing a real X.org driver.
v2: drop cursor information, just return an error from the cursor ioctls
and we can make userspace fallback to sw cursor in that case, cursor
info was getting too messy, best to start smaller.
Dave Airlie [Mon, 19 Dec 2011 11:15:29 +0000 (11:15 +0000)]
drm: move pci bus master enable into driver.
The current enabling of bus mastering in the drm midlayer allows a large
race condition under kexec. When a kexec'ed kernel re-enables bus mastering
for the GPU, previously setup dma blocks may cause writes to random pieces
of memory. On radeon the writeback mechanism can cause these sorts of issues.
This patch doesn't fix the problem, but it moves the bus master enable under
the individual drivers control so they can move enabling it until later in
their load cycle and close the race.
Fix for radeon kms driver will be in a follow-up patch.
Chris Wilson [Thu, 9 Feb 2012 09:35:53 +0000 (09:35 +0000)]
drm/i915/lvds: Always use the presence pin for LVDS on PCH
With the introduction of the PCH, we gained an LVDS presence pin but we
continued to use the existing logic that asserted that LVDS was only
supported on certain mobile chipsets. However, there are desktop
IronLake systems with LVDS attached which we fail to detect. So for PCH,
trust the LVDS presence pin and quirk all the lying manufacturers.
Tested-by: Daniel Woff <wolff.daniel@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43171 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Wed, 15 Feb 2012 11:25:37 +0000 (11:25 +0000)]
drm/i915: Record the in-flight requests at the time of a hang
Being able to tally the list of outstanding requests with the sequence
of commands in the ringbuffer is often useful evidence with respect to
driver corruption.
Note that since this is the umpteenth per-ring data structure to be added
to the error state, I've coallesced the nearby loops (the ringbuffer and
batchbuffer) into a single structure along with the list of requests. A
later task would be to refactor the ring register state into the same
structure.
v2: Fix pretty printing of requests so that they are parsed correctly by
intel_error_decode and use the 0x%08x format for seqno for consistency
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Wed, 15 Feb 2012 11:25:36 +0000 (11:25 +0000)]
drm/i915: Record the tail at each request and use it to estimate the head
By recording the location of every request in the ringbuffer, we know
that in order to retire the request the GPU must have finished reading
it and so the GPU head is now beyond the tail of the request. We can
therefore provide a conservative estimate of where the GPU is reading
from in order to avoid having to read back the ring buffer registers
when polling for space upon starting a new write into the ringbuffer.
A secondary effect is that this allows us to convert
intel_ring_buffer_wait() to use i915_wait_request() and so consolidate
upon the single function to handle the complicated task of waiting upon
the GPU. A necessary precaution is that we need to make that wait
uninterruptible to match the existing conditions as all the callers of
intel_ring_begin() have not been audited to handle ERESTARTSYS
correctly.
By using a conservative estimate for the head, and always processing all
outstanding requests first, we prevent a race condition between using
the estimate and direct reads of I915_RING_HEAD which could result in
the value of the head going backwards, and the tail overflowing once
again. We are also careful to mark any request that we skip over in
order to free space in ring as consumed which provides a
self-consistency check.
Given sufficient abuse, such as a set of unthrottled GPU bound
cairo-traces, avoiding the use of I915_RING_HEAD gives a 10-20% boost on
Sandy Bridge (i5-2520m):
firefox-paintball 18927ms -> 15646ms: 1.21x speedup
firefox-fishtank 12563ms -> 11278ms: 1.11x speedup
which is a mild consolation for the performance those traces achieved from
exploiting the buggy autoreported head.
v2: Add a few more comments and make request->tail a conservative
estimate as suggested by Daniel Vetter.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: resolve conflicts with retirement defering and the lack of
the autoreport head removal (that will go in through -fixes).] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dave Airlie [Tue, 14 Feb 2012 14:16:00 +0000 (14:16 +0000)]
Merge tag 'drm-intel-next-2012-02-07' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next
* tag 'drm-intel-next-2012-02-07' of git://people.freedesktop.org/~danvet/drm-intel: (29 commits)
drm/i915: Handle unmappable buffers during error state capture
drm/i915: rewrite shmem_pread_slow to use copy_to_user
drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
drm/i915: fall through pwrite_gtt_slow to the shmem slow path
drm/i915: add debugfs file for swizzling information
drm/i915: fix swizzle detection for gen3
drm/i915: Remove the upper limit on the bo size for mapping into the CPU domain
drm/i915: add per-ring fault reg to error_state
drm/i915: reject GTT domain in relocations
drm/i915: remove the i915_batchbuffer_info debugfs file
drm/i915: capture error_state also for stuck rings
drm/i915: refactor debugfs create functions
drm/i915: refactor debugfs open function
drm/i915: don't trash the gtt when running out of fences
drm/i915: Separate fence pin counting from normal bind pin counting
drm/i915/ringbuffer: kill snb blt workaround
drm/i915: collect more per ring error state
drm/i915: refactor ring error state capture to use arrays
drm/i915: switch ring->id to be a real id
drm/i915: set AUD_CONFIG N_value_index for DisplayPort
...
Yufeng Shen [Mon, 13 Feb 2012 22:36:54 +0000 (17:36 -0500)]
drm/i915: Fix race condition in accessing GMBUS
GMBUS has several ports and each has it's own corresponding
I2C adpater. When multiple I2C adapters call gmbus_xfer() at
the same time there is a race condition in using the underlying
GMBUS controller. Fixing this by adding a mutex lock when calling
gmbus_xfer().
v2: Moved gmbus_mutex below intel_gmbus and added comments.
Rebased to drm-intel-next-queued.
Signed-off-by: Yufeng Shen <miletus@chromium.org>
[danvet: Shortened the gmbus_mutex comment a bit and add the patch
revision comment to the commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Wu Fengguang [Tue, 14 Feb 2012 03:45:36 +0000 (11:45 +0800)]
drm/i915: add a "force-dvi" HDMI audio mode
When HDMI-DVI converter is used, it's not only necessary to turn off
audio, but also to disable HDMI_MODE_SELECT and video infoframe. Since
the DVI mode is mainly tied to audio functionality from end user POV,
add a new "force-dvi" audio mode:
xrandr --output HDMI1 --set audio force-dvi
Note that most users won't need to set this and happily rely on the EDID
based DVI auto detection.
Reported-by: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Sean Paul [Mon, 13 Feb 2012 18:14:51 +0000 (13:14 -0500)]
drm/i915: Don't lock panel registers when downclocking
This patch replaces the locking from the downclock routines with an assert
to ensure the registers are indeed unlocked. Without this patch, pre-SNB
devices would lock the registers when downclocking which would cause a
WARNING on suspend/resume with downclocking enabled.
Note: To hit this bug, you need to have lvds downclocking enabled.
Signed-off-by: Sean Paul <seanpaul@chromium.org> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jerome Glisse [Fri, 16 Dec 2011 22:03:42 +0000 (17:03 -0500)]
drm/radeon: add support for evergreen/ni tiling informations v11
evergreen and northern island gpu needs more informations for 2D tiling
than previous r6xx/r7xx. Add field to tiling ioctl to allow userspace
to provide those.
The v8 cs checking change to track color view on r6xx/r7xx doesn't
affect old userspace as old userspace always emited 0 for this register.
v2 fix r6xx/r7xx 2D tiling computation
v3 fix r6xx/r7xx height align for untiled surface & add support for
tile split on evergreen and newer
v4 improve tiling debugging output
v5 fix tile split code for evergreen and newer
v6 set proper tile split for crtc register
v7 fix tile split limit value
v8 add COLOR_VIEW checking to r6xx/r7xx checker, add evergreen cs
checking, update safe reg for r600, evergreen and cayman.
Evergreen checking need some work around for stencil alignment
issues
v9 fix tile split value range, fix compressed texture handling and
mipmap calculation, allow evergreen check to be silencious in
front of current broken userspace (depth/stencil alignment issue)
v10 fix eg 3d texture and compressed texture, fix r600 depth array,
fix r600 color view computation, add support for evergreen stencil
split
v11 more verbose debugging in some case
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
will incorrectly patch the command stream for certain regs.
v4: agd5f: add warning if safe reg check fails for copy_dw
v5: agd5f: add stricter checking for 6xx/7xx
v6: agd5f: add range checking for copy_dw on eg+,
add sx_surface_sync to safe reg list for 7xx.
v7: agd5f: add stricter checking for eg+
Signed-off-by: Marek Olšák <maraeo@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Mon, 13 Feb 2012 12:04:11 +0000 (12:04 +0000)]
Merge branch 'drm-vmware-next' into drm-core-next
* drm-vmware-next:
drm/vmwgfx: Bump driver minor
vmwgfx: Move function declaration to correct header
drm/vmwgfx: Treat out-of-range initial width and height as host errors
vmwgfx: Pick up the initial size from the width and height regs
vmwgfx: Add page flip support
vmwgfx: Pipe fence out of screen object dirty functions
vmwgfx: Make it possible to get fence from execbuf
vmwgfx: Clean up pending event references to struct drm_file objects on close
vmwgfx: Rework fence event action
vmwgfx: Move function declaration to correct header
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/vmwgfx: Treat out-of-range initial width and height as host errors
And assign the initial width and height to the minimum in that case.
Strange values (-1) from these registers have been reported by users.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
vmwgfx: Pick up the initial size from the width and height regs
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
vmwgfx: Pipe fence out of screen object dirty functions
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
vmwgfx: Make it possible to get fence from execbuf
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
vmwgfx: Clean up pending event references to struct drm_file objects on close
Pending events may have stale pointer references to struct drm_file objects
after a file has been closed, but before the event is supposed to be
attached to the drm file. Remove such events on file close.
Tested with "modetest".
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter [Fri, 27 Jan 2012 21:40:51 +0000 (22:40 +0100)]
drm/modes: do not enforce an odd vtotal for interlaced modes
CEA actually specifies an interlaced mode with even vtotal and
supplies a diagram showing how this is supposed to work.
Note that interlaced modes with an even vtotal seem to be a fairly
recent invention. All modelines lore I could dig up with googling says
that vtotal for interlaced modes _needs_ to be odd. But the even
modelines in CEA are not a spec-bug, there's a figure in CEA-861-E
called "Figure 5 Special Interlaced Video Format Timing (Even Vtotal)"
that explains how it's supposed to work. Furthermore intel Bspec
explicitly mentions that both odd and even interlaced vtotal are
supported (VTOTAL register in the south display engine of PCH split
chips).
Acked-by: Adam Jackson <ajax@redhat.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter [Thu, 26 Jan 2012 10:41:11 +0000 (11:41 +0100)]
drm/i915: fix up locking inconsistency around gem_do_init
The locking in our setup and teardown paths is rather arbitrary, but
generally we try to protect gem stuff with dev->struct_mutex. Further,
the ums/gem ioctl to setup gem _does_ take the look. So fix up this
benign inconsistency.
Notice while reading through code.
v2: Rebased on top of the ppgtt code.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 25 Jan 2012 13:04:00 +0000 (14:04 +0100)]
drm/i915: enable forcewake voodoo also for gen6
We still have reports of missed irqs even on Sandybridge with the
HWSTAM workaround in place. Testing by the bug reporter gets rid of
them with the forcewake voodoo and no HWSTAM writes.
Because I've slightly botched the rebasing I've left out the ACTHD
readback which is also required to get IVB working. Seems to still
work on the tester's machine, so I think we should go with the more
minmal approach on SNB. Especially since I've only found weak evidence
for holding forcewake while waiting for an interrupt to arrive, but
none for the ACTHD readback.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45181
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45332 Tested-by: Nicolas Kalkhof nkalkhof()at()web.de Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 25 Jan 2012 15:32:49 +0000 (16:32 +0100)]
drm/i915: fixup seqno allocation logic for lazy_request
Currently we reserve seqnos only when we emit the request to the ring
(by bumping dev_priv->next_seqno), but start using it much earlier for
ring->oustanding_lazy_request. When 2 threads compete for the gpu and
run on two different rings (e.g. ddx on blitter vs. compositor)
hilarity ensued, especially when we get constantly interrupted while
reserving buffers.
This patch fixes up the seqno reservation logic by moving it into
i915_gem_next_request_seqno. The ring->add_request functions now
superflously still return the new seqno through a pointer, that will
be refactored in the next patch.
Note that with this change we now unconditionally allocate a seqno,
even when ->add_request might fail because the rings are full and the
gpu died. But this does not open up a new can of worms because we can
already leave behind an outstanding_request_seqno if e.g. the caller
gets interrupted with a signal while stalling for the gpu in the
eviciton paths. And with the bugfix we only ever have one seqno
allocated per ring (and only that ring), so there are no ordering
issues with multiple outstanding seqnos on the same ring.
v2: Keep i915_gem_get_seqno (but move it to i915_gem.c) to make it
clear that we only have one seqno counter for all rings. Suggested by
Chris Wilson.
v3: As suggested by Chris Wilson use i915_gem_next_request_seqno
instead of ring->oustanding_lazy_request to make the follow-up
refactoring more clearly correct. Also improve the commit message
with issues discussed on irc.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45181 Tested-by: Nicolas Kalkhof nkalkhof()at()web.de Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Thu, 9 Feb 2012 09:15:20 +0000 (10:15 +0100)]
drm/i915: check gtfifodbg after possibly failed writes
If we don't have a sufficient number of free entries in the FIFO, we
proceed to do a write anyway. With this check we should have a clue if
that write actually failed or not.
After some discussion with Daniel Vetter regarding his original
complaint, we agreed upon this.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Thu, 9 Feb 2012 09:15:19 +0000 (10:15 +0100)]
drm/i915: catch gtfifo errors on forcewake_put
This is similar to a patch I wrote several months ago. It's been updated
for the new FORCEWAKE_MT. As recommended by Chris Wilson, use WARN()
instead of DRM_ERROR, so we can get a backtrace.
This shouldn't impact performance too much as the extra register read
can replace the POSTING_READ we had previously.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Thu, 9 Feb 2012 09:15:18 +0000 (10:15 +0100)]
drm/i915: use gtfifodbg
Add register definitions for GTFIFODBG, and clear it during init time to
make sure state is correct.
This register tells us if either a read, or a write occurred while the
fifo was full. It seems like bit 2 is an OR of bit 0 and bit 1, so we
check that as well, but the documents are not quite clear.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by (v1): Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 3 Feb 2012 19:47:15 +0000 (17:47 -0200)]
drm/i915: set interlaced bits for TRANSCONF
I'm not sure why they are needed (I didn't notice any difference in my
tests), but these bits are in our documentation and they are also set by
the Windows driver.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sat, 28 Jan 2012 22:48:46 +0000 (23:48 +0100)]
drm/i915: fixup overlay checks for interlaced modes
The drm core _really_ likes to frob around with the crtc timings and
put halfed vertical timings (in fields) in there. Which confuses the
overlay code, resulting in it's refusal to display anything at the
lower half of an interlaced pipe.
Tested-by: Christopher Egert <cme3000@gmail.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Peter Ross [Sat, 28 Jan 2012 13:49:26 +0000 (14:49 +0100)]
drm/i915: allow interlaced mode output on the HDMI connector
Signed-off-by: Peter Ross <pross@xvid.org> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Christopher Egert <cme3000@gmail.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Peter Ross [Sat, 28 Jan 2012 13:49:25 +0000 (14:49 +0100)]
drm/i915: allow interlaced mode output on the SDVO connector
Signed-off-by: Peter Ross <pross@xvid.org> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Christopher Egert <cme3000@gmail.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sat, 28 Jan 2012 13:49:24 +0000 (14:49 +0100)]
drm/i915: correctly program the VSYNCSHIFT register
The hw seems to use this to correctly insert the required delay
before/after an even/odd interlaced field. This might also explain
why we need to substract 1 half-line from vtotal - if the hw just
adds the delay programmend in VSYNCSHIFT the total frame time would be
about that too long.
These registers seems to only exist on gen4 and later. For paranoia
also program it to 0 for progressive modes, but according to
documentation the hw should just ignore it in this case.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sat, 28 Jan 2012 13:49:23 +0000 (14:49 +0100)]
drm/i915: don't allow interlaced pipeconf on gen2
gen2 doesn't support it, so be a bit more paranoid and add a check to
ensure that we never ever set an unsupported interlaced bit.
Ensure that userspace can't set an interlaced mode by resetting
interlace_allowed for the crt on gen2. dvo and lvds are the only other
encoders that gen2 supports and these already disallow interlaced
modes.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sat, 28 Jan 2012 13:49:22 +0000 (14:49 +0100)]
drm/i915: fixup interlaced support on ilk+
According to Paulo Zanoni, this is what windows does.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sat, 28 Jan 2012 13:49:21 +0000 (14:49 +0100)]
drm/i915: fixup interlaced vertical timings confusion, part 2
According to bspec, we need to subtract an additional line from vtotal
for interlaced modes and vblank_end needs to equal vtotal. All other
timing fields do not need this special treatment, so kill it.
Bspec says that this is irrespective of whether the interlaced mode
has an odd or even vtotal, both modes are supported.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Christopher Egert <cme3000@gmail.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sat, 28 Jan 2012 13:49:20 +0000 (14:49 +0100)]
drm/i915: fixup interlaced vertical timings confusion, part 1
We have a pretty decent confusion about vertical timings of interlaced
modes. Peter Ross has written a patch that makes interlace modes work
on a lot more platforms/output combinations by doubling the vertical
timings.
The issue with that patch is that core drm _does_ support specifying
whether we want these vertical timings in fields or frames, we just
haven't managed to consistently use this facility. The relavant
function is drm_mode_set_crtcinfo, which fills in the crtc timing
information.
The first thing to note is that the drm core keeps interlaced modes in
frames, but displays modelines in fields. So when the crtc modeset
helper copies over the mode into adjusted_mode it will already contain
vertical timings in half-frames. The result is that the fixup code in
intel_crtc_mode_fixup doesn't actually do anything (in most cases at
least).
Now gen3+ natively supports interlaced modes and wants the vertical
timings in frames. Which is what sdvo already fixes up, at least under
some conditions.
There are a few other place that demand vertical timings in fields
but never actually deal with interlaced modes, so use frame timings
for consistency, too. These are:
- lvds panel,
- dvo encoders - dvo is the only way gen2 could support interlaced
mode, but currently we don't support any encoders that do.
- tv out - despite that the tv dac sends out an interlaced signal it
expects a progressive mode pipe configuration.
All these encoders enforce progressive modes by resetting
interlace_allowed.
Hence we always want crtc vertical timings in frames. Enforce this in
our crtc mode_fixup function and rip out any redudant timing
computations from the encoders' mode_fixup function.
v2-4: Adjust the vertical timings a bit.
v5: Split out the 'subtract-one for interlaced' fixes.
v6: Clarify issues around tv-out and gen2.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Christopher Egert <cme3000@gmail.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sat, 28 Jan 2012 13:49:19 +0000 (14:49 +0100)]
drm/i915: clean up interlaced pipeconf bit definitions
- Clarify which bits are for which chips.
- Note that gen2 can't do interlaced directly (only via dvo tv chips).
- Move the mask to the top to make it clearer how wide this field is.
- Add defintions for all possible values.
This patch doesn't change any code.
v2: Paulo Zanoni pointed out that the pixel doubling modes do no
longer exist on ivb.
Cc: Peter Ross <pross@xvid.org> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Christopher Egert <cme3000@gmail.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Fri, 10 Feb 2012 15:52:55 +0000 (16:52 +0100)]
Merge remote-tracking branch 'airlied/drm-fixes' into drm-intel-next-queued
Back-merge from drm-fixes into drm-intel-next to sort out two things:
- interlaced support: -fixes contains a bugfix to correctly clear
interlaced configuration bits in case the bios sets up an interlaced
mode and we want to set up the progressive mode (current kernels
don't support interlaced). The actual feature work to support
interlaced depends upon (and conflicts with) this bugfix.
- forcewake voodoo to workaround missed IRQ issues: -fixes only enabled
this for ivybridge, but some recent bug reports indicate that we
need this on Sandybridge, too. But in a slightly different flavour
and with other fixes and reworks on top. Additionally there are some
forcewake cleanup patches heading to -next that would conflict with
currrent -fixes.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dave Airlie [Fri, 10 Feb 2012 08:35:19 +0000 (08:35 +0000)]
Merge branch 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux into drm-fixes
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux:
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT (v2)
drm/i915: no lvds quirk for AOpen MP45
drm/i915: Force explicit bpp selection for intel_dp_link_required
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT
drm/i915:: Disable FBC on SandyBridge
Daniel Vetter [Thu, 9 Feb 2012 19:53:27 +0000 (20:53 +0100)]
drm/i915: enable ppgtt
We want to unconditionally enable ppgtt for two reasons:
- Windows uses this on snb and later.
- We need the basic hw support to work before we can think about real
per-process address spaces and other cool features we want.
But Chris Wilson was complaining all over irc and intel-gfx that this
will blow up if we don't have a module option to disable it. Hence add
one, to prevent this.
ppgtt support seems to slightly change the timings and make crashy
things slightly more or less crashy. Now in my testing and the testing
this got on troublesome snb machines, it seems to have improved things
only. But on ivb it makes quite a few crashes happen much more often,
see
Luckily Eugeni Dodonov seems to have a set of workarounds that fix
this issue.
v2: Don't try to enable ppgtt on pre-snb.
v3: Pimp commit message and make Chris Wilson less grumpy by adding a
module option.
v4: New try at making Chris Wilson happy.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 9 Feb 2012 16:15:49 +0000 (17:15 +0100)]
drm/i915: ppgtt debugfs info
This was pretty usefull for debugging, might be useful for diagnosing
issues.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 9 Feb 2012 16:15:48 +0000 (17:15 +0100)]
drm/i915: ppgtt register definitions
Split out for easier cross-checking of the boring pieces with bspec.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 9 Feb 2012 16:15:47 +0000 (17:15 +0100)]
drm/i915: ppgtt binding/unbinding support
This adds support to bind/unbind objects and wires it up. Objects are
only put into the ppgtt when necessary, i.e. at execbuf time.
Objects are still unconditionally put into the global gtt.
v2: Kill the quick hack and explicitly pass cache_level to ppgtt_bind
like for the global gtt function. Noticed by Chris Wilson.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
projects / linux-beck.git / log