- 26 Oct, 2012 26 commits
-
-
Yuly Novikov authored
LVDS allowed changing panel fitting scaling mode, while eDP didn't. Copied relevant code from LVDS to eDP. Signed-off-by:
Yuly Novikov <ynovikov@chromium.org> [Jani: use fitting mode in intel_panel, remove default mode change] Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Prepare for supporting scaling mode configuration also in eDP. Includes a drive-by-removal of an outdated comment about fitting mode. Signed-off-by:
-
Jani Nikula authored
At some point the DPCD size was increased, but the debug print not. While at it, switch to using hex dump. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
Damien Lespiau authored
Just like HSW, VLV does not have a sprite scale. Set intel_plane->can_scale accordingly. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Jani Nikula authored
SDVOB may be multiplexed with HDMIB. If it's not SDVOB, the same i2c adapter may be used for HDMIB, with the adjusted config (i.e. with GPIO bit-banging instead of gmbus). Restore i2c adapter config before error return from intel_sdvo_init(), letting HDMIB enjoy the joys of gmbus. Signed-off-by:
-
Jani Nikula authored
commit 63abf3ed Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Dec 8 16:48:21 2010 +0000 drm/i915/sdvo: Only use the SDVO pin if it is in the valid range added a default fallback if BIOS provides an invalid pin mapping, but failed to force GPIO bit-banging on it. Finish the job, and also clean up the function a bit. With bit-banging, setting the gmbus speed has no effect, so drop it. Signed-off-by:
-
Paulo Zanoni authored
Now that all the eDP enablement bits are there, we can actually try to use the eDP. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Paulo Zanoni authored
It's an important step :) Signed-off-by:
-
Paulo Zanoni authored
Signed-off-by:
-
Paulo Zanoni authored
The cdclk frequency is not always the same, so the value here should be adjusted to match it. Version 2: call intel_ddi_get_cdclk_freq instead of reading CDCLK_FREQ, because the register is just for earlier HW steppings. Signed-off-by:
-
Paulo Zanoni authored
Signed-off-by:
-
Paulo Zanoni authored
See the documentation for the DDI_FUNC_CTL register, EDP Input Select bits: when the EDP input selection is B, the VTOTAL_B must be programmed with the VTOTAL_EDP value, same thing for selection C. V2: Use I915_READ as suggested by Daniel Vetter. Signed-off-by:
-
Paulo Zanoni authored
Signed-off-by:
-
Paulo Zanoni authored
Same thing as the previous commits. Not renaming this one since it exists since way before Haswell. Signed-off-by:
-
Paulo Zanoni authored
Same as the other registers. This one also appeared on Haswell for the first time, so that's why we are renaming it. Signed-off-by:
-
Paulo Zanoni authored
Because the PIPECONF register is actually part of the CPU transcoder, not the CPU pipe. Ideally we would also rename PIPECONF to TRANSCONF to remind people that they should use the transcoder instead of the pipe, but let's keep it like this for now since most Gens still name it PIPECONF. Signed-off-by:
-
Paulo Zanoni authored
We need to check if any of the pipes is using TRANSCODER_EDP. V2: DDI_BUF_CTL was renamed, so fix the usage here. Signed-off-by:
-
Paulo Zanoni authored
Because there's one instance of the register per CPU transcoder and not per CPU pipe. This is another register that appeared for the first time on Haswell, and even though its Haswell name is PIPE_DDI_FUNC_CTL, it will be renamed to TRANS_DDI_FUNC_CTL, so let's just use the new naming scheme before it confuses more people. Notice that there's a big improvement on intel_ddi_get_hw_state due to the new TRANSCODER_EDP. V2: Also rename the register to TRANS_DDI_FUNC_CTL as suggested by Damien Lespiau. Signed-off-by:
-
Paulo Zanoni authored
This register appeared in Haswell. It does not have an EDP version because the EDP transcoder is always tied to the DDIA clock. Notice that if we call PIPE_CLK_SEL(pipe) when pipe is PIPE_A and transcoder is TRANSCODER_EDP we might introduce a bug, that's why this is a transcoder register even though it does not have an EDP version. Even though Haswell names this register PIPE_CLK_SEL, it will be renamed to TRANS_CLK_SEL in the future, so let's just start using the real name that makes more sense and avoids misusage. Signed-off-by:
-
Paulo Zanoni authored
Before Haswell we used to have the CPU pipes and the PCH transcoders. We had the same amount of pipes and transcoders, and there was a 1:1 mapping between them. After Haswell what we used to call CPU pipe was split into CPU pipe and CPU transcoder. So now we have 3 CPU pipes (A, B and C), 4 CPU transcoders (A, B, C and EDP) and 1 PCH transcoder (only used for VGA). For all the outputs except for EDP we have an 1:1 mapping on the CPU pipes and CPU transcoders, so if you're using CPU pipe A you have to use CPU transcoder A. When have an eDP output you have to use transcoder EDP and you can attach this CPU transcoder to any of the 3 CPU pipes. When using VGA you need to select a pair of matching CPU pipes/transcoders (A/A, B/B, C/C) and you also need to enable/use the PCH transcoder. For now we're just creating the cpu_transcoder definitions and setting cpu_transcoder to TRANSCODER_EDP on DDI eDP code, but none of the registers was ported to use transcoder instead of pipe. The goal is to keep the code backwards-compatible since on all cases except when using eDP we must have pipe == cpu_transcoder. V2: Comment the haswell_crtc_off chunk, suggested by Damien Lespiau and Daniel Vetter. We currently need the haswell_crtc_off chunk because TRANSCODER_EDP can be used by any CRTC, so when you stop using it you have to stop saying you're using it, otherwise you may have at some point 2 CRTCs claiming they're using TRANSCODER_EDP (a disabled CRTC and an enabled one), then the HW state readout code will get completely confused. In other words: Imagine the following case: xrandr --output eDP1 --auto --crtc 0 xrandr --output eDP1 --off xrandr --output eDP1 --auto --crtc 2 After the last command you could get a "pipe A assertion failure (expected off, current on)" because CRTC 0 still claims it's using TRANSCODER_EDP, so the HW state readout function will read it (through PIPECONF) and expect it to be off, when it's actually on because it's being used by CRTC 2. So when we make "intel_crtc->cpu_transcoder = intel_crtc->pipe" we make sure we're pointing to our own original CRTC which is certainly not used by any other CRTC. Signed-off-by:
-
Paulo Zanoni authored
On Ironlake we have one PCH transcoder and FDI per pipe, so we know that if ironlake_crtc_driving_pch returns false we can disable the PCH transcoder and we also know that when we disable the crtc we can also disable the PCH transcoder. On Haswell there is only 1 PCH transcoder and FDI and they can be used by any CRTC. So if for one specific crtc haswell_crtc_driving_pch returns false we can't assert anything about the state of the PCH transcoder or the FDI link without checking if any other CRTC is using the PCH. So on this commit remove the "assert_fdi_{t,r}x_disabled" form haswell_crtc_enable and also only disable FDI and the PCH transcoder if the port being disabled was actually a PCH port (we only have one port using PCH: the VGA port). Signed-off-by: -
Paulo Zanoni authored
By forking Ironlake and Haswell functions. The only callers are {ironlake,haswell}_crtc_enable anyway, and this way we won't need to add other checks on the Haswell version for the next gens. V2: Even simpler, as pointed by Jani Nikula. Signed-off-by: -
Paulo Zanoni authored
These functions were forked from their Ironlake versions, so now fix the gen checks to reflect the fact that they will only run on Haswell. It is worth noticing that we are not considering IBX/CPT possible on Haswell anymore. So far on Haswell enablement we kept trying to still consider IBX/CPT as a possibility with a Haswell CPU, but this was never tested, I really doubt it will work with the current code and we don't really have plans to support it. Future patches will remove the IBX/CPT code from other Haswell functions. Notice that we still have a WARN on haswell_crtc_mode_set in case we detect non-LPT PCH. Signed-off-by:
-
Paulo Zanoni authored
The last commit forked a Haswell version, so now we remove Haswell code from these functions. Signed-off-by:
-
Paulo Zanoni authored
The way we enable and disable the PCH on Haswell changed considerably since now we have only one PCH transcoder, so we can't keep the same asserts and we also can't just unconditionally disable the PCH transcoder for non-PCH outputs. So let's fork a Haswell version. These new functions look exactly the same as the ironlake versions. The next patches will introduce the differences. Signed-off-by:
-
Jani Nikula authored
Identical #define is now available in include/drm/drm_dp_helper.h, nuke the dupe. Signed-off-by:
-
- 24 Oct, 2012 4 commits
-
-
Daniel Vetter authored
That thing has grown way too big already. Also move around a comment to the right spot. Reviewed-by:
-
Daniel Vetter authored
Otherwise dp aux won't work on some hsw platforms, since they use a different rawclk than the 125MHz clock used thus far. To absolutely not change anything, round up: That way we get the old 63 divider for the default 125MHz clock. Reviewed-by:
-
Daniel Vetter authored
We need this when the bios forgets even to set that bit up. Most seem to do that, even when they don't set up anything else in the panel power sequencer. Note that on IBX the rawclk is variable according to Bspec, but everyone is using 125MHz. The rawclk is fixed to 125MHz on CPT, but luckily we still have the same register available. On hsw, different variants have different clocks, hence we need to check the register. Since other pieces are driven by the rawclock, too, keep the little helper in a central place. Reviewed-by:
-
Daniel Vetter authored
Like we already do for the LVDS panels. This seems to help greatly in setting up the backlight, since the BIOS might refuse to cooperate. Reviewed-by:
Paulo Zanoni <przanoni@gmail.com> Signed-off-by:
-
- 23 Oct, 2012 3 commits
-
-
Daniel Vetter authored
3 changes: - If a given value is unset, use the maximal limits from the eDP spec. - Write back the new values, since otherwise the panel power sequencing hw will not dtrt. - Revert the early bail-out in case the register values are unset. The last change reverts commit bfa3384a Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Apr 10 11:58:04 2012 -0700 drm/i915: check PPS regs for sanity when using eDP v2: - Unlock the PP regs as the very first thing. This is a required w/a for cpu eDP on port A, and generally a good idea. - Fixup the panel power control port selection bits. v3: Paulo Zanoni noticed that I've fumbled the computation of the spec limit values. Fix them up. We've also noticed that the t8/t9 values in the vbt/bios-programmed pp are much larger than any limits. My guess is that this is to conceal any backlight enable/disable delays. So by using the much shorter limits from the spec, which only concerns the sink, we risk that we might display before the backlight is fully on, or disable the output while the backlight still has afterglow. I've figured I don't care too much, since this will only happen when both the pp regs are not programmed, and the vbt tables don't contain anything useful. v4: Don't set the port selection bits on hsw/LPT, they don't exist any more. v5: Fixup spelling issues in comments, as noticed by Jesse Barnes. Reviewed-by:
-
Damien Lespiau authored
Haswell does not have a scaler in the sprite pipeline anymore, so let's ensure: 1/ We bail out of update_plate() when someone is trying to ask to display a scaled framebuffer, 2/ We never write to the nonexistent SPR_SCALE register v2: Smash in the fixup from Damien in the disable_plane function. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (for v1) Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (for v1) Signed-off-by: -
Daniel Vetter authored
... like the comment says. No idea whether this has any effect, but I guess it's better to not lie to the display by acking a test request and never following through with it. This goes back to the commit that originally introduced this code: commit a60f0e38 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Oct 20 15:09:17 2011 -0700 drm/i915: add DP test request handling Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Meh'ed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
- 22 Oct, 2012 7 commits
-
-
Daniel Vetter authored
Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Reviewed-by:
-
Daniel Vetter authored
Only really required for dp 1.2. I've hoped this would help with some link training woes I'm fighting, but alas those are only dp 1.1 devices. Also move a comment that went misplaced in the recent refactorings to the right spot again. Reviewed-by:
-
Daniel Vetter authored
This requires a few changes since that dpcd value is above the range currently cached by radeon. I've check the dp specs, and above 0xf there's a big gap and nothing that looks like we should cache it while a given device is plugged in. It's also the same value that i915.ko uses. Hence extend the various dpcd arrays in the radeon driver, use proper symbolic constants where applicable (one place overallocated the dpcd array to 25 bytes). Then also drop the rd_interval cache - radeon_dp_link_train_init re-reads the dpcd block, so the values we'll consume in train_cr and train_ce will always be fresh. To avoid needless diff-churn, #define the old size of dpcd as the new one and keep it around. v2: Alex Deucher noticed one place where I've forgotten to replace 8 with DP_RECEIVER_CAP_SIZE. Reviewed-by:
-
Daniel Vetter authored
Safe for the minor difference that the intel versions get an offset into the link_status as an argument, both are the same again. Reviewed-by:
-
Daniel Vetter authored
radeon and intel use the exact same definition. Reviewed-by:
-
Daniel Vetter authored
radeon and intel use the exact same definition. Reviewed-by:
-
