Daniel Vetter [Thu, 5 Jul 2012 14:09:09 +0000 (16:09 +0200)]
drm/i915: convert pointless error checks in set_config to BUGs
Because they all are, the ioctl command never calls us with any of
these violated. Also drop a equally pointless empty debug message (and
also in set_cursor, while we're at it).
With all these changes, intel_crtc_set_config is neatly condensed down
to it's essence, the actual modeset code (or fb update calling code)
v2: The fb helper code is actually stretching ->set_config semantics a bit,
it calls it with set->mode == NULL but set->fb != NULL.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 10 Jul 2012 16:11:08 +0000 (18:11 +0200)]
drm/i915: don't update the fb base if there is no fb
Otherwise we'll set_fb complains pretty loudly if we the crtc is off
and userspace moves the NULL fb around a bit. Yeah, this actually
happens in the wild ...
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
Daniel Vetter [Wed, 4 Jul 2012 20:16:09 +0000 (22:16 +0200)]
drm/i915: introduce struct intel_set_config
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>
Daniel Vetter [Wed, 4 Jul 2012 15:51:47 +0000 (17:51 +0200)]
drm/i915: ensure the force pipe A quirk is actually followed
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>
Daniel Vetter [Thu, 26 Jul 2012 17:25:46 +0000 (19:25 +0200)]
drm/i915: rip out intel_dp->dpms_mode
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>
Daniel Vetter [Tue, 3 Jul 2012 11:19:00 +0000 (13:19 +0200)]
drm/i915: rip out intel_crtc->dpms_mode
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>
Daniel Vetter [Mon, 2 Jul 2012 19:54:27 +0000 (21:54 +0200)]
drm/i915: check connector hw/sw state
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>
Daniel Vetter [Mon, 2 Jul 2012 18:28:59 +0000 (20:28 +0200)]
drm/i915: read out the modeset hw state at load and resume time
... 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>
Daniel Vetter [Mon, 2 Jul 2012 13:09:45 +0000 (15:09 +0200)]
drm/i915/dvo: implement get_hw_state
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>
Daniel Vetter [Mon, 2 Jul 2012 12:54:00 +0000 (14:54 +0200)]
drm/i915/sdvo: implement get_hw_state
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>
Daniel Vetter [Mon, 2 Jul 2012 11:41:21 +0000 (13:41 +0200)]
drm/i915/crt: implement get_hw_state
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>
Daniel Vetter [Mon, 2 Jul 2012 11:10:34 +0000 (13:10 +0200)]
drm/i915: Add interfaces to read out encoder/connector hw state
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>
Daniel Vetter [Mon, 2 Jul 2012 09:43:47 +0000 (11:43 +0200)]
drm/i915: WARN when trying to enabled an unused crtc
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>
Daniel Vetter [Mon, 2 Jul 2012 07:56:42 +0000 (09:56 +0200)]
drm/i915: copy&paste drm_crtc_helper_set_mode
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>
Daniel Vetter [Sun, 1 Jul 2012 22:16:19 +0000 (00:16 +0200)]
drm/i915: clean up encoder_prepare/commit
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>
Daniel Vetter [Sun, 1 Jul 2012 20:42:24 +0000 (22:42 +0200)]
drm/i915: convert dpms functions of dvo/sdvo/crt
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>
Daniel Vetter [Sun, 1 Jul 2012 13:31:04 +0000 (15:31 +0200)]
drm/i915/sdvo: convert to encoder disable/enable
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>
Daniel Vetter [Sun, 1 Jul 2012 12:58:27 +0000 (14:58 +0200)]
drm/i915/crt: convert to encoder disable/enable
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>
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>
Daniel Vetter [Sat, 30 Jun 2012 06:59:56 +0000 (08:59 +0200)]
drm/i915/hdmi: convert to encoder->disable/enable
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>
Daniel Vetter [Fri, 29 Jun 2012 20:40:09 +0000 (22:40 +0200)]
drm/i915: add direct encoder disable/enable infrastructure
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>
Daniel Vetter [Fri, 29 Jun 2012 20:53:09 +0000 (22:53 +0200)]
drm/i915: rip out crtc prepare/commit indirection
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>
Daniel Vetter [Fri, 29 Jun 2012 20:39:33 +0000 (22:39 +0200)]
drm/i915: add crtc->enable/disable vfuncs insted of dpms
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>
Wang Xingchao [Thu, 16 Aug 2012 14:43:37 +0000 (22:43 +0800)]
drm/i915: Haswell HDMI audio initialization
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>
Dave Airlie [Thu, 16 Aug 2012 00:15:34 +0000 (10:15 +1000)]
drm/i915: implement dma buf begin_cpu_access (v2)
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>
Damien Lespiau [Wed, 15 Aug 2012 18:23:25 +0000 (19:23 +0100)]
drm/i915: Don't hardcode the number of pipes in the error state dump
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>
Daniel Vetter [Sun, 12 Aug 2012 16:15:48 +0000 (18:15 +0200)]
drm/fb-helper: don't clobber output routing in setup_crtcs
Yet again the too close relationship between the fb helper and the
crtc helper code strikes. This time around the fb helper resets all
encoder->crtc pointers to NULL before starting to set up it's own
mode. Which is total bullocks, because this will clobber the existing
output routing, which the new drm/i915 code depends upon to be
absolutely correct.
The crtc helper itself doesn't really care about that, since it
disables unused encoders in a rather roundabout way anyway.
Two places call drm_setup_crts:
- For the initial fb config. I've auditted all current drivers, and
they all allocate their encoders with kzalloc. So there's no need to
clear encoder->crtc once more.
- When processing hotplug events while showing the fb console. This
one is a bit more tricky, but both the crtc helper code and the new
drm/i915 modeset code disable encoders if their crtc is changed and
that encoder isn't part of the new config. Also, both disable any
disconnected outputs, too.
Which only leaves encoders that are on, connected, but for some odd
reason the fb helper code doesn't want to use. That would be a bug
in the fb configuration selector, since it tries to light up as many
outputs as possible.
v2: Kill the now unused encoders variable.
Acked-by: Dave Airlie <airlied@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Wang Xingchao [Thu, 9 Aug 2012 08:52:18 +0000 (16:52 +0800)]
drm/i915: ironlake_write_eld code cleanup
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>
Wang Xingchao [Thu, 9 Aug 2012 08:52:16 +0000 (16:52 +0800)]
drm/i915: write eld info for HDMI audio
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>
Wang Xingchao [Thu, 9 Aug 2012 08:52:15 +0000 (16:52 +0800)]
drm/i915: HSW audio registers definition
Add hsw audio registers definition
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>
Daniel Vetter [Sun, 12 Aug 2012 17:27:12 +0000 (19:27 +0200)]
drm/i915: simplify dvo dpms interface
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>
Daniel Vetter [Sun, 12 Aug 2012 17:27:11 +0000 (19:27 +0200)]
drm/i915: prepare load-detect pipe code for dpms changes
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>
Daniel Vetter [Sun, 12 Aug 2012 17:27:10 +0000 (19:27 +0200)]
drm/i915: rip out the overlay pipe A workaround
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>
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>
Daniel Vetter [Fri, 17 Aug 2012 06:57:56 +0000 (08:57 +0200)]
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>
Ian Kent [Mon, 6 Aug 2012 01:37:47 +0000 (09:37 +0800)]
autofs4 - fix get_next_positive_subdir()
Following a report of a crash during an automount expire I found that
the locking in fs/autofs4/expire.c:get_next_positive_subdir() was wrong.
Not only is the locking wrong but the function is more complex than it
needs to be.
The function is meant to calculate (and dget) the next entry in the list
of directories contained in the root of an autofs mount point (an autofs
indirect mount to be precise). The main problem was that the d_lock of
the owner of the list was not being taken when walking the list, which
lead to list corruption under load. The only other lock that needs to
be taken is against the next dentry candidate so it can be checked for
usability.
Signed-off-by: Ian Kent <raven@themaw.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Thu, 16 Aug 2012 18:47:42 +0000 (11:47 -0700)]
Merge tag 'vfio-for-v3.6-rc1' of git://github.com/awilliam/linux-vfio
Pull VFIO fix from Alex Williamson:
"Just a trivial patch to include vfio.h in the installed headers so we
can complete userspace integration into QEMU."
* tag 'vfio-for-v3.6-rc1' of git://github.com/awilliam/linux-vfio:
vfio: Include vfio.h in installed headers
Linus Torvalds [Thu, 16 Aug 2012 18:31:59 +0000 (11:31 -0700)]
Merge tag 'stable/for-linus-3.6-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
Pull Xen fix from Konrad Rzeszutek Wilk:
"Way back in v3.5 we added a mechanism to populate back pages that were
released (they overlapped with MMIO regions), but neglected to reserve
the proper amount of virtual space for extend_brk to work properly.
Coincidentally some other commit aligned the _brk space to larger area
so I didn't trigger this until it was run on a machine with more than
2GB of MMIO space."
* On machines with large MMIO/PCI E820 spaces we fail to boot b/c
we failed to pre-allocate large enough virtual space for extend_brk.
* tag 'stable/for-linus-3.6-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
xen/p2m: Reserve 8MB of _brk space for P2M leafs when populating back.
Linus Torvalds [Thu, 16 Aug 2012 18:13:16 +0000 (11:13 -0700)]
Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma
Pull two slave-dmaengine fixes from Vinod Koul:
"One fixes the correct use of clock API in imx driver and the other
enables clock for tegra driver, which is used for other tegra driver
conversion to dmanegine in -next."
* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
dma: tegra: enable/disable dma clock
dma: imx-dma: Fix kernel crash due to missing clock conversion
Linus Torvalds [Thu, 16 Aug 2012 18:08:32 +0000 (11:08 -0700)]
Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
Pull more drm fixes from Dave Airlie:
"Just some intel and nouveau ones this time, intel has more edp panel
fixes for macbooks and nouveau has a suspend/resume regression fix in
there."
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/i915: Apply post-sync write for pipe control invalidates
drm/i915: reorder edp disabling to fix ivb MacBook Air
drm/nv86/fifo: suspend fix
drm/nouveau: disable copy engine on NVAF
nouveau: fixup scanout enable in nvc0_pm
drm/nouveau/aux: mask off higher bits of auxch index in i2c table entry
drm/nvd0/disp: mask off high 16 bit of negative cursor x-coordinate
drm/i915: ensure i2c adapter is all set before adding it
drm/i915: ignore eDP bpc settings from vbt
drm/i915: Fix blank panel at reopening lid
drm/nve0/fifo: add support for the flip completion swmthd
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sparc64: Be less verbose during vmemmap population.
sparc64: do not clobber personality flags in sys_sparc64_personality()
Dave Airlie [Wed, 15 Aug 2012 10:31:22 +0000 (20:31 +1000)]
Merge branch 'drm-nouveau-fixes' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
* 'drm-nouveau-fixes' of git://git.freedesktop.org/git/nouveau/linux-2.6:
drm/nv86/fifo: suspend fix
drm/nouveau: disable copy engine on NVAF
nouveau: fixup scanout enable in nvc0_pm
drm/nouveau/aux: mask off higher bits of auxch index in i2c table entry
drm/nvd0/disp: mask off high 16 bit of negative cursor x-coordinate
drm/nve0/fifo: add support for the flip completion swmthd
Dave Airlie [Wed, 15 Aug 2012 10:27:51 +0000 (20:27 +1000)]
Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Daniel Vetter writes:
"A few important fixers:
- fix various lvds backlight issues, regressed in 3.6 (Takashi Iwai)
- make the retina mbp work (ignore bogus edp bpc value in vbt)
- fix a gmbus regression introduced in (iirc) 3.4 (Jani Nikula)
- fix an edp panel power sequence regression, fixes the new macbook air
- apply the tlb invalidate w/a
Otherwise we still have another gmbus regression (patches are awaiting
tested-bys) and there's something odd going with some rare systems not
entering rc6 often enough (and hence blowing through too much power). It
seems to be a timing-related issue and can be mitigated by frobbing the
magic tuning parameters. We're still working on that one. Also, we still
have some fallout from the hw context support, but you can only hit that
with mesa master."
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: Apply post-sync write for pipe control invalidates
drm/i915: reorder edp disabling to fix ivb MacBook Air
drm/i915: ensure i2c adapter is all set before adding it
drm/i915: ignore eDP bpc settings from vbt
drm/i915: Fix blank panel at reopening lid
David S. Miller [Wed, 15 Aug 2012 07:37:29 +0000 (00:37 -0700)]
sparc64: Be less verbose during vmemmap population.
On a 2-node machine with 256GB of ram we get 512 lines of
console output, which is just too much.
This mimicks Yinghai Lu's x86 commit ccd3a32a52f9902d9687a8afb20161a9e7e20479
(x86_64/mm: check and print vmemmap allocation continuous) except that
we aren't ever going to get contiguous block pointers in between calls
so just print when the virtual address or node changes.
This decreases the output by an order of 16.
Also demote this to KERN_DEBUG.
Signed-off-by: David S. Miller <davem@davemloft.net>
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>
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>
Linus Torvalds [Tue, 14 Aug 2012 04:58:59 +0000 (07:58 +0300)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 patches from Martin Schwidefsky:
"Included are bug fixes and a patch to enable system call filtering
with BPF."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/compat: fix mmap compat system calls
s390/compat: fix compat wrappers for process_vm system calls
s390: do not clobber personality flags in sys_32_personality()
s390/seccomp: add support for system call filtering using BPF
s390/sclp_sdias: Add missing break and "fall through"
s390/mm: remove MAX_PHYSADDR_BITS define
Linus Torvalds [Tue, 14 Aug 2012 04:52:41 +0000 (07:52 +0300)]
Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"Radeon and intel fixes mostly, one fix to the mgag200 driver to not
hang on certain server variants."
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (32 commits)
drm/radeon: fix typo in function header comment
drm/radeon/kms: implement timestamp userspace query (v2)
drm/radeon/kms: add MSAA texture support for r600-evergreen
drm/radeon/kms: reorder code in r600_check_texture_resource
drm/radeon: fence virtual address and free it once idle v4
drm/radeon: fix some missing parens in asic macros
drm/radeon: add some new SI pci ids
drm/radeon: fix ordering in pll picking on dce4+
drm/radeon: do not reenable crtc after moving vram start address
drm/radeon: fix bank tiling parameters on cayman
drm/radeon: fix bank tiling parameters on evergreen
drm/radeon: fix bank tiling parameters on SI
drm/radeon: properly handle crtc powergating
drm/radeon: properly handle SS overrides on TN (v2)
drm/radeon/dce4+: set a more reasonable cursor watermark
drm/radeon: fix handling for ddc type 5 on combios
drm/mgag200: fix G200ER pll picking algorithm
drm/edid: Fix potential memory leak in edid_load()
drm/udl: Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(.. [1]
drm/radeon/kms: allow "invalid" DB formats as a means to disable DB
...
Arnd Bergmann [Mon, 13 Aug 2012 14:36:10 +0000 (14:36 +0000)]
GPIO: gpio-pxa: fix building without CONFIG_OF
Commit 44e9efc670 ("GPIO: gpio-pxa: fix devicetree functions") added an
"xlate" function pointer to the irq_domain_ops, but this function is nor
declared or defined anywhere when CONFIG_OF is disabled, causing the
build error:
drivers/gpio/gpio-pxa.c:532:11: error: 'irq_domain_xlate_twocell' undeclared here (not in a function)
Extending the DT-only code section to cover the irq_domain_ops and the
pxa_gpio_dt_ids solves this problem and makes it clearer which code is
actually used without DT.
Ben Skeggs [Fri, 27 Jul 2012 04:18:03 +0000 (14:18 +1000)]
drm/nouveau/aux: mask off higher bits of auxch index in i2c table entry
At least partially fixes DP output detection on W530. Not sure if more
issues remain, or if my adaptor is just behaving weirdly (it does that
sometimes).
Dave Airlie [Mon, 13 Aug 2012 23:25:01 +0000 (09:25 +1000)]
Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
Alex Deucher writes:
This is the current set of radeon fixes for 3.6. Nothing too major.
Highlights:
- various display fixes
- some SI fixes
- new SI pci ids
- major VM fix
- CS checker support for MSAA
I've tested on a number of cards across generations and noticed no problems.
* 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: fix typo in function header comment
drm/radeon/kms: implement timestamp userspace query (v2)
drm/radeon/kms: add MSAA texture support for r600-evergreen
drm/radeon/kms: reorder code in r600_check_texture_resource
drm/radeon: fence virtual address and free it once idle v4
drm/radeon: fix some missing parens in asic macros
drm/radeon: add some new SI pci ids
drm/radeon: fix ordering in pll picking on dce4+
drm/radeon: do not reenable crtc after moving vram start address
drm/radeon: fix bank tiling parameters on cayman
drm/radeon: fix bank tiling parameters on evergreen
drm/radeon: fix bank tiling parameters on SI
drm/radeon: properly handle crtc powergating
drm/radeon: properly handle SS overrides on TN (v2)
drm/radeon/dce4+: set a more reasonable cursor watermark
drm/radeon: fix handling for ddc type 5 on combios
Jani Nikula [Mon, 13 Aug 2012 14:33:02 +0000 (17:33 +0300)]
drm/i915: ensure i2c adapter is all set before adding it
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>
Jerome Glisse [Mon, 6 Aug 2012 16:32:21 +0000 (12:32 -0400)]
drm/radeon: fence virtual address and free it once idle v4
Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.
Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex locking.
v2: For to update pagetable when unbinding bo (don't bailout if
bo_va->valid is true).
v3: Add kernel 3.5/3.4 comment.
v4: Fix compilation warnings.
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
drm/radeon: do not reenable crtc after moving vram start address
It seems we can not update the crtc scanout address. After disabling
crtc, update to base address do not take effect after crtc being
reenable leading to at least frame being scanout from the old crtc
base address. Disabling crtc display request lead to same behavior.
So after changing the vram address if we don't keep crtc disabled
we will have the GPU trying to read some random system memory address
with some iommu this will broke the crtc engine and will lead to
broken display and iommu error message.
So to avoid this, disable crtc. For flicker less boot we will need
to avoid moving the vram start address.
Alex Deucher [Thu, 26 Jul 2012 17:38:52 +0000 (13:38 -0400)]
drm/radeon: properly handle crtc powergating
Need to make sure the crtc is gated on before modesetting.
Explicitly gate the crtc on in prepare() and set a flag
so that the dpms functions don't gate it off during
mode set.
Noticed by sylware on IRC.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
projects / kernel.git / log