We should only write the DDI_BUF_CTL at this point for HDMI/DVI. For
DP we need to do this earlier, and the values written to the register
are also different.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The old rule that the AUX registers are just an offset (+4 and +10)
from output_reg is not true anymore, since output_reg in on the CPU
and some AUX regs are on the PCH.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: use the existing #defines as spotted by Damien Lespiau.]
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some BIOSes may forcibly suspend RC6 during their operation which
trigger a warning as we find the hardware in a perplexing state upon
first use. So far that appears to be the worst symptom as fortuituously
we use the same values as the BIOS for programming the FORCEWAKE register.
Reported-by: Oleksij Rempel <bug-track@fisher-privat.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We now no longer rely on this.
This is step 1 on a long journey to rid us of the save/restore
madness, which tends to lightly paper over many issues, and cause
tons of bad things itself ...
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: satisfy Paulo's ocd and drop the needless braces.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... instead of relying on the register save/restore madness to do this.
To extract a bit of code call drm_mode_config_reset both on resume
and boot-up and move the hw state frobbing from the crt_init to the
->reset callback. The crt connector is the only one with a ->reset
callback, hence we can easily do this.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... since they don't apply to pre-pch platforms and could actually be
harmful.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already do that as part of the ringbuffer re-setup at resume time.
Furthermore the register offset has moved on gen6+ around quite a bit,
and on ilk/gm45 we also need to restore the HWS reg for the bsd ring,
not just the render ring.
So again in kms mode this is only confusing a best, hence don't
bother.
v2: Fixup logic, noticed by Paulo Zanoni.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already call drm_irq_install/uninstall at the right time, which
will set up the irq registers with the correct values (through the
preinstall hooks).
For kms this is at best harmless, in the worst case we get an
interrupt when we don't really expect it.
v2: Fixup the logic, noticed by Paulo Zanoni.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We completely compute these anew in each modeset, hence we don't rely
on them containing anything valid after resume.
To avoid breaking any ums setup due to reordering of the reads/writes
simply don't reorder anything, but bracket the reads/writes into if
(!kms) conditionals. More churn, but safer.
v2: Fixup the logic, noticed by Paulo Zanoni.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Much simpler and looks more like the M/N code inside intel_display.c.
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>
Previously, the DP register was used for everything. On Haswell, it
was split into DDI_BUF_CTL (which is the new intel_dp->DP register)
and DP_TP_CTL.
The logic behind this patch is based on a patch written by Shobhit
Kumar, but the way the code was written is very different.
Credits-to: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fixup the logic error spotted by Jani Nikula.]
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In theory, all the DDI pipe settings should be set here, including
timing and M/N registers. For now, let's just set the DP MSA
attributes.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: fixed up the unused typo in a #define, spotted by Jani
Nikula.]
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
No functional change, but reserves 0x2 for use by userspace.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the introduction of per-process GTT space, the hardware designers
thought it wise to also limit the ability to write to MMIO space to only
a "secure" batch buffer. The ability to rewrite registers is the only
way to program the hardware to perform certain operations like scanline
waits (required for tear-free windowed updates). So we either have a
choice of adding an interface to perform those synchronized updates
inside the kernel, or we permit certain processes the ability to write
to the "safe" registers from within its command stream. This patch
exposes the ability to submit a SECURE batch buffer to
DRM_ROOT_ONLY|DRM_MASTER processes.
v2: Haswell split up bit8 into a ppgtt bit (still bit8) and a security
bit (bit 13, accidentally not set). Also add a comment explaining why
secure batches need a global gtt binding.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
[danvet: added hsw fixup.]
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Somehow this was left out in the refactoring that introduced the pch
handlers. Avoids a hotplug_mask special case in the ilk_irq_handler.
Noticed while hunting down the pch hotplug bits.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BIOS should be setting the minimum voltage for rc6 to be 450mV. Old or
buggy BIOSen may not be doing this, so we correct it for them. Ideally
customers should update the BIOS as only it would know the optimal
values for the platform, so we leave that fact as a DRM_ERROR for the
user to see.
Unfortunately this isn't fixing any of the issues it was targeted to
fix, but it is documented that we must do it.
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: Matt Turner <mattst88@gmail.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: bikeshedded loglevel of the "your bios is broken message" to
debug.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is a special mechanism for communicating with the PCU already
being used for the ring frequency stuff. As we'll be needing this for
other commands, extract it now to make future code less error prone and
the current code more reusable.
I'm not entirely sure if this code matches 1:1 with the previous code
behaviorally. Functionally however, it should be the same.
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Fixup compile fail reported by Wu Fengguang.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So WARN in case they're not. It also does not make any sense to
wait_for_vblank at this point.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And also properly wait for its idle bit.
You may notice that DDI_BUF_CTL is enabled in .enable but disabled in
.post_disable instead of .disable. Yes, the mode set sequence is not
exactly symmetrical, but let's assume the spec is correct unless we
can prove it's wrong.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Introduced in commit 87f8020ec9e3069597746040a4e8655189bc0c1a:
drm/i915: implement WaDisableEarlyCull for VLV and IVB
Notice that the original patch sent to the mailing list did not
include the Haswell chunk, it was added later.
The bit set by the commit does not exist on Haswell machines (at least
that's what the documentation says). Also, the commit gives me a GPU
hang every time we're loading the driver. So let's revert the Haswell
chunk, making the patch do only what its title actually says.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just set the only bit we need, everything else is either ignored on
HDMI or should be set to zero.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Problems with the previous code:
- HDMI just uses WRPLL1 for everything, so dual head cases might not
work sometimes.
- At encoder->mode_set we just write the PLL register without doing
any kind of check (e.g., check if the PLL is already being used).
- There is no way to fail and return error codes at
encoder->mode_set.
- We write to PORT_CLK_SEL at mode_set and we never disable it.
- Machines hang due to wrong clock enable/disable sequence.
So here we rewrite the code, making it a little more like the
pre-Haswell PLL mode set code:
- Check PLL availability at ironlake_crtc_mode_set.
- Try to use both WRPLLs.
- Check if PLLs are used before actually trying to use them, and
properly fail with error messages.
- Enable/disable PORT_CLK_SEL at the right place.
- Add some WARNs to check for bugs.
The next improvement will be to try to reuse PLLs if the timings
match, but this is content for another patch and it's already
documented with a TODO comment.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's a copy of ironlake_set_pipeconf with 2 differences:
- There is no BPC field to set.
- The interlaced mask is now 2 bits instead of 3.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On ironlake_crtc_mode_set, WARN if not using IBX or CPT.
On haswell_crtc_mode_set, only run IBX/CPT code on IBX/CPT. I am still
not sure whether IBX/CPT will be possible with a Haswell CPU, so leave
the code there for now and put a WARN in case we spot it.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's just a copy of ironlake_crtc_mode_set.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Previously we were enabling it at mode_set but never disabling. Let's
follow the mode set sequence.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And the right time is exactly after/before changing PIPE_CONF. See the
documentation about the mode set sequence.
This code is not inside any encoder-specific callback because
DDI_FUNC_CTL is part of the pipe, so it is used by all encoders.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Right now, we're trying to enable LCPLL at every mode set, but we're
never disabling it. Also, we really don't want to be disabling LCPLL
since it requires a very complex disable/enable sequence. This
register should really be set by the BIOS and we shouldn't be touching
it. Still, let's try to check its value and print some errors in case
we find something wrong. We're also adding intel_ddi_get_cdclk_freq
which will be used later in other places.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By using round_jiffies() we can align the wakeup of our worker to the
nearest second in order to batch wakeups and reduce system load, which
is useful for unimportant coarse tasks like our retire_requests.
v2: round_jiffies_relative() already returns the relative timeout value,
so no need to incorrectly perform the subtraction twice. The timer
interface still leaves the possibility for the value of jiffies to
change be we program the timer.
Suggested-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
round_jiffies() aligns the wakeup time to the nearest second in order to
batch wakeups and reduce system load, which is useful for unimportant
coarse timers like our hangcheck.
v2: round_jiffies_relative() returns the relative jiffie value, whereas
we need the absolute value for the timer.
Suggested-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This workaround is only valid for IVB and VLV and the write triggers an
error on HSW.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanonI@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For the next person that checks these kind of things, without having to
dig up the register definition.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Remove duplicated include.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's is another register (a read only, so no harm done) at 0x42020 on
Haswell GPUs. Let's just remove the write from the copy&paste that
introduced haswell_init_clock_gating().
A note for the interested reader, it does seem we have a duplication of
the 0x42020 register definition, hence the removal of 2 writes. That
duplication could be the object of a later patch.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Workaround for a culling optimization.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Also apply to haswell, spotted by Damien.]
Reviewed-by: "Lespiau, Damien" <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I'm official fed up with the yelling and useless indirection.
Let it burn!
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Version 2: call intel_set_pipe_timings from both i9xx_crtc_mode_set
and ironlake_crtc_mode_set, instead of just ironlake, as requested by
Daniel Vetter.
The problem caused by calling this function from i9xx_crtc_mode_set
too is that now on i9xx we write to PIPESRC before writing to DSPSIZE
and DSPPOS. I could not find any evidence in our documentation that
this won't work, and the docs actually say the pipe registers should
be set before the plane registers.
Version 3: don't remove pipeconf bits on i9xx_crtc_mode_set.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make it easier to track backlight set requests coming through ASLE instead
of the driver's own backlight sysfs interface. We've had enough of
backlight issues to warrant some extra debug logs in the area.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Eventhough Valleyview display block is derived from Cantiga, VLV
supports eDP. So, added eDP checks in i9xx_crtc_mode_set path.
v2: use different DPIO_DIVISOR values for VGA, DP and eDP
v3: fix DPIO value calculation to use same values for all display
interfaces
v4: removed unconditional enabling of 6bpc dithering based on comments
from Daniel & Jani Nikula. Also changed the display enabling order to
force eDP detection first.
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In valleyview voltageswing, pre-emphasis and lane control registers can
be programmed only through the h/w side band fabric.
Cleaned up DPLL calculations for Valleyview to support multi display
configurations.
v2: Based on Daniel's feedbacak, moved crt hotplug detect work around as separate
patch. Also moved i9xx_update_pll_dividers to i8xx_update_pll and
i9xx_update_pll.
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: drop spurious whitespace changes.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
m n tu register offset has changed in Valleyview. Also fixed DP limit
frequencies.
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Added DPIO data lane register definitions for Valleyview
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni