- 17 Oct, 2012 7 commits
-
-
Paulo Zanoni authored
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>
-
Paulo Zanoni authored
Signed-off-by:
-
Paulo Zanoni authored
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:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Paulo Zanoni authored
Signed-off-by:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
-
Daniel Vetter authored
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:
-
- 16 Oct, 2012 3 commits
-
-
Ben Widawsky authored
CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
-
Ben Widawsky authored
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 authored
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:
-
- 11 Oct, 2012 1 commit
-
-
Damien Lespiau authored
We're talking about Spread Spectrum Clocks here, thus SSC. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
- 10 Oct, 2012 11 commits
-
-
Paulo Zanoni authored
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 authored
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 authored
Introduced in commit 87f8020e: 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 authored
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 authored
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 authored
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 authored
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 authored
It's just a copy of ironlake_crtc_mode_set. Signed-off-by:
-
Paulo Zanoni authored
Previously we were enabling it at mode_set but never disabling. Let's follow the mode set sequence. Signed-off-by:
-
Paulo Zanoni authored
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 authored
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:
-
- 08 Oct, 2012 4 commits
-
-
Chris Wilson authored
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 authored
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:
-
Damien Lespiau authored
This workaround is only valid for IVB and VLV and the write triggers an error on HSW. Signed-off-by:
-
Damien Lespiau authored
For the next person that checks these kind of things, without having to dig up the register definition. Signed-off-by:
-
- 07 Oct, 2012 2 commits
-
-
Wei Yongjun authored
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:
-
Damien Lespiau authored
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:
-
- 04 Oct, 2012 2 commits
-
-
Jesse Barnes authored
Workaround for a culling optimization. Signed-off-by:
-
Jesse Barnes authored
References: https://bugs.freedesktop.org/show_bug.cgi?id=50250Signed-off-by:
-
- 02 Oct, 2012 2 commits
-
-
Daniel Vetter authored
I'm official fed up with the yelling and useless indirection. Let it burn! Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Paulo Zanoni authored
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:
-
- 01 Oct, 2012 1 commit
-
-
Jani Nikula authored
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:
-
- 28 Sep, 2012 7 commits
-
-
Vijay Purushothaman authored
Fixed correct min, max vco limits and dip ctl reg Signed-off-by:
Vijay Purushothaman <vijay.a.purushothaman@intel.com> Signed-off-by:
Gajanan Bhat <gajanan.bhat@intel.com> Signed-off-by:
Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
-
Gajanan Bhat authored
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:
-
Vijay Purushothaman authored
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 authored
m n tu register offset has changed in Valleyview. Also fixed DP limit frequencies. Signed-off-by:
-
Vijay Purushothaman authored
Added DPIO data lane register definitions for Valleyview Signed-off-by:
-
Vijay Purushothaman authored
Fixed SDVOB and SDVOC bit definitions for Valleyview. Signed-off-by:
-
Vijay Purushothaman authored
Set hrawclk to 200 MHz and aux divider clock to 100 MHz for Valleyview. This enables the aux transactions in Valleyview. Signed-off-by:
-
