- 18 Oct, 2012 11 commits
-
-
Paulo Zanoni authored
We have to write the correct values inside intel_dp_set_m_n and then prevent these values from being overwritten later. V2: Unconfuse double negation. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Just a missing register. There is no problem to run this code when the output is HDMI. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Paulo Zanoni authored
Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Paulo Zanoni authored
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 authored
Signed-off-by:
-
Paulo Zanoni authored
Signed-off-by:
-
Paulo Zanoni authored
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:
-
Chris Wilson authored
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 authored
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:
-
Daniel Vetter authored
... 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:
-
Daniel Vetter authored
... since they don't apply to pre-pch platforms and could actually be harmful. Reviewed-by:
-
- 17 Oct, 2012 11 commits
-
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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 authored
Much simpler and looks more like the M/N code inside intel_display.c. Signed-off-by:
-
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 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:
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:
-
- 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 3 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:
-
