- 26 Oct, 2012 10 commits
-
-
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 <paulo.r.zanoni@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:Jani Nikula <jani.nikula@intel.com> 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:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-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:
Jesse Barnes <jbarnes@virtuousgeek.org> Tested-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 20 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:
-
Daniel Vetter authored
I want to move some dp link training helpers into this place, so in the future this won't be just about i2c any longer. Reviewed-by:
-
Mika Kuoppala authored
Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
Jani Nikula authored
Move the cached EDID from intel_dp and intel_lvds_connector to intel_connector. Unify cached EDID handling for LVDS and eDP, in preparation for adding more generic EDID caching later. Signed-off-by:
-
Jani Nikula authored
The caller, not intel_connector_update_modes(), should free the edid. This improves the reusability of intel_connector_update_modes(). Signed-off-by:
-
Jani Nikula authored
Pave the way for sharing some logic between eDP and LVDS. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Jani Nikula authored
Create a generic struct intel_panel for sharing a data structure and code between eDP and LVDS panels. Add the new struct to intel_connector so that later on we can have generic EDID and mode reading functions with EDID caching that transparently fallback to fixed mode when EDID is not available. Add intel_panel as a dummy first, and move data (such as the mentioned fixed mode) to it in later patches. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Jani Nikula authored
Since we do EDID caching in intel_dp_init, we can do the fixed mode initialization there too. This should not change the functionality apart from initializing fixed mode earlier. Particularly retain the behaviour of only falling back to VBT if EDID is not available to not regress commit 47f0eb22 Author: Keith Packard <keithp@keithp.com> Date: Mon Sep 19 14:33:26 2011 -0700 drm/i915: Only use VBT panel mode on eDP if no EDID is found Signed-off-by:
-
Jani Nikula authored
As there is 1:1 mapping between encoder and connector for the LVDS, the goal is to simply reduce the amount of noise within the connector functions, i.e. we split the encoder/connector for LVDS as best we can and try to only operate on the LVDS connector from the connector funcs and the LVDS encoder form the encoder funcs. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Jani Nikula authored
Get rid of saved int_lvds_connector and int_edp_connector in drm_i915_private. Signed-off-by:
-
Jani Nikula authored
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Jani Nikula authored
Introduce a local structure to move LVDS specific information away from the drm_i915_private and onto the LVDS connector. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Jani Nikula authored
In preparation for introducing intel_lvds_connector to move some of the LVDS specific storage away from drm_i915_private, first rename the encoder to avoid potential confusion. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
Linux 3.7-rc2 Backmerge to solve two ugly conflicts: - uapi. We've already added new ioctl definitions for -next. Do I need to say more? - wc support gtt ptes. We've had to revert this for snb+ for 3.7 and also fix a few other things in the code. Now we know how to make it work on snb+, but to avoid losing the other fixes do the backmerge first before re-enabling wc gtt ptes on snb+. And a few other minor things, among them git getting confused in intel_dp.c and seemingly causing a conflict out of nothing ... Conflicts: drivers/gpu/drm/i915/i915_reg.h drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_dp.c drivers/gpu/drm/i915/intel_modes.c include/drm/i915_drm.h Signed-off-by:
-
- 20 Oct, 2012 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64Linus Torvalds authored
Pull arm64 fixes from Catalin Marinas: "Main changes: - AArch64 Linux compilation fixes following 3.7-rc1 changes (MODULES_USE_ELF_RELA, update_vsyscall() prototype) - Unnecessary register setting in start_thread() (thanks to Al Viro) - ptrace fixes" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64: arm64: fix alignment padding in assembly code arm64: ptrace: use HW_BREAKPOINT_EMPTY type for disabled breakpoints arm64: ptrace: make structure padding explicit for debug registers arm64: No need to set the x0-x2 registers in start_thread() arm64: Ignore memory blocks below PHYS_OFFSET arm64: Fix the update_vsyscall() prototype arm64: Select MODULES_USE_ELF_RELA arm64: Remove duplicate inclusion of mmu_context.h in smp.c -
Marc Zyngier authored
An interesting effect of using the generic version of linkage.h is that the padding is defined in terms of x86 NOPs, which can have even more interesting effects when the assembly code looks like this: ENTRY(func1) mov x0, xzr ENDPROC(func1) // fall through ENTRY(func2) mov x0, #1 ret ENDPROC(func2) Admittedly, the code is not very nice. But having code from another architecture doesn't look completely sane either. The fix is to add arm64's version of linkage.h, which causes the insertion of proper AArch64 NOPs. Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
