- 19 Oct, 2012 2 commits
-
-
Damien Lespiau authored
Register 0x42020 was defined twice under the names PCH_DSPCLK_GATE_D and ILK_DSPCLK_GATE. This patch consolidate the 2 sets of defines in one. The transforms done are: PCH_DSPCLK_GATE_D -> ILK_DSPCLK_GATE_D ILK_DSPCLK_GATE -> ILK_DSPCLK_GATE_D DPARBUNIT_CLOCK_GATE_DISABLE -> ILK_DPARBUNIT_CLOCK_GATE_DISABLE ILK_DPARB_CLK_GATE -> ILK_DPARBUNIT_CLOCK_GATE_DISABLE DPFDUNIT_CLOCK_GATE_DISABLE -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE ILK_DPFD_CLK_GATE -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE ILK_CLK_FBC -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE DPFCRUNIT_CLOCK_GATE_DISABLE -> ILK_DPFCRUNIT_CLOCK_GATE_DISABLE ILK_DPFC_DIS1 -> ILK_DPFCRUNIT_CLOCK_GATE_DISABLE DPFCUNIT_CLOCK_GATE_DISABLE -> ILK_DPFCUNIT_CLOCK_GATE_DISABLE ILK_DPFC_DIS2 -> ILK_DPFCUNIT_CLOCK_GATE_DISABLE We have a VHRUNIT_CLOCK_GATE_DISABLE define for the pre-ILK DSPCLK_GATE_D. Even if the same bit is used in ILK_DSPCLK_GATE_D, other bits in the register change, so I went with re-defining it, well more precisely rename IVB_VRHUNIT_CLK_GATE, which is not specific to IVB+. So: IVB_VRHUNIT_CLK_GATE -> ILK_VHRUNIT_CLOCK_GATE_DISABLE VHRUNIT_CLOCK_GATE_DISABLE -> ILK_VHRUNIT_CLOCK_GATE_DISABLE (ILK+ code) This commit is only a renaming commit, further commits will clean up the logic. v2: Rename bit 5 and 7 to _ENABLE as setting them to 1 enables clock gating on their respective units, contrary to all of the other bits (Paulo Zanoni) 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>
-
Daniel Vetter authored
Single-threaded forcewake was only used on some early pre-production ivybridge machines, all the latest ones should use mt forcewake. And we already assume this in other places of the code (e.g. DERRMR support in the ddx, or the latest intel_gt_reset patch to reset any lingering forcewake references left behind by the bios), so don't bother here, too. Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
- 18 Oct, 2012 13 commits
-
-
Paulo Zanoni authored
This is the final remaining piece of Haswell DP enablement. After this patch, just calling intel_dp_init on any port will make DP work. We still do not do this because we're currently initializing HDMI on all the ports, so if we replace intel_hdmi_init with intel_dp_init, we will break HDMI, and we can't call both because they share the same registers. Signed-off-by:
-
Paulo Zanoni authored
Previous patch "drm/i915: add basic Haswell DP link train bits" implemented the basic structure to set the voltage levels and training patterns. This patch adds the higher-level bits that are part of the mode set sequence and hot plug. Signed-off-by:
-
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 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:
-
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:
-
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 10 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:
-
