This computes what exactly changed in the modeset configuration, i.e.
whether a full modeset is required or only an update of the
framebuffer base address or no change at all.
In the future we might add more checks for e.g. when only the output
mode changed, so that we could do a minimal modeset for outputs that
support this. Like the lvds/eDP panels where we only need to update
the panel fitter.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At the end this won't be of much use to us, but meanwhile just extract
it to get a better overview of what exactly set_config does.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_crtc_set_config is an unwidly beast and is in serious need of
some function extraction. To facilitate that, introduce a struct to
keep track of all the state involved. Atm it doesn't do much more than
keep track of all the allocated memory.
v2: Apply some bikeshed to intel_set_config_free, as suggested by
Jesse Barnes.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Many BIOSen forget to turn on the pipe A after resume (because they
actually don't turn on anything), so we have to do that ourselves when
sanitizing the hw state.
I've discovered this due to the recent addition of a pipe WARN that
takes the force quirk into account.
v2: Actually try to enable the pipe with a proper configuration instead
of simpyl switching it on with whatever random state the bios left it
in after resume.
v3: Fixup rebase conflict - the load_detect functions have lost their
encoder argument.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We now track the connector state in encoder->connectors_active, and
because the DP output can't be cloned, that is sufficient to track the
link state. Hence use this instead of adding yet another modeset state
variable with dubious semantics at driver load and resume time.
Also, connectors_active should only ever be set when the encoder is
linked to a crtc, hence convert that crtc test into a WARN.
v2: Rebase on top of struct intel_dp moving.
v3: The rebase accidentally killed the newly-introduced intel_dp->port
Noticed by Paulo Zanoni.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Afaict this has been used for two things:
- To prevent the crtc enable code from being run twice. We have now
intel_crtc->active to track this in a more precise way.
- To ensure the code copes correctly with the unknown hw state after
boot and resume. Thanks to the hw state readout and sanitize code we
have now a better way to handle this.
The only thing it still does is complicate our modeset state space.
Having outlived its usefullness, let it just die.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm we can only check the connector state after a dpms call - while
doing modeset with the copy&pasted crtc helper code things are too
ill-defined for proper checking. But the idea is very much to call
this check from the modeset code, too.
v2: Fix dpms check and don't presume that if the hw isn't on that it
must not be linked up with an encoder (it could simply be switched off
with the dpms state).
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... instead of resetting a few things and hoping that this will work
out.
To properly disable the output pipelines at the initial modeset after
resume or boot up we need to have an accurate picture of which outputs
are enabled and connected to which crtcs. Otherwise we risk disabling
things at the wrong time, which can lead to hangs (or at least royally
confused panels), both requiring a walk to the reset button to fix.
Hence read out the hw state with the freshly introduce get_hw_state
functions and then sanitize it afterwards.
For a full modeset readout (which would allow us to avoid the initial
modeset at boot up) a few things are still missing:
- Reading out the mode from the pipe, especially the dotclock
computation is quite some fun.
- Reading out the parameters for the stolen memory framebuffer and
wrapping it up.
- Reading out the pch pll connections - luckily the disable code
simply bails out if the crtc doesn't have a pch pll attached (even
for configurations that would need one).
This patch here turned up tons of smelly stuff around resume: We
restore tons of register in seemingly random way (well, not quite, but
we're not too careful either), which leaves the hw in a rather
ill-defined state: E.g. the port registers are sometimes
unconditionally restore (lvds, crt), leaving us with an active
encoder/connector but no active pipe connected to it. Luckily the hw
state sanitizer detects this madness and fixes things up a bit.
v2: When checking whether an encoder with active connectors has a crtc
wire up to it, check for both the crtc _and_ it's active state.
v3:
- Extract intel_sanitize_encoder.
- Manually disable active encoders without an active pipe.
v4: Correclty fix up the pipe<->plane mapping on machines where we
switch pipes/planes. Noticed by Chris Wilson, who also provided the
fixup.
v5: Spelling fix in a comment, noticed by Paulo Zanoni
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Similar to the sdvo code we poke the dvo encoder whether the output is
active. Safe that dvo encoders are not standardized, so this requires
a new callback into the dvo chip driver.
Hence implement that for all 6 dvo drivers.
v2: With the newly added ns2501 we now have 6 dvo drivers instead of
just 5 ...
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
SDVO is the first real special case - we support multiple outputs on
the same encoder and the encoder dpms state isn't the same as when
just disabling the outputs when the encoder is cloned.
Hence we need a real connector get_hw_state function which inquires
the sdvo encoder about its active outputs.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Note that even though this connector is cloneable we still can use the
exact same test to check whether the connector is on or whether the
encoder is enabled - both the dpms code and the encoder disable/enable
frob the exact same hw state.
For dvo/sdvo outputs, this will be different.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also add some macros to make the pipe computation a bit easier.
v2: I've mixed up the CPT and !CPT PORT_TO_PIPE macro variants ...
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It is all glorious if we try really hard to only enable/disable an
entire display pipe to ensure that everyting happens in the right
order. But if we don't know the output configuration when the driver
takes over, this will all be for vain because we'll make the hw angry
right on the first modeset - we don't know what outputs/ports are
enabled and hence have to disable everything in a rather ad-hoc way.
Hence we need to be able to read out the current hw state, so that we
can properly tear down the current hw state on the first modeset.
Obviously this is also a nice preparation for the fastboot work, where
we try to avoid the modeset on driver load if it matches what the hw
is currently using.
Furthermore we'll be using these functions to cross-check the actual
hw state with what we think it should be, to ensure that the modeset
state machine actually works as advertised.
This patch only contains the interface definitions and a little helper
for the simple case where we have a 1:1 encoder to connector mapping.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is the first tiny step towards cross-checking the entire modeset
state machine with WARNs. A crtc can only be enabled when it's
actually in use, i.e. crtc->active imlies crtc->enabled.
Unfortunately we can't (yet) check this when disabling the crtc,
because the crtc helpers are a bit slopy with updating state and
unconditionally update crtc->enabled before changing the hw state.
Fixing that requires quite some more work.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of going through the crtc helper function tables.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the new infrastructure we're doing this when enabling/disabling
the entire display pipe.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- We don't have the ->get_crtc callback.
- Call intel_encoder->disable directly.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Together with the static helper functions drm_crtc_prepare_encoders
and drm_encoder_disable (which will be simplified in the next patch,
but for now are 1:1 copies). Again, no changes beside new names for
these functions.
Also call our new set_mode instead of the crtc helper one now in all
the places we've done so far.
v2: Call the function just intel_set_mode to better differentia it
from intel_crtc_mode_set which really only does the ->mode_set step of
the entire modeset sequence on one crtc. Whereas this function does
the global change.
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also kill the error-path, we have a fixed connector->encoder mapping.
Unfortunately we can't rip out all the ->best_encoder callbacks, these
are all still used by the fb_helper. Neat helper layering violation there.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And the following static functions required by it:
drm_encoder_crtc_ok, drm_crtc_helper_disable
No changes safe for the s/drm/intel prefix change.
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We no longer need them. And now that all encoders are converted, we
can finally move the cpt modeset check to the right place - at the end
of the crtc_enable function.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All encoders are now converted so there's no need for these checks any
more.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Yeah, big patch but I couldn't come up with a neat idea of how to
split it up further, that wouldn't break dpms on cloned configs
somehow. But the changes in dvo/sdvo/crt are all pretty much
orthonogal, so it's not too bad a patch.
These are the only encoders that support cloning, which requires a few
special changes compared to the previous patches.
- Compute the desired state of the display pipe by walking all
connected encoders and checking whether any has active connectors.
To make this clearer, drop the old mode parameter to the crtc dpms
function and rename it to intel_crtc_update_dpms.
- There's the curious case of intel_crtc->dpms_mode. With the previous
patches to remove the overlay pipe A code and to rework the load
detect pipe code, the big users are gone. We still keep it to avoid
enabling the pipe twice, but we duplicate this logic with
crtc->active, too. Still, leave this for now and just push a fake
dpms mode into it that reflects the state of the display pipe.
Changes in the encoder dpms functions:
- We clamp the dpms state to the supported range right away. This is
escpecially important for the VGA outputs, where only older hw
supports the intermediate states. This (and the crt->adpa_reg patch)
allows us to unify the crt dpms code again between all variants
(gmch, vlv and pch).
- We only enable/disable the output for dvo/sdvo and leave the encoder
running. The encoder will be disabled/enabled when we switch the
state of the entire output pipeline (which will happen right away
for non-cloned setups). This way the duplication is reduced and
strange interaction when disabling output ports at the wrong time
avoided.
The dpms code for all three types of connectors contains a bit of
duplicated logic, but I think keeping these special cases separate is
simpler: CRT is the only one that hanldes intermediate dpms state
(which requires extra logic to enable/disable things in the right
order), and introducing some abstraction just to share the code
between dvo and sdvo smells like overkill. We can do that once someone
bothers to implement cloning for the more modern outputs. But I doubt
that this will ever happen.
v2: s/crtc/crt/_set_dpms, noticed by Paulo Zanoni.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Similar to crt, this doesn't convert the dpms functions.
Also similar to crt, we don't switch of the display pipe
for the intermediate modes, only DPMS_OFF is truely off.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
CRT is the first output which can be cloned, hence we cannot (yet)
move the dpms handling over to disable/enable. This requires some more
smarts in intel_crtc_dpms first to set the display pipe status
depening upon encoder->connectors_active of all connected encoders.
Because that will happen in a separate step, don't touch the dpms
functions, yet.
v2: Be careful about clearing the _DISABLE flags for intermediate dpms
modes - otherwise we might clobber the crt state when another (cloned)
connector gets enabled.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DP is the first encoder which isn't simple. As
commit d240f20f54
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Aug 13 15:43:26 2010 -0700
drm/i915: make sure eDP PLL is enabled at the right time
discovered, we need to enable the eDP PLL for the cpu port _before_ we
enable the pipes and planes. After a few more commits the current
solution is to enable the PLL in the dp mode_set function (because
this is the only encoder callback the crtc helper code calls before it
calls the crtc's commit function).
Now I suspect that we actually should enable/disable the entire cpu
eDP port before/after planes, but thanks to how the crtc helper code
assumes that you can disable an encoder without disabling it's crtc
right away, this won't work.
The result is that the current prepare/commit hooks don't touch the
eDP PLL, but instead it get's frobbed in dp_mode_set and in the dp
dpms function. Hence we need to keep things (at least for now)
bug-for-bug compatible by using our own special dp dpms function and
keep everything else more-or-less as-is (just using our own
infrastrucutre now).
This mess can only be cleaned up once we control the entire modeset
sequence and can move things around freely.
v2: Squash unsupported dpms modes to OFF at the beginning of the DP
dpms function.
v3: Need to set the dpms state to off in dp_disable, otherwise this
breaks the newly added WARNs ...
v4: Rebased against edp panel off sequence changes in 3.6-rc2
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the previous patch LVDS is also a simple case. Treat it
accordingly.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like hdmi tv outputs are simple: They only have 2 states and can't be
cloned. Hence give it the same treatment.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I've picked hdmi as the first encoder to convert because it's rather
simple:
- no cloning possible
- no differences between prepare/commit and dpms off/on switching.
A few changes are required to do so:
- Split up the dpms code into an enable/disable function and wire it
up with the intel encoder.
- Noop out the existing encoder prepare/commit functions used by the
crtc helper - our crtc enable/disable code now calls back into the
encoder enable/disable code at the right spot.
- Create new helper functions to handle dpms changes.
- Add intel_encoder->connectors_active to better track dpms state. Atm
this is unused, but it will be useful to correctly disable the
entire display pipe for cloned configurations. Also note that for
now this is only useful in the dpms code - thanks to the crtc
helper's dpms confusion across a modeset operation we can't (yet)
rely on this having a sensible value in all circumstances.
- Rip out the encoder helper dpms callback, if this is still getting
called somewhere we have a bug. The slight issue with that is that
the crtc helper abuses dpms off to disable unused functions. Hence
we also need to implement a default encoder disable function to do
just that with the new encoder->disable callback.
- Note that we drop the cpt modeset verification in the commit
callback, too. The right place to do this would be in the crtc's
enable function, _after_ all the encoders are set up. But because
not all encoders are converted yet, we can't do that. Hence disable
this check temporarily as a minor concession to bisectability.
v2: Squash the dpms mode to only the supported values -
connector->dpms is for internal tracking only, we can hence avoid
needless state-changes a bit whithout causing harm.
v3: Apply bikeshed to disable|enable_ddi, suggested by Paulo Zanoni.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just prep work, not yet put to some use.
Note that because we're still using the crtc helper to switch modes
(and their complicated way to do partial modesets), we need to call
the encoder's disable function unconditionally.
But once this is cleaned up we shouldn't call the encoder's disable
function unconditionally any more, because then we know that we'll
only call it if the encoder is actually enabled. Also note that we
then need to be careful about which crtc we're filtering the encoder
list on: We want to filter on the crtc of the _current_ mode, not the
one we're about to set up.
For the enabling side we need to do the same trick. And again, we
should be able to simplify this quite a bit when things have settled
into place.
Also note that this simply does not take cloning into account, so dpms
needs to be handled specially for the few outputs where we even bother
with it.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just impendance matching with the the crtc helper stuff.
... and somehow the design of this all ended up in this commit here,
too ;-)
The big plan is that this new set of crtc display_funcs take full
responsibility of modeset operations for the entire display output
pipeline (by calling down into object-specific callbacks and
functions). The platform-specific callbacks simply know best what the
proper order is.
This has the drawback that we can't do minimal change-overs any more
if a modeset just disables one encoder in a cloned configuration
(because we will only expose a disable/enable action that takes
down/sets up the entire crtc including all encoders). Imo that's the
only sane way to do it though:
- The use-case for this is pretty minimal, even when presenting (at
least sane people) should use a dual-screen output so that you can
see your notes on your panel. Clone mode is imo BS.
- With all the clone mode constrains, shared resources, and special
ordering requirements (which differ even on the same platform
sometimes for different outputs) there's no way we'd get this right
for all cases. Especially since this is a under-used feature.
- And to top it off: On haswell even dp link re-training requires us
to take down the entire display pipe - otherwise the chip dies.
So the only sane way is to do a full modeset on every crtc where the
output config changes in any way.
To support global modeset (i.e. set the configuration for all crtcs at
once) we'd then add one more function to allocate global and shared
objects in the best ways (e.g. fdi links, pch plls, ...). The crtc
functions would then simply use the pre-allocated stuff (and shouldn't
be able to fail, ever). We could even do all the object pinning in
there (and maybe try to defragment the global gtt if we fail)!
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because that's what we're essentially calling. This is the first step
in untangling the crtc_helper induced dpms handling mess we have - at
the crtc level we only have 2 states and the magic is just in
selecting which one (and atm there isn't even much magic, but on
recent platforms where not even the crt output has more than 2 states
we could do better).
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The original patch was actually incorrect in stubbing out the sysfs for
l3 parity.
commit 5ab3633d69
Author: Hunt Xu <mhuntxu@gmail.com>
Date: Sun Jul 1 03:45:07 2012 +0000
drm/i915: make rc6 in sysfs functions conditional
Unfortunately Hunt didn't respond to my review comments, and Daniel
sucked in the patch again ignoring. Worst of all, I'm too lazy to write
the patch for what I originally wanted, which was to keep rc6 sysfs even
without CONFIG_PM. This simpler patch does enough to enable us to add
more sysfs entries though.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Previously intel_panel_setup_backlight() would create a sysfs backlight
interface with max brightness of 1 if it was unable to figure out the max
backlight brightness. This rendered the backlight interface useless.
Do not create a dysfunctional backlight interface to begin with.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The same designer from the previous patch has told us to never read
FORCEWAKE. We only do this for the POSTING_READ(), so simply change that
to something within the same cacheline (for no reason in particular
other than it sounds nice). In the _mt case we can leverage
the gtfifodbg check for the POSTING_READ.
This partially reverts
commit 6af2d180f8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jul 26 16:24:50 2012 +0200
drm/i915: fix forcewake related hangs on snb
v2: commit message, comments about posting read from (Daniel)
Note: vlv forcewake doesn't need any changes for this special
treatment since FORCEWAKE_VLV is in a totally different register
range, and the readback FORCEWAKE_ACK_VLV readback that follows is in
the same range.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Added note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A designer familiar with the hardware has stated that the forcewake
timeout can theoretically be as high as a little over 1ms. Therefore we
modify our code to use 2ms (appropriate fudge and because we don't want
to round down).
Hopefully this can't prevent spurious timeouts.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Chris Wilson <chris@chris-wilson.oc.uk>
[danvet: again fix conflict with vlv patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As part of the advice given to us from the hardware designers regarding
the maximum wait time on the forcewake handshake we need to move from us
granularity to ms granularity. In earlier patches to do this, Jani
noticed that wait_for_us was properly converted to use cpu_relax(), but
wait_for was not.
The issue has existed since the introduction of the macro:
commit 913d8d1100
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat Aug 7 11:01:35 2010 +0100
drm/i915: Ensure that while(INREG()) are bounded (v2)
CC: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.oc.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's used all over the place, and we want to be able to play around with
the value, apparently. Note that it doesn't touch other timeouts of the
same value (like gtfifo, and thread C0 wait).
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.oc.uk>
[danvet: fixup conflict with vlv forcewake patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The sdvo hotplug support check and activation has worked by coincidence for
TMDS0. The boolean value returned by intel_sdvo_supports_hotplug() was
masked with a bit shifted by device number, which also should have been one
of SDVO_OUTPUT_* bits instead. Boolean true masked with 1 shifted by 0 just
happened to match SDVO_OUTPUT_TMDS0...
Get hotplug support as a bit mask, check the correct bits for support, and
use the correct bits for activating hotplug support.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Avoid constant wakeups caused by noisy irq lines when we don't even care
about the irq. This should be particularly useful for i945g/gm where the
hotplug has been disabled:
commit 768b107e4b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri May 4 11:29:56 2012 +0200
drm/i915: disable sdvo hotplug on i945g/gm
v2: While at it, remove the bogus hotplug_active read, and do not mask
hotplug_active[0] before checking whether the irq is needed, per discussion
with Daniel on IRC.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442
Tested-by: Dominik Köppl <dominik@devwork.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For code consolidation and future maintainability.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-and-Tested-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
<ickle> danvet: in the force wake, both DRM_ERRORs have the same string.
<ickle> useful for .txt shrinkage, horrible for debugging
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For some odd reasons, the vlv forcewake code is rather different from
all other platforms, with no clear justification. Adjust things:
- Don't check whether the gt is awake already (and bail out early), we
need to grab a forcewake anyway. Otherwise the chip might go to
sleep too early. And this would also screw up our forcewake
accounting.
- Like all other platforms, check whether the gt has cleared the
forcewake bit in the _ACK register before setting it again.
- Use _MASKED_BIT_ENABLE/DISABLE macros
- Only use bit0 of the forcewake reg, not all 16 bits.
- check the gtfifodb reg like on all other platforms in _put.
- Drop the POSTING_READs for consistency.
v2: Failure to git add ... again.
v3: Fixup the spelling fail a bit.
Tested-by: "Purushothaman, Vijay A" <vijay.a.purushothaman@intel.com>
Tested-by: "Widawsky, Benjamin" <benjamin.widawsky@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We've had and still have too many issues where the gpu turbo doesn't
quite to what it's supposed to do (or what we want it to do).
Adding a tracepoint to track when the desired gpu frequency changes
should help a lot in characterizing and understanding problematic
workloads.
Also, this should be fairly interesting for power tuning (and
especially noticing when the gpu is stuck in high frequencies, as has
happened in the past) and hence for integration into powertop and
similar tools.
Cc: Arjan van de Ven <arjan@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like with the equivalent change for gen6+ rps state, this helps in
clarifying the code (and in fixing a few places that have fallen through
the cracks in the locking review).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From Bspec, Vol 2a, Section 1.9.3.4 "PIPE_CONTROL", intro section
detailing the various workarounds:
"[DevIVB {W/A}, DevHSW {W/A}]: Pipe_control with CS-stall bit
set must be issued before a pipe-control command that has the State
Cache Invalidate bit set."
Note that public Bspec has different numbering, it's Vol2Part1,
Section 1.10.4.1 "PIPE_CONTROL" there.
There's also a second workaround for the PIPE_CONTROL command itself:
"[DevIVB, DevVLV, DevHSW] {WA}: Every 4th PIPE_CONTROL command, not
counting the PIPE_CONTROL with only read-cache-invalidate bit(s) set,
must have a CS_STALL bit set"
For simplicity we simply set the CS_STALL bit on every pipe_control on
gen7+
Note that this massively helps on some hsw machines, together with the
following patch to unconditionally set the CS_STALL bit on every
pipe_control it prevents a gpu hang every few seconds.
This is a regression that has been introduced in the pipe_control
cleanup:
commit 6c6cf5aa9c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 20 18:02:28 2012 +0100
drm/i915: Only apply the SNB pipe control w/a to gen6
It looks like the massive snb pipe_control workaround also papered
over any issues on ivb and hsw.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: squashed both workarounds together, pimped commit message
with Bsepc citations, regression commit citation and changed the
comment in the code a bit to clarify that we unconditionally set
CS_STALL to avoid being hurt by trying to be clever.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since gen 7+ now run the new gen7_render_ring_flush function.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For now, just a copy of gen6_render_ring_flush. Different gens have
different workarounds, so we want different functions.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise it just won't compile ...
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Avoid constant wakeups caused by noisy irq lines when we don't even care
about the irq. This should be particularly useful for i945g/gm where the
hotplug has been disabled:
commit 768b107e4b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri May 4 11:29:56 2012 +0200
drm/i915: disable sdvo hotplug on i945g/gm
v2: While at it, remove the bogus hotplug_active read, and do not mask
hotplug_active[0] before checking whether the irq is needed, per discussion
with Daniel on IRC.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442
Tested-by: Dominik Köppl <dominik@devwork.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In order to setup the i2c channel, we power up the panel
via ironlake_edp_panel_vdd_on, however it requires
intel_dp->panel_power_up_delay to be initialised,
which hasn't been setup yet.
So move things around so we set the panel power up
values first then init the i2c stuff.
This is one step to fixing the eDP panel in the MBP
from uninitialised state.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel writes:
"New stuff for -next. Highlights:
- prep patches for the modeset rework. Note that one of those patches
touches the fb helper in the common drm code.
- hasw hdmi audio support (Wang Xingchao)
- improved instdone dumping for gen7 (Ben)
- unbound tracking and a few follow-up patches from Chris
- dma_buf->begin/end_cpu_access plus fix for drm/udl (Dave)
- improve mmio error reporting for hsw
- prep patch for WQ_NON_REENTRANT removal (Tejun Heo)
"
* 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: (41 commits)
drm/i915: Remove __GFP_NO_KSWAPD
drm/i915: disable rc6 on ilk when vt-d is enabled
drm/i915: Avoid unbinding due to an interrupted pin_and_fence during execbuffer
drm/i915: Use new INSTDONE registers (Gen7+)
drm/i915: Add new INSTDONE registers
drm/i915: Extract reading INSTDONE
drm/i915: Use a non-blocking wait for set-to-domain ioctl
drm/i915: Juggle code order to ease flow of the next patch
drm/i915: Use cpu relocations if the object is in the GTT but not mappable
drm/i915: Extract general object init routine
drm/i915: Protect private gem objects from truncate (such as imported dmabuf)
drm/i915: Only pwrite through the GTT if there is space in the aperture
i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1
drm/i915: Find unclaimed MMIO writes.
drm/i915: Add ERR_INT to gen7 error state
drm/i915: Cantiga+ cannot handle a hsync front porch of 0
drm/i915: fix reassignment of variable "intel_dp->DP"
drm/i915: Try harder to allocate an mmap_offset
drm/i915: Show pin count in debugfs
drm/i915: Show (count, size) of purgeable objects in i915_gem_objects
...
When I pulled-in today's drm-intel-next into linux-next (next-20120824)
I saw this build-breakage:
drivers/gpu/drm/i915/i915_gem.c: In function 'i915_gem_object_get_pages_gtt':
drivers/gpu/drm/i915/i915_gem.c:1778:40: error: '__GFP_NO_KSWAPD' undeclared (first use in this function)
drivers/gpu/drm/i915/i915_gem.c:1778:40: note: each undeclared identifier is reported only once for each function it appears in
This is caused by commit ba099ef165f8 ("mm: remove __GFP_NO_KSWAPD")
and commit b6beae2c2014 ("mm: remove __GFP_NO_KSWAPD fixes") in
linux-next (next-20120824).
Fix this by removing __GFP_NO_KSWAPD from drm/i915 driver.
Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There was some merge conflicts in -next and they weren't so pretty, so
backmerge now to avoid them.
Conflicts:
drivers/gpu/drm/i915/i915_gem.c
drivers/gpu/drm/i915/intel_modes.c
It blows up. And hopefully this is the root-cause of the mysterious
rc6 related hang on ilk. For reference, the commit that enabled rc6 on
ilk again is:
commit 456470eb58
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Aug 8 23:35:40 2012 +0200
drm/i915: enable rc6 on ilk again
Reported-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we need to stall in order to complete the pin_and_fence operation
during execbuffer reservation, there is a high likelihood that the
operation will be interrupted by a signal (thanks X!). In order to
simplify the cleanup along that error path, the object was
unconditionally unbound and the error propagated. However, being
interrupted here is far more common than I would like and so we can
strive to avoid the extra work by eliminating the forced unbind.
v2: In discussion over the indecent colour of the new functions and
unwind path, we realised that we can use the new unreserve function to
clean up the code even further.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Using the extracted INSTDONE reading, and our new register definitions,
update our hangcheck detection and error collection to use it. This
primarily means changing == to memcmp, and changing = to memcpy.
Hopefully this will give more info on error dump, and provide more
accurate hangcheck detection (both are actually TBD).
Also, remove the reading of instdone1 from the ring error collection
function, and just crap everything in capture_error_state (that could be
split into a separate patch if it wasn't so trivial).
v2: Now assuming i915_get_extra_instdone does the memset we can clean up the
code a bit (Jani)
v3: use ARRAY_SIZE as requested earlier by Jani (didn't change sizeof)
Updated commit msg
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
INSTDONE is used in many places, and it varies from generation to
generation. This provides a good reason for us to extract the logic to
read the relevant information.
The patch has no functional change. It's prep for some new stuff.
v2: move the memset inside of i915_get_extra_instdone (Jani)
v3,4: bugs caught by (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This board is incorrectly detected as having an LVDS connector,
resulting in the VGA output (the only available output on the board)
showing the console only in the top-left 1024x768 pixels, and an extra
LVDS connector appearing in X.
It's a desktop Mini-ITX board using an Atom D525 CPU with an NM10
chipset.
I've had this board for about a year, but this is the first time I
noticed the issue because I've been running it headless for most of its
life.
Signed-off-by: Calvin Walton <calvin.walton@kepstin.ca>
The principal use for set-to-domain is for userspace to serialise
operations with a particular buffer, for example to maintain coherency
with a CPU map or to ratelimit its rendering by waiting on all previous
operations before continuing. As such we tend to hold the struct_mutex
for long periods during the synchronisation and so cause contention
issues with other users of the graphics device, even for independent
operations as memory management. An example is the contention between
compiz and X which causes jitter in the display and a drop in peak
throughput.
The ultimate solution would be a set of fine grained locks and lockless
operations, but an intermediate step is to first attempt the
synchronisation for set-to-domain without holding the mutex. This
introduces a number of race conditions, so we limit it use to the ioctl
periphery where we have no dependent state and can safely complete with
a locked synchronisation afterwards.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the wait-for-rendering logic around in the file so that we can
group it together with the subsequent variations. The general goal is to
have the lower level routines clustered together and then the higher
level logic building upon those low level routines that came before.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The current layout is to place the per-process tables at the end of the
GTT. However, this is currently using a hardcoded maximum size for the GTT
and not taking in account limitations imposed by the BIOS. Use the value
for the total number of entries allocated in the table as provided by
the configuration registers.
Reported-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Matthew Garret <mjg@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This prevents the case of unbinding the object in order to process the
relocations through the GTT and then rebinding it only to then proceed
to use cpu relocations as the object is now in the CPU write domain. By
choosing to use cpu relocations up front, we can therefore avoid the
rebind penalty.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we wish to create specialised object constructions in the near
future that share the same basic GEM object struct, export the default
initializer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the object has no backing shmemfs filp, then we obviously cannot
perform a truncation operation upon it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Avoid stalling and waiting for the GPU by checking to see if there is
sufficient inactive space in the aperture for us to bind the buffer
prior to writing through the GTT. If there is inadequate space we will
have to stall waiting for the GPU, and incur overheads moving objects
about. Instead, only incur the clflush overhead on the target object by
writing through shmem.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Neither the drm core nor any of the drivers really need the raw_edid field
of struct drm_display_info for anything. Instead of being useful, it
creates confusion about who is responsible for freeing the memory it points
to and setting the field to NULL afterwards, leading to memory leaks and
dangling pointers.
Remove the raw_edid field, and fix drivers as necessary.
Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The EDID returned by drm_get_edid() was never freed.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is an equivalent conversion and will ease scheduled removal of
WQ_NON_REENTRANT.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is already fixed for ILK and SNB in the below commit but somehow
IVB is missed.
commit ab2f9df10d
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Mon Feb 27 12:40:10 2012 -0800
drm/i915: fix color order for BGR formats on SNB
Had the wrong bits and field definitions.
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Wrong order of parameters passed-in when calling hdmi/adpa
/lvds_pipe_enabled(), 2nd and 3rd parameters are reversed.
This bug was indroduced by
commit 1519b9956e
Author: Keith Packard <keithp@keithp.com>
Date: Sat Aug 6 10:35:34 2011 -0700
drm/i915: Fix PCH port pipe select in CPT disable paths
The reachable tag for this commit is v3.1-rc1-3-g1519b99
Signed-off-by: Anhua Xu <anhua.xu@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44876
Tested-by: Daniel Schroeder <sec@dschroeder.info>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ERR_INT on HSW will display unclaimed MMIO accesses. This can be either
the result of a driver bug writing to an invalid addresses, or the
result of RC6.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ERR_INT can generate interrupts. However since most of the conditions seem
quite fatal the patch opts to simply report it in error state instead of
adding more complexity to the interrupt handler for little gain (the
bits are sticky anyway).
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This addresses WaPruneModeWithIncorrectHsyncOffset.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=50236
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In intel_dp_mode_set we OR in the exact same bits twice at the same
spot. Kill one of the redundant assignments.
This little regression was introduced by:
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
PCH eDP has many of the same needs as regular PCH DP connections,
including the DP_CTl bit settings, the TRANS_DP_CTL register.
The reachable tag for this commit is: v3.1-5461-g417e822
Signed-off-by: Anhua Xu <anhua.xu@intel.com>
[danvet: Improved the commit message somewhat and ensured the diff is
clearer.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Given the persistence of an offset for the lifetime of an object, itis
easy to contemplate how the mmap space becomes badly fragmented to the
point that further allocations fail with ENOSPC. Our only recourse at
this point is to try to purge the objects to release some space and
reattempt the allocation.
References: https://bugs.freedesktop.org/show_bug.cgi?id=39552
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A pair of universally true checks that just need to be put in the right
place depending on where in the patch sequence you go. Note that
i915_gem_object_put_pages_gtt() already gains the
BUG_ON(obj->gtt_space), but on reflection that needed to migrate to
put_pages().
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When dealing with a working set larger than the GATT, or even the
mappable aperture when touching through the GTT, we end up with evicting
objects only to rebind them at a new offset again later. Moving an
object into and out of the GTT requires clflushing the pages, thus
causing a double-clflush penalty for rebinding.
To avoid having to clflush on rebinding, we can track the pages as they
are evicted from the GTT and only relinquish those pages on memory
pressure.
As usual, if it were not for the handling of out-of-memory condition and
having to manually shrink our own bo caches, it would be a net reduction
of code. Alas.
Note: The patch also contains a few changes to the last-hope
evict_everything logic in i916_gem_execbuffer.c - we no longer try to
only evict the purgeable stuff in a first try (since that's superflous
and only helps in OOM corner-cases, not fragmented-gtt trashing
situations).
Also, the extraction of the get_pages retry loop from bind_to_gtt (and
other callsites) to get_pages should imo have been a separate patch.
v2: Ditch the newly added put_pages (for unbound objects only) in
i915_gem_reset. A quick irc discussion hasn't revealed any important
reason for this, so if we need this, I'd like to have a git blame'able
explanation for it.
v3: Undo the s/drm_malloc_ab/kmalloc/ in get_pages that Chris noticed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Split out code movements and rant a bit in the commit message
with a few Notes. Done v2]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
James Bottomley reported [1] a massive power regression, due to the
enabling of semaphores by default in 3.5. A workaround for him is to
again disable semaphores. And indeed, his system has a very hard time
to enter rc6 with semaphores enabled.
Ben Widawsky run around with a kill-a-watt a lot and noticed:
- There are indeed a few rare systems that seem to have a hard time
entering rc6 when desktop-idle.
- One machine, The Indestructible Toshiba regressed in this behaviour
between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the
current setting seems to be highly timing dependent and not robust
at all.
- The behaviour James reported wrt semaphores seems to be a freak
timing thing that only happens on his specific machine, confirming
that enabling semaphores shouldn't reduce rc6 residency.
Now furthermore the Google ChromeOS guys reported [2] a while ago that
at least on some machines a simply a blinking cursor can keep the gpu
turbo at the highest frequency. This is because the current rps limits
used on snb/ivb are highly asymmetric.
On the theory that gpu turbo and rc6 tuning values are related, we've
tried whether the much saner looking (since much less asymmetric) rps
tuning values used for hsw would also help entering rc6 more robustly.
And it seems to mostly work, and we don't really have the resources to
through-roughly tune things in any better way: The values from the
ChromeOS ppl seem to fare a bit worse for James' machine, so I guess
we better stick with something vpg (the gpu hw/windows group)
provided, hoping that they've done their jobs.
Reference[1]: http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html
Reference[2]: http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393
Tested-by: Ben Widawsky <ben@bwidawsk.net>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Prep work to make Chris Wilson's unbound tracking patch a bit easier
to read. Alas, I'd have preferred that moving the page allocation
retry loop from bind to get_pages would have been a separate patch,
too. But that looks like real work ;-)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Added new haswell_write_eld() to initialize Haswell HDMI audio registers
to generate an unsolicited response to the audio controller driver to
indicate that the controller sequence should start.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In order for udl vmap to work properly, we need to push the object
into the CPU domain before we start copying the data to the USB device.
This along with the udl change avoids userspace explicit mapping to
be used.
v2: add a flag for userspace to query to know if Intel kernel driver can
deal with the vmap flushing properly. In theory udl would need a flag also,
but I intend to push the patches very close to each other and other drivers
should do the right thing from the start.
I've added a test to my intel-gpu-tools prime branch, however testing
this is a bit messy since the only way to get udl to vmap is to rendering
something. I've tested this with real code as well to make sure it works.
Signed-off-by: Dave Airlie <airlied@redhat.com>
[danvet: resolved conflict, which required reallocating the PARAM
number to 21.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is left over from the old PLL sharing code and isn't useful now
that PLLs are shared when possible.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
New-ish devices have 3 pipes, so let's not just hardcode 2 but use the
for_each_pipe() macro and make struct intel_display_error_state is big
enough.
V2: Also add the number of pipes emitted (Chris Wilson)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use _PIPE macro to get correct register definition for IBX/CPT, discard
old variable "i" way.
Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Added the DIP_PORT_SEL #define from a preceeding patch in the
series that needs more work.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
HDMI audio related registers will be configured in write_eld callback.
Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Simply to make the ilk+ crtc disable path clearer and more symmetric
with the enable function.
Also switch to intel_crtc for the enable function.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... and move a few others only used by i915_dma.c into the dri1
dungeon.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All dvo drivers only support 2 dpms states, and our dvo driver
even switches of the dvo port for anything else than DPMS_ON. Hence
ditch this complexity and simply use bool enable.
While reading through this code I've noticed that the mode_set
function of ch7017 is a bit peculiar - it disable the lvds again, even
though the crtc helper code should have done that ... This might be to
work around an issue at driver load, we pretty much ignore the hw
state when taking over.
v2: Also do the conversion for the new ns2501 driver.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since it's redundant - we can get the attached encoder in the
functions themselves.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A few things need adjustement:
- Change the dpms state by calling the dpms connector function and
not some crtc helper internal callbacks. Otherwise this will break
once we switch to our own dpms handling.
- Instead of tracking and restoring intel_crtc->dpms_mode use the
connector's dpms variable - the former relies on the dpms compuation
rules used by the crtc helper. And it would break when the encoder
is cloned and the other output has a different dpms state. But luckily
no one is crazy enough for that.
- Properly clear the connector -> encoder -> crtc linking, even when
failing (note that the crtc helper removes the encoder -> crtc link
in disabled_unused_functions for us).
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that all affected i830M systems have the pipe A quirk set,
we don't need to do any special dances in the overlay code any
longer. And reading through the code I'm rather dubios that it
actually does what it claims to do ...
As a nice benefit this rips out a users of the crtc helper dpms
callback.
v2: As suggested by Chris Wilson, replace the code by an appropriate
WARN to ensure that the pipe A is indeed running.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the pipe A quirk properly fixed up for i830M, this shouldn't be
required any longer.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For some odd reason we've missed i830 and a i855 variant. Also
kill the two now redundant i830 entries.
v2: Don't add the missing 855 id to the pipe A quirk list, we seem to
lack justification for it.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Wrong order of parameters passed-in when calling hdmi/adpa
/lvds_pipe_enabled(), 2nd and 3rd parameters are reversed.
This bug was indroduced by
commit 1519b9956e
Author: Keith Packard <keithp@keithp.com>
Date: Sat Aug 6 10:35:34 2011 -0700
drm/i915: Fix PCH port pipe select in CPT disable paths
The reachable tag for this commit is v3.1-rc1-3-g1519b99
Signed-off-by: Anhua Xu <anhua.xu@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
GMBUS was enabled over bit-banging as the default in commits:
commit c3dfefa0a6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Feb 14 22:37:25 2012 +0100
drm/i915: reenable gmbus on gen3+ again
and
commit 0fb3f969c8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Mar 2 19:38:30 2012 +0100
drm/i915: enable gmbus on gen2
Unfortunately, GMBUS seems to fail on some CRT displays. Add a bit-banging
fallback to CRT EDID reads.
LKML-Reference: <201207251020.47637.maciej.rutecki@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Alex Ferrando <alferpal@gmail.com>
Cc: stable@vger.kernel.org (for 3.4+3.5)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Refactor the connector update part of intel_ddc_get_modes() into a separate
intel_connector_update_modes() function for reuse. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881
Tested-by: Alex Ferrando <alferpal@gmail.com>
Cc: stable@vger.kernel.org (for 3.4+3.5)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
They've changed it ... for no apparent reason. Meh.
V2: remove unused 'is_hsw' field.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After reset we unconditionally reinitialize lists. If the context switch
hasn't yet completed before the suspend, the default context object will
end up on lists that are going to go away when we resume.
The patch forces the context switch to be synchronous before suspend
assuring that the active/inactive tracking is correct at the time of
resume.
References: https://bugs.freedesktop.org/show_bug.cgi?id=52429
Tested-by: Guang A Yang <guang.a.yang@intel.com>
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>
The EDID returned by drm_get_edid() was never freed.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEcBAABAgAGBQJQLWtvAAoJEHm+PkMAQRiG/DYH+wd0FqfEuYkYk4KPyAPuhKpX
zX7HYfLvyJE/ZYIdrhjq1E6Xm2KNr7gtX7/Rdzi2W38M9sjbYzwG1UGIw51qnxWy
yZJH9BGkfyQgQPeuDGohfB6DkDy2JWr2eqMDvakjOwgBsIzji0PQD/f3UvndhtUa
c+tTj/kjavHE1Yr2Wy6OnRZz3Uc0hIMn/Q0JqtbCs3LUgEV1KA4OEAe56XNz4Ku4
WE+FFaGFPvtriQsQON+ohPS5IC8jzQGK/0vbrJ4lWjFnZy4gvZXnborTOwD0WSQG
fbsNuxp1AaM2/pqfMwXm1w0ADvwOITHNiwwXf9id6DoK81QwTFpUdvKpn6yB6gQ=
=rurr
-----END PGP SIGNATURE-----
Merge tag 'v3.6-rc2' into drm-intel-next
Backmerge Linux 3.6-rc2 to resolve a few funny conflicts before we put
even more madness on top:
- drivers/gpu/drm/i915/i915_irq.c: Just a spurious WARN removed in
-fixes, that has been changed in a variable-rename in -next, too.
- drivers/gpu/drm/i915/intel_ringbuffer.c: -next remove scratch_addr
(since all their users have been extracted in another fucntion),
-fixes added another user for a hw workaroudn.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When invalidating the TLBs it is documentated as requiring a post-sync
write. Failure to do so seems to result in a GPU hang.
Exposure to this hang on IVB seems to be a result of removing the extra
stalls required for SNB pipecontrol workarounds:
commit 6c6cf5aa9c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 20 18:02:28 2012 +0100
drm/i915: Only apply the SNB pipe control w/a to gen6
Note: Manually switch the pipe_control cmd to 4 dwords to avoid a
(silent) functional conflict with -next. This way will get a loud (but
conflict with next (since the scratch_addr has been deleted there).
Reported-and-tested-by: yex.tian@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53322
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: added note about merge conflict with -next.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
eDP is tons of fun. It turns out that at least the new MacBook Air 5,1
model absolutely doesn't like the new force vdd dance we've introduced
in
commit 6cb49835da
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun May 20 17:14:50 2012 +0200
drm/i915: enable vdd when switching off the eDP panel
But that patch also tried to fix some neat edp sequence issue with the
force_vdd timings. Closer inspection reveals that we've raised
force_vdd only to do the aux channel communication dp_sink_dpms. If we
move the edp_panel_off below that, we don't need any force_vdd for the
disable sequence, which makes the Air happy.
Unfortunately the reporter of the original bug that the above commit
fixed is travelling, so we can't test whether this regresses things.
But my theory is that since we don't check for any power-off ->
force_vdd-on delays in edp_panel_vdd_on, this was the actual
root-cause of this failure. With that force_vdd dance completely
eliminated, I'm hopeful the original bug stays fixed, too.
For reference the old bug, which hopefully doesn't get broken by this:
https://bugzilla.kernel.org/show_bug.cgi?id=43163
In any case, regression fixers win over plain bugfixes, so this needs
to go in asap.
v2: The crucial pieces seems to be to clear the force_vdd flag
uncoditionally, too, in edp_panel_off. Looks like this is left behind
by the firmware somehow.
v3: The Apple firmware seems to switch off the panel on it's own, hence
we still need to keep force_vdd on, but properly clear it when switching
the panel off.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45671
Tested-by: Roberto Romer <sildurin@gmail.com>
Tested-by: Daniel Wagner <wagi@monom.org>
Tested-by: Keith Packard <keithp@keithp.com>
Cc: stable@vger.kernel.org
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i2c_add_adapter() may do i2c transfers on the bus to detect supported
devices. Therefore the adapter needs to be all set before adding it. This
was not the case for the bit-banging fallback, resulting in an oops if the
device detection GMBUS transfers timed out. Fix the issue by calling
i2c_add_adapter() only after intel_gpio_setup().
LKML-Reference: <5021F00B.7000503@ionic.de>
Tested-by: Mihai Moldovan <ionic@ionic.de>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since forcewake is now protected by a spinlock, we don't need to grab
dev->struct_mutex any more. This way we can also get rid of a stale
comment, noticed by Ben Widawsky while reviewing some locking changes.
v2: Kill the unused variable ret, noticed by Fengguang Wu.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This has originally been introduced to not oversubscribe the dp links
in
commit 885a5fb5b1
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date: Tue Jan 12 05:38:31 2010 +0800
drm/i915: fix pixel color depth setting on eDP
Since then we've fixed up the dp link bandwidth calculation code and
should now automatically fall back to 6bpc dithering. So this is
unnecessary.
Furthermore it seems to break the new MacbookPro with retina display,
hence let's just rip this out.
Reported-by: Benoit Gschwind <gschwind@gnu-log.net>
Cc: Benoit Gschwind <gschwind@gnu-log.net>
Cc: Francois Rigaut <frigaut@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
Tested-by: Benoit Gschwind <gschwind@gnu-log.net>
Tested-by: Bernhard Froemel <froemel at vmars tuwien.ac.at>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
--
Testing feedback highgly welcome, and thanks for Benoit for finding
out that the bpc computations are busted.
-Daniel
When you reopen the lid on a laptop with PCH, the panel suddenly goes
blank sometimes. It seems because BLC_PWM_CPU_CTL register is cleared
to zero when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 registers are
enabled.
This patch fixes the problem by moving the call of the function setting
BLC_PWM_CPU_CTL after enabling other two registers.
Reported-and-tested-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we don't find the exact refresh rate, go with the next one. This
makes some modes work for me. They won't have the best settings, but
will at least have something. Just returning from this function when
we don't find the perfect settings does not help us at all.
Version 2:
- Remove duplicate lines on the clock table.
- Add back debug message with refresh, p, n2 and r2.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- intel_encoder->type is INTEL_OUTPUT_SOMETHING
- drm_encoder->encoder_type is DRM_MODE_ENCODER_SOMETHING
Here we're using intel_encoder, so compare the oranges against
oranges. While at it, rename the variable to "intel_encoder" so we
keep our naming standards used everywhere.
Luckily this was not a bug because both DRM_MODE_ENCODER_DAC and
INTEL_OUTPUT_ANALOG are defined as 1. This is the only case where the
drm definition matches the intel definition.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Avoid the forcewake overhead when simply retiring requests, as often the
last seen seqno is good enough to satisfy the retirment process and will
be promptly re-run in any case. Only ensure that we force the coherent
seqno read when we are explicitly waiting upon a completion event to be
sure that none go missing, and also for when we are reporting seqno
values in case of error or debugging.
This greatly reduces the load for userspace using the busy-ioctl to
track active buffers, for instance halving the CPU used by X in pushing
the pixels from a software render (flash). The effect will be even more
magnified with userptr and so providing a zero-copy upload path in that
instance, or in similar instances where X is simply compositing DRI
buffers.
v2: Reverse the polarity of the tachyon stream. Daniel suggested that
'force' was too generic for the parameter name and that 'lazy_coherency'
better encapsulated the semantics of it being an optimization and its
purpose. Also notice that gen6_get_seqno() is only used by gen6/7
chipsets and so the test for IS_GEN6 || IS_GEN7 is redundant in that
function.
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>
I have the faint hope that the total absence of any locking for the
rps code wasn't too good an idea and could very well have caused some
rc6 related regressions.
Unfortunately we've never managed to reproduce these issues on any of
our own machines, so the only way to go about this is to enable it and
see what happens.
While at it, kill some stale comments and improve the logging.
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We change the drps/ips sw/hw state from different callers: Our own irq
handler, the external intel-ips module and from process context. Most
of these callers don't take any lock at all.
Protect everything by making the mchdev_lock irqsave and grabbing it in
all relevant callsites. Note that we have to convert a few sleeps in the
drps enable/disable code to delays, but alas, I'm not volunteering to
restructure the code around a few work items.
For paranoia add a spin_locked assert to ironlake_set_drps, too.
v2: Move one access inside the lock protection. Caught by the
dev_priv->ips mass-rename ...
v3: Resolve rebase conflict.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like all the other drps/ips stuff. Hence add the corresponding check,
give the function a preciser prefix and move the single reg clearing into
the rps handling function, too.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's only ever a pointer to the global mchdev_lock, and we don't use
it at all.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This way it's easier so see what belongs together, and what is used
by the ilk ips code. Also add some comments that explain the locking.
Note that (cur|min|max)_delay need to be duplicated, because
they're also used by the ips code.
v2: Missed one place that the dev_priv->ips change caught ...
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's no fun if your shell hangs when the driver has gone on vacation
and you want to know why ...
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Take the dev->struct_mutex around access the corresponding state
(and adjusting the rps hw state).
- Add an assert to gen6_set_rps to ensure we don't forget about this
in the future.
- Don't set up the min/max_freq files if it doesn't apply to the hw.
And do the same for the gen6+ cache sharing file while at it.
v2: Move the gen6+ checks into the read/write callbacks. Thanks to the
awesome drm midlayer we can't check that when registering the debugfs
files, because the driver is not yet fully set up, specifically the
->load callback hasn't run yet.
Oh how I despise this disaster ...
v3: Also add a WARN_ON(mutex_is_locked) in set_rps to check the
locking.
v4: Use mutex_lock_interruptible, suggested by Chris Wilson.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (for v2)
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The update_gfx_val function called from mark_busy wasn't taking the
mchdev_lock, as it should have. Also sprinkle a few spinlock asserts
over the code to document things better.
Things are still rather confusing, especially since a few variables
in dev_priv are used by both the gen6+ rps code and the ilk ips code.
But protected by totally different locks. Follow-on patches will clean
that up.
v2: Don't add a deadlock ... hence split up update_gfx_val into a
wrapper that grabs the lock and an internal __ variant for callsites
within intel_pm.c that already have taken the lock.
v3: Mark the internal helper as static, noticed by Ben Widawsky.
v4: Damien Lespiau had questions about the safety of the ips setup
sequence, explain in a comment why it works.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By looking at the current way we're using these definitions I don't
think this commit will fix any bug, but programmers from the future
are evil and will certainly find ways to combine macro expansion with
operator precedence to introduce bugs that are hard to find.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's the only part of the i915_reg.h file that looks totally wrongly
indented, so I assume my editor config is the correct one.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Don't rely on previous values already set on the register. Everything
we're not explicitly setting should be zero for now.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Correctly erase the values previously set and also check for 6bpc and
10bpc.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During my tests, everything worked even if the wrong polarity was set.
Still, we should try to set the correct values.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mask the value before changing it and also select DVI when needed.
DVI was working in cases where the BIOS was setting the correct value
because we were not masking the value before changing it.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Handy for lazy people like me, or when people forget to add the output
of lspci -nn.
v2: Chris Wilson noticed that we have this duplicated already in the
i915_capabilites debugfs file. But there \n as separator looks better,
which would be a bit verbose in dmesg. Abuse the preprocessor to
extract this all.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel writes:
"- Regression fixer for an OOPS at boot when i915.ko is built-in and
CONFIG_PM=n, introduce in 3.5 (patch from Hunt Xu)
- Regression fixer for occlusion query failures, the required w/a wasn't
applied in all cases (thanks to Eric for tracking this on down).
- dmar vs. dma_buf imprt fix (Dave Airlie)
- 2 patches to fight down forcewake issues on snb. This is the stuff I've
talked about 2 weeks ago already, it's a minefield. Investigation still
going on, but afaict this is the best we have for now.
- a few minor things to keep coverty&compiler happy (Alan, Davendra,
Stéphane)
- tons of hsw pci ids - this one is a bit late because internal approval
sometimes takes a while, but ppl in charge finally agreed that world+dog
already knows about ult and crw haswell variants ;-)
Wrt regressions I'm aware of:
- the power regression due to semaphores=1. Ben is running around with a
killawatt, unfortunately we have a hard time reproducing this one. And
this /shouldn't/ increase power usage. Ben has turned up a few odds bits
though already.
- the lvds fix in 3.6-rc1 broke a backlight after lid close/open (but can
be resurrected with a modeset cycle). I guess we anger the bios - I'm
still looking into this one.
- gmbus broke edid reading on an odd-ball monitor, we need to fall-back.
Due to vacation (both mine&the reporter's) this is stalling for a final
patch and a tested-by on it. But issue is fully diagnosed."
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: correctly order the ring init sequence
drm/i915: add more Haswell PCI IDs
drm/i915: make rc6 in sysfs functions conditional
drm/i915: Workaround hang with BSD and forcewake on SandyBridge
drm/i915: Make intel_panel_get_backlight static.
i915: don't map imported dma-bufs for dmar.
drm/i915: remove unused variable
drm/i915: Don't forget to apply SNB PIPE_CONTROL GTT workaround.
drm/i915: fix forcewake related hangs on snb
i915: Remove silly test
i915: fix error path leak in intel_sdvo_write_cmd
vlv: it might be wise if we initialised the flag value...
In commit
commit 20b46e59dd
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jul 26 11:16:14 2012 +0200
drm/i915: Only set the down rps limit when at the loweset frequency
The computation for the new desired frequency was extracted, but since
the desired frequency was passed-by value, the adjustments didn't
propgate back. Fix this.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Userspace tries to estimate the cost of ring switching based on whether
the GPU and GEM supports semaphores. (If we have multiple rings and no
semaphores, userspace assumes that the cost of switching rings between
batches is exorbitant and will endeavour to keep the next batch on the
active ring - as a coarse approximation to tracking both destination and
source surfaces.) Currently userspace has to guess whether semaphores
exist based on the chipset generation and the module parameter,
i915.semaphores. This is a crude and inaccurate guess as the defaults
internally depend upon other chipset features being enabled or disabled,
nor does it extend well into the future. By exporting a HAS_SEMAPHORES
parameter, we can easily query the driver and obtain an accurate answer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We may only start to set up the new register values after having
confirmed that the ring is truely off. Otherwise the hw might lose the
newly written register values. This is caught later on in the init
sequence, when we check whether the register writes have stuck.
Cc: stable@vger.kernel.org
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
Tested-by: Yang Guang <guang.a.yang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The requirements for the sync flush to be emitted prior to the render
cache flush is only true for SandyBridge. On IvyBridge and friends we
can just emit the flushes with an inline CS stall.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also properly indent the HB IDs.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Commit 0136db586c merges rc6 information
into the power group. However, when compiled with CONFIG_PM not set,
modprobing i915 would taint since power_group_name is defined as NULL.
This patch makes these rc6 in sysfs functions conditional upon the
definition of the CONFIG_PM macro to avoid the above-mentioned problem.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45181
Cc: stable@vger.kernel.org
Tested-by: Kris Karas <bugs-a12@moonlit-rail.com>
Signed-off-by: Hunt Xu <mhuntxu@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For reasons that are not apparent to anybody, 990bbdadab (drm/i915:
Group the GT routines together in both code and vtable) breaks the use
of the BitStream Decoder ring on SandyBridge. The active ingredient of
that patch is the conversion from a udelay(10) to a udelay(1) in the
busy-wait loop of waiting for the forcewake acknowledge. If we restore
that udelay(10) or insert another udelay(1) afterwards (or any wait
longer than 250ns) everything works again. An alternative is also to
remove any delay from the busy-wait loop.
Given that in the atomic sections we want to complete the wait as quick
as possible to avoid blocking the CPU for too long, it makes sense to
remove the delay altogether and simply spin on the exit condition until
it completes. So we replace the udelay(1) with cpu_relax().
Papers over regression from
commit 990bbdadab
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Jul 2 11:51:02 2012 -0300
drm/i915: Group the GT routines together in both code and vtable
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51738
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This function isn't used outside of intel_panel.c, so make it static.
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The exporter should have given us pages in the correct place, avoid
the prepare object mapping phase on dmar systems.
This fixes an oops on a GM45/R600 machine, when running the intel/radeon
tests.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
the following warning was produced,
drivers/gpu/drm/i915/i915_gem_context.c: In function ‘i915_switch_context’:
drivers/gpu/drm/i915/i915_gem_context.c:454:6: warning: unused variable ‘ret’ [-Wunused-variable]
fix up by removing it
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If a buffer that was the target of a PIPE_CONTROL from userland was a
reused one that hadn't been evicted which had not previously had this
workaround applied, then the early return for a correct
presumed_offset in this function meant we would not bind it into the
GTT and the write would land somewhere else.
Fixes reproducible failures with GL_EXT_timer_query usage in apitrace,
and I also expect it to fix the intermittent OQ issues on snb that
danvet's been working on.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48019
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52932
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Carl Worth <cworth@cworth.org>
Tested-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... by adding seemingly redudant posting reads.
This little dragon lair exploded the first time around when we've
refactored the code a bit to use the common wait_for_atomic_us in
"drm/i915: Group the GT routines together in both code and vtable",
which caused QA to file fdo bug #51738.
Chris Wilson entertained a few approaches to fixing #51738: Replacing
the udelay(1) with the previously-used udelay(10) (or any other
"sufficiently larger" delay), adding a posting read, or ditching the
delay completely and using cpu_relax. We went with the cpu_relax and
"915: Workaround hang with BSD and forcewake on SandyBridge". Which
blew up in fdo bug #52424, but adding the posting read while still
using cpu_relax seems to also fix that, it looks like the
posting read is the important ingriedient to fix these rc6 related
hangs on snb.
Popular theories as to why this is like it is include:
- A herd of pink elephants got royally angered somehow.
- The gpu has internally different functional units and judging by the
register offsets, the forcewake request register and the forcewake
ack registers are _not_ in the same functional unit (or at least
aren't reached through the same routes). Hence the posting read
syncs up with the wrong block and gets the entire gpu confused.
- ...
As a minimal ducttape fix for 3.6, let's just put these posting reads
into place again. We can try fancier approaches (like adding back the
cpu_relax instead of the udelay) in -next.
This (re-)fixes a regression introduced in
commit 990bbdadab
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Jul 2 11:51:02 2012 -0300
drm/i915: Group the GT routines together in both code and vtable
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Du Yan <yanx.du@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52424
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51738u
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We should not hit this under any sane conditions, but still, this does not
looks right.
CC: Chris Wilson <chris@chris-wilson.co.uk>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
CC: stable@vger.kernel.org
Reported-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Reviewed-by: Chris Wlison <chris@chris-wilson.co.uk>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We believe to have squashed all issues around the gen6+ rps interrupt
generation and why the gpu sometimes got stuck. With that cleared up,
there's no user left for the sanitize_pm infrastructure, so let's just
rip it out.
Note that 'intel_reg_write 0xa014 0x13070000' is the w/a if we find
ourselves stuck again.
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The power docs say that when the gt leaves rc6, it is in the lowest
frequency and only about 25 usec later will switch to the frequency
selected in GEN6_RPNSWREQ. If the downclock limit expires in that
window and the down limit is set to the lowest possible frequency, the
hw will not send the down interrupt. Which leads to a too high gpu
clock and wasted power.
Chris Wilson already worked on this with
commit 7b9e0ae6da
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat Apr 28 08:56:39 2012 +0100
drm/i915: Always update RPS interrupts thresholds along with
frequency
but got the logic inverted: The current code set the down limit as
long as we haven't reached it. Instead of only once with reached the
lowest frequency.
Note that we can't always set the downclock limit to 0, because
otherwise the hw will keep on bugging us with downclock request irqs
once the lowest level is reached.
For similar reasons also always set the upclock limit, otherwise the
hw might poke us again with interrupts.
v2: Chris Wilson noticed that the limit reg is also computed in
sanitize_pm. To avoid duplication, extract the code into a common
function.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter