... even if the actual infoframe is smaller than the maximum possible
size.
If we don't write all the 32 DIP data bytes the InfoFrame ECC may not
be correctly calculated in some cases (e.g., when changing the port),
and this will lead to black screens on HDMI monitors. The ECC value is
generated by the hardware.
I don't see how this should break anything since we're writing 0 and
that should be the correct value, so this patch should be safe.
Notice that on IVB and older we actually have 64 bytes available for
VIDEO_DIP_DATA, but only bytes 0-31 actually store infoframe data: the
others are either read-only ECC values or marked as "reserved". On HSW
we only have 32 bytes, and the ECC value is stored on its own separate
read-only register. See BSpec.
This patch fixes bug #46761, which is marked as a regression
introduced by commit 4e89ee174bb2da341bf90a84321c7008a3c9210d:
drm/i915: set the DIP port on ibx_write_infoframe
Before commit 4e89 we were just failing to send AVI infoframes when we
needed to change the port, which can lead to black screens in some
cases. After commit 4e89 we started sending infoframes, but with a
possibly wrong ECC value. After this patch I hope we start sending
correct infoframes.
Version 2:
- Improve commit message
- Try to make the code more clear
Cc: stable@vger.kernel.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46761
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEcBAABAgAGBQJQX7MuAAoJEHm+PkMAQRiG0h0IAJURkrMCAQUxA+Ik66ReH89s
LQcVd0U9uL4UUOi7f5WR64Vf9Cfu6VVGX9ZKSvjpNskvlQaUQPMIt4pMe6g4X4dI
u0bApEy4XZz3nGabUAghIU8jJ8cDmhCG6kPpSiS7pi7KHc0yIa4WFtJRrIpGaIWT
xuK38YOiOHcSDRlLyWZzainMncQp/ixJdxnqVMTonkVLk0q0b84XzOr4/qlLE5lU
i+TsK3PRKdQXgvZ4CebL+srPBwWX1dmgP3VkeBloQbSSenSeELICbFWavn2ml+sF
GXi4dO93oNquL/Oy5SwI666T4uNcrRPaS+5X+xSZgBW/y2aQVJVJuNZg6ZP/uWk=
=0v2l
-----END PGP SIGNATURE-----
Merge tag 'v3.6-rc7' into drm-intel-next-queued
Manual backmerge of -rc7 to resolve a silent conflict leading to
compile failure in drivers/gpu/drm/i915/intel_hdmi.c.
This is due to the bugfix in -rc7:
commit b98b601672
Author: Wang Xingchao <xingchao.wang@intel.com>
Date: Thu Sep 13 07:43:22 2012 +0800
drm/i915: HDMI - Clear Audio Enable bit for Hot Plug
Since this code moved around a lot in -next git put that snippet at
the wrong spot. I've tried to fix this by making the conflict explicit
by merging a version for next with:
commit 3cce574f01
Author: Wang Xingchao <xingchao.wang@intel.com>
Date: Thu Sep 13 11:19:00 2012 +0800
drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally
But that failed to solve the entire problem. To avoid pushing out
further -nightly branch to our QA where this is broken, do the
backmerge and manually add the stuff git adds to -next from the patch
in -fixes.
Note that this doesn't show up in git's merge diff (and hence is also
not handled by git rerere), which adds to the reasons why I'd like to
fix this with a verbose backmerge. The git merge diff only shows a
bunch of trivial conflicts of the "code changed in lines next to each
another" kind.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should never happen, but the silent "return" makes me wonder
every time I try to debug InfoFrame bugs, so promote this to BUG() to
make sure people will complain if we ever break this.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel writes:
Essentially just flush my -fixes queue before I head off to xdc.
- gen2 regression fixer, we've enabled the lvds stuff too late. Not
causing any known issues, but this restores the sequence before a
refactor that landed in 3.5, and lvds is a fickle beast. And seriously,
who runs gen2 still ...
- downgrade a BUG to a WARN - we haven't root-caused/fixed the underlying
issue yet, but this should help bug reporters quite a bit.
- properly disable hdmi audio - we've lost track of this, which resulted
in the alsa driver again losing track of the unplug event.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: HDMI - Clear Audio Enable bit for Hot Plug
drm/i915: Reduce a pin-leak BUG into a WARN
drm/i915: enable lvds pin pairs before dpll on gen2
This fixes the gpio reset problem so the Retina MBP works, but avoids
breaking the Dell systems. Ben will work on a better solution for 3.7.
Tested by me on retina MBP.
Signed-off-by: Dave Airlie <airlied@redhat.com>
fixes a resume regression on pre-r6xx asics.
* 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: Prevent leak of scratch register on resume from suspend
Cards typically have 5-7 scratch registers; one of these is reserved for
rdev->rptr_save_reg. Unfortunately the reservation is done in function
r100_cp_init, which is called by all drivers except r600 - and this
function is also invoked on resume from suspend. After several resumes,
no scratch registers are free and graphics acceleration is disabled.
Dmesg then reports either:
*ERROR* radeon: cp failed to get scratch reg (-22).
*ERROR* radeon: cp isn't working(-22).
radeon 0000:01:00.0: failed initializing CP (-22).
or:
*ERROR* radeon: failed to get scratch reg (-22).
*ERROR* radeon: failed testing IB on GFX ring (-22).
*ERROR* ib ring test failed (-22).
The chain of calls on boot for all except r600 is:
radeon_init -> ... -> (rXXX_init) -> rXXX_startup -> r100_cp_init
The chain of calls on resume for all except r600 is:
rXXX_resume -> rXXX_startup -> r100_cp_init.
R600 correctly allocates rptr_save_reg in r600_init (ie once only, not
in resume). However moving the code into the init functions for all
drivers means touching 4 drivers. So instead, this patch just adds a
test in r100_cp_init to avoid reallocating on resume. As the rdev
structure is allocated via kzalloc in radeon_driver_load_kms, and zero
is not a valid registerid, zero safely implies not-yet-allocated.
This issue appears to have been introduced in c7eff978 (3.6.0-rcN)
Signed-off-by: Simon Kitching <skitching@vonos.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Somehow this hunk got dropped from my last patch. We do not have the
rc6_attrs when there is no CONFIG_PM so this causes a compilation error.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we make the simplification of using a power-of-two size for the
execbuffer handle-to-object TLB, we should validate that this is actually
true and so clarify that premise.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Clear Audio Enable bit to trigger unsolicated event to notify Audio
Driver part the HDMI hot plug change. The patch fixed the bug when
remove HDMI cable the bit was not cleared correctly.
In intel_enable_hdmi(), if intel_hdmi->has_audio been true, the "Audio enable bit" will
be set to trigger unsolicated event to notify Alsa driver the change.
intel_hdmi->has_audio will be reset to false from intel_hdmi_detect() after
remove the hdmi cable, here's debug log:
[ 187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2
[ 187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0
so when comes back to intel_disable_hdmi(), the "Audio enable bit" will not be cleared. And this
cause the eld infomation and pin presence doesnot update accordingly in alsa driver side.
This patch will also trigger unsolicated event to alsa driver to notify the hot plug event:
[ 187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1
[ 187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0
Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By providing a callback for when we need to bind the pages, and then
release them again later, we can shorten the amount of time we hold the
foreign pages mapped and pinned, and importantly the dmabuf objects then
behave as any other normal object with respect to the shrinker and
memory management.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Hopefully this makes userspace slightly less confused about us
frobbing the dpms state behind its back. Yeah, it would be better
to be more careful with not changing the dpms state, but that is
quite more invasive.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... because our current set_mode implementation doesn't bother to adjust
for the dpms state, we just forcefully update it. So stop pretending that
we're better than we are and rip out this extranous call.
Note that this totally confuses userspace, because the exposed connector
property isn't actually updated ...
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because they should have been disabled when shutting down the display
pipe previously. To ensure that this is the case, add a few assserts
instead of unconditionally disabling the fdi link.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Even with the old crtc helper code we should have disabled all
encoders on that pipe by now, and with the new code this would
definitely paper over a bug. We already have the necessary checks
in place in intel_disable_transcoder, so if we accidentally leave
a pch port on, this will be caught.
Hence just rip this all out.
Note that up to the patch in this giant modeset series that removes
the LVDS special case to avoid disabling LVDS in the encoder->prepare
callback ("drm/i915/lvds: ditch ->prepare special case"), this was not
the case for all outputs.
Also note that in
commit 1b3c7a47f9
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date: Wed Nov 25 13:09:38 2009 +0800
drm/i915: Fix LVDS stability issue on Ironlake
this was already discovered independently and worked around. How I
bloody hate this entire mess of cludges piled on top of other cludges.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the future we may like to experiment with using a WC map of the GTT
portion. However, that will conflict with i915.ko mapping the entire bar
as UC in order to access the GPU registers. Instead we can shrink the
register ioremap to only map the register block.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by (IVB): Ben Widawsky <ben@bwidawsk.net>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Squashed-in follow-up fix for gen2/3 registers file size from
Chris Wilson.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is useful for userspace utilities which wish to use the previous
interface, specifically for micromanaging the increase/decrease steps by
setting min == max.
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>
Provide a standardized sysfs interface for setting min, and max
frequencies. The code which reads the limits were lifted from the
debugfs files. As a brief explanation, the limits are similar to the CPU
p-states. We have 3 states:
RP0 - ie. max frequency
RP1 - ie. "preferred min" frequency
RPn - seriously lowest frequency
Initially Daniel asked me to clamp the writes to supported values, but
in conforming to the way the cpufreq drivers seem to work, instead
return -EINVAL (noticed by Jesse in discussion).
The values can be used by userspace wishing to control the limits of the
GPU (see the CC list for people who care).
v4: Make exceeding the soft limits return -EINVAL as well (Daniel)
v3: bug fix (Ben) - was passing the MHz value to gen6_set_rps instead of
the step value. To fix, deal only with step values by doing the divide
at the top.
v2: add the dropped mutex_unlock in error cases (Chris)
EINVAL on both too min, or too max (Daniel)
v2 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This has been tons of fun to figure out with git blame. The first
notion of this code block goes back to the original cpu edp enabling
for ilk in
commit 32f9d658ae
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date: Fri Jul 24 01:00:32 2009 +0800
drm/i915: Add eDP support on IGDNG mobile chip
Two things are notable in this commit wrt to the this edp special
case:
- The IS_eDP check _only_ fires for DP A, i.e. cpu edp ports.
- The cpu edp port is disabled at the top of the dp_link_down function.
My theory is that these hacks was added to work around the completely
different modeset sequence for cpu edp ports compared to pch edp
ports. With the cpu edp confusion on ilk (and snb/ivb) now fixed up,
this shouldn't be required any more.
The really interesting question is how this special cases survived
this long in the code. The first step is declaring the pch port D as
eDP if it's used for an internal panel:
commit b329530ca7
Author: Adam Jackson <ajax@redhat.com>
Date: Fri Jul 16 14:46:28 2010 -0400
drm/i915/dp: Correctly report eDP in the core connector type
This commit unfortunately failed to notice that not all edp ports are
created equal. Then follow a flurry of refactorings, culminating in a
patch from Keith Packard which resulted in the current logic (by
making it "correct" for all platforms that have edp):
commit 417e822dee
Author: Keith Packard <keithp@keithp.com>
Date: Tue Nov 1 19:54:11 2011 -0700
drm/i915: Treat PCH eDP like DP in most places
None of these cleanups or refactorings supply any reason why we need
this code, they've simply carried it on as-is.
Hence presume it might be harmful with the current code and rip it
out. We do rewrite the link training bits completely anyway when
re-training the link.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The exec_list is of type drm_i915_gem_exec_object2 and so casting it to
a drm_i915_gem_relocation_entry is very confusing!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is rather a hack to fix brightness hotkeys on a Clevo laptop. CADL is not
used anywhere in the driver code at the moment, but it could be used in BIOS as
is the case with the Clevo laptop.
The Clevo B7130 requires the CADL field to contain at least the ID of
the LCD device. If this field is empty, the ACPI methods that are called
on pressing brightness / display switching hotkeys will not trigger a
notification. As a result, it appears as no hotkey has been pressed.
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=45452
Tested-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
See bspec, Vol3 Part2, Section 1.1.3 "Display Mode Set Sequence". This
applies to all platforms where we currently support eDP on, i.e. ilk,
snb & ivb.
Without this change we fail to light up the eDP port on previously
unused crtcs (likely because something is stuck on the old pipe), and
we also fail to properly disable the old pipe (i.e. bit 30 in the
PIPECONF register is stuck as set until the next reboot).
v2: Rebased on top of the edp panel off sequence changes in 3.6-rc2.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=44001
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These have been added because dp links are fiddle things and don't
like it when we try to re-train an enabled output (or disable a
disabled output harder). And because the crtc helper code is
ridiculously bad add tracking the modeset state.
But with the new code in place it is simply a bug to disable a disabled
encoder or to enable an enabled encoder again. Hence convert these to
WARNs (and bail out for safety), but flatten all conditionals in the
code itself.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the previous patch to clean up where exactly these two functions
are getting called, this patch can tackle the enable/disable code
itself:
- WARN if the port enable bit is in the wrong state or if the edp pll
bit is in the wrong state, just for paranoia's sake.
- Don't disable the edp pll harder in the modeset functions just for
fun.
- Don't set the edp pll enable flag in intel_dp->DP in modeset, do
that while changing the actual hw state. We do the same with the
actual port enable bit, so this is a bit more consistent.
- Track the current DP register value when setting things up and add
some comments how intel_dp->DP is used in the disable code.
v2: Be more careful with resetting intel_dp->DP - otherwise dpms
off->on will fail spectacularly, becuase we enable the eDP port when
we should only enable the eDP pll.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By using the new pre_enable/post_disable functions.
To ensure that we only frob the cpu edp pll while the pipe is off add
the relevant asserts. Thanks to the new output state staging, this is
now really easy.
With this fixed we can now finally rip out the special-case handling
in the dp dpms code and replace it by the common intel_connector_dpms.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The cpu eDP encoder has some horrible hacks to set up the DP pll at
the right time. To be able to move them to the right place, add some
more encoder callbacks so that this can happen at the right time.
LVDS has some similar funky hacks, but that would require more work
(we need to move around the pll setup a bit). Hence for now only
wire these new callbacks up for ilk+ - we only have cpu eDP on these
platforms.
v2: Bikeshed the vtable ordering, requested by Chris Wilson.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's bogus.
If I've followed the history of this piece of code correctly, i.e. the
initial register write with the following vblank wait, this goes all
the way back to the original enabling of DP support in
commit a4fc5ed698
Author: Keith Packard <keithp@keithp.com>
Date: Tue Apr 7 16:16:42 2009 -0700
drm/i915: Add Display Port support
Unfortunately it seems to be nothing more than glorified duct-tape and
sometimes actively harmful. Adam Jackson noticed this for CPT
platforms with
commit e85194641b
Author: Adam Jackson <ajax@redhat.com>
Date: Thu Jul 21 17:48:38 2011 -0400
drm/i915/dp: Don't turn CPT DP ports on too early
Unfortunately this kept the code around for ilk and gm45.
The specific failure case I'm seeing here is that after a dpms off/on
cycle we have the bits from the last link training (hopefully
successful link training) set in intel_dp->DP. This is requiered so
that complete_link_train can enable the port with the right tuning
values.
Unfortunately writing these again to the disabled port at dpms on time
kills the port somehow until it's disabled - dp link training fails in
an endless loop without this patch on my mobile ilk and gm45.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51493
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the new "standardized" sysfs interfaces we need to be a bit more
careful about setting the RPS values.
Because the sysfs code and the rps workqueue can run at the same time,
if the sysfs setter wins the race to the mutex, the workqueue can come
in and set a value which is out of range (ie. we're no longer protecting
by RPINTLIM).
I was not able to actually make this error occur in testing.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In order to keep our cached values in sync with the hardware, we need a
posting read here.
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Userspace applications such as PowerTOP are interesting in being able to
read the current GPU frequency. The patch itself sets up a generic array
for gen6 attributes so we can easily add other items in the future (and
it also happens to be just about the cleanest way to do this).
The patch is a nice addition to
commit 1ac02185dff3afac146d745ba220dc6672d1d162
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Aug 30 13:26:48 2012 +0200
drm/i915: add a tracepoint for gpu frequency changes
Reading the GPU frequncy can be done by reading a file like:
/sys/class/drm/card0/render_frequency_mhz
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>
Magic numbers are bad mmmkay. In this case in particular the value is
especially weird because the docs say multiple things. We'll need this
value for sysfs, so extracting it is useful for that as well.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
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>
Name variables a bit better for copy-pasters. This got turned up as part
of review for upcoming sysfs patches.
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>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: resolved conflicts due to missing some earlier patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because declaring a variable in the beginning of the function, then
initializing it 100 lines later, then using it 100 lines later does
not make our code look good IMHO.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because ironlake_crtc_mode_set is a giant function that used to have
404 lines. Let's try to make it less complex/confusing.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rather than have multiple data structures for describing our page layout
in conjunction with the array of pages, we can migrate all users over to
a scatterlist.
One major advantage, other than unifying the page tracking structures,
this offers is that we replace the vmalloc'ed array (which can be up to
a megabyte in size) with a chain of individual pages which helps reduce
memory pressure.
The disadvantage is that we then do not have a simple array to iterate,
or to access randomly. The common case for this is in the relocation
processing, which will typically fit within a single scatterlist page
and so be almost the same cost as the simple array. For iterating over
the array, the extra function call could be optimised away, but in
reality is an insignificant cost of either binding the pages, or
performing the pwrite/pread.
v2: Fix drm_clflush_sg() to not invoke wbinvd as well! And fix the
trivial compile error from rebasing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
beneath us, and so we can simplify the code for iterating over the pages.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
jeneath us, and so we can simplify the code for iterating over the pages.
Note: The old code had such complicated page refcounting since it used
obj->pages as a micro-optimization if it's there, but that could
(before this patch) disappear when we drop the dev->struct_mutex.
Hence some manual page refcounting was required for the slow path,
complicated by the fact that pages returned by shmem_read_mapping_page
already have a pageref, which needs to be dropped again.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Added note to explain the question Ben raised in review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to refcount our pages in order to prevent reaping them at
inopportune times, such as when they currently vmapped or exported to
another driver. However, we also wish to keep the lazy deallocation of
our pages so we need to take a pin/unpinned approach rather than a
simple refcount.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In order to specialise functions depending upon the type of object, we
can attach vfuncs to each object via a new ->ops pointer.
For instance, this will be used in future patches to only bind pages from
a dma-buf for the duration that the object is used by the GPU - and so
prevent them from pinning those pages for the entire of the object.
v2: Bonus comments.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 991083ba60.
We discovered this causes problem on some Dell eDP laptops, so Apple
lose out for now, I might try and whip up a dmi based workaround for 3.6
but I'm not sure I'll get time.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel writes:
"The big ticket item here is the new i915 modeset infrastructure.
Shockingly it didn't not blow up all over the place (i.e. I've managed to
fix the ugly issues before merging). 1-2 smaller corner cases broke, but
we have patches. Also, there's tons of patches on top of this that clean
out cruft and fix a few bugs that couldn't be fixed with the crtc helper
based stuff. So more stuff to come ;-)
Also a few other things:
- Tiny fix in the fb helper to go through the official dpms interface
instead of calling the crtc helper code.
- forcewake code frobbery from Ben, code should be more in-line with
what Windows does now.
- fixes for the render ring flush on hsw (Paulo)
- gpu frequency tracepoint
- vlv forcewake changes to better align it with our understanding of the
forcewake magic.
- a few smaller cleanups"
+ 2 fixes.
* 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: (78 commits)
drm/i915: fix OOPS in lid_notify
drm/i915: correctly update crtc->x/y in set_base
drm/fb helper: don't call drm_helper_connector_dpms directly
drm/i915: improve modeset state checking after dpms calls
drm/i915: add tons of modeset state checks
drm/i915: no longer call drm_helper_resume_force_mode
drm/i915: disable all crtcs at suspend time
drm/i915: push commit_output_state past the crtc/encoder preparing
drm/i915: switch the load detect code to the staged modeset config
drm/i915: WARN if the pipe won't turn off
drm/i915: s/intel_encoder_disable/intel_encoder_noop
drm/i915: push commit_output_state past crtc disabling
drm/i915: implement new set_mode code flow
drm/i915: compute masks of crtcs affected in set_mode
drm/i915: use staged outuput config in lvds->mode_fixup
drm/i915: use staged outuput config in tv->mode_fixup
drm/i915: extract adjusted mode computation
drm/i915: move output commit and crtc disabling into set_mode
drm/i915: remove crtc disabling special case
drm/i915: push crtc->fb update into pipe_set_base
...
We hit this a lot with i915 and although we'd like to engineer things to hit
it a lot less, this commit at least makes it consume a few less cycles.
from something containing
movzwl 0x0(%rip),%r10d
to
add %r8,%rdx
I only noticed it while using perf to profile something else.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The SH Mobile LCD controller (LCDC) DRM driver supports the main
graphics plane in RGB and YUV formats, as well as the overlay planes (in
alpha-blending mode only).
Only flat panel outputs using the parallel interface are supported.
Support for SYS panels, HDMI and DSI is currently not implemented.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
This patchset introduces a set of helper function for implementing the KMS
framebuffer layer for drivers which use the DRM GEM CMA helper function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
[Make DRM_KMS_CMA_HELPER a boolean Kconfig option]
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Many embedded drm devices do not have a IOMMU and no dedicated
memory for graphics. These devices use CMA (Contiguous Memory
Allocator) backed graphics memory. This patch provides helper
functions to be able to share the code. The code technically does
not depend on CMA as the backend allocator, the name has been chosen
because CMA makes for a nice, short but still descriptive function
prefix.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Lars-Peter Clausen <lars@metafoo.de>
[Make DRM_GEM_CMA_HELPER a boolean Kconfig option]
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
This goes back to
commit c1c7af6089
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Sep 10 15:28:03 2009 -0700
drm/i915: force mode set at lid open time
It was used to fix an issue on a i915GM based Thinkpad X41, which
somehow clobbered the modeset state at lid close time. Since then
massive amounts of things changed: Tons of fixes to the modeset
sequence, OpRegion support, better integration with the acpi code.
Especially OpRegion /should/ allow us to control the display hw
cooperatively with the firmware, without the firmware clobbering the
hw state behind our backs.
So it's dubious whether we still need this.
The second issue is that it's unclear who's responsibility it actually
is to restore the mode - Chris Wilson suggests to just emit a hotplug
event and let userspace figure things out.
The real reason I've stumbled over this is that the new modeset code
breaks drm_helper_resume_force_mode - it OOPSes derefing a NULL vfunc
pointer. The reason this wasn't caught in testing earlier is that in
commit c9354c85c1
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon Nov 2 09:29:55 2009 -0800
i915: fix intel graphics suspend breakage due to resume/lid event
confusion
logic was added to _not_ restore the modeset state after a resume. And
since most machines are configured to auto-suspend on lid-close, this
neatly papered over the issue.
Summarizing, this shouldn't be required on any platform supporting
OpRegion. And none of the really old machines I have here seem to
require it either. Hence I'm inclined to just rip it out.
But in case that there are really firmwares out there that clobber the
hw state, replace it with a call to intel_modset_check_state. This
will ensure that we catch any issues as soon as they happen.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While reworking the modeset sequence, this got lost in
commit 25c5b2665f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Jul 8 22:08:04 2012 +0200
drm/i915: implement new set_mode code flow
I've noticed this because some Xorg versions seem to set up a new mode
with every crtc at (0,0) and then pan to the right multi-monitor
setup. And since some hacks of mine added more calls to mode_set using
the stored crtc->x/y my multi-screen setup blew up.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 985f61f7ee.
This commit fixed certain cases, but ended up regressing others
due to limitations in the current KMS API. A proper fix is too
invasive for 3.6. Push it back to 3.7.
Reported-by: Andres Freund <andres@anarazel.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Paulo Zanoni