summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-05-16drm/i915/lvds: Remove ->mode_set callbackDaniel Vetter
All the hard work was already done, only thing left to do is remove the empty callback. And a now rather misleading comment I've spotted while reading through code. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16drm/i915/hdmi: Remove ->mode_set callbackDaniel Vetter
Similar to dp the only thing we do is call intel_write_eld and prepare a bit of state for the enable hooks. The only difference is that we write that to the hardware instead of keeping track of it somewhere in software. Still we can just move all this to the very first enable hook. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16drm/i915/hdmi: Remove redundant IS_VLV checksDaniel Vetter
Those functions are only used on vlv platforms, so no need to check. Especially if we're not too consistent about it. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16drm/i915/dp: Remove ->mode_set callbackDaniel Vetter
With all the preceding refactoring the dp mode_set callback only computes a bit of state (all derived from the pipe config) and also writes the eld. As long as we do that before we enable the audio bit or depend upon the correct value in intel_dp->DP we'll be fine. No other hw state is touched. We therefore only need to check that clearing intel_dp->DP is save. Which it is since when we re-enable we already mask out all the bits the link training code sets. And we need to keep on doing that so that the re-train loop walking over pre-emph/voltage-swing values still works properly. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16drm/i915/dp: Move port A pll setup to g4x_pre_enable_dpDaniel Vetter
Only ilk/snb/ivb need the port A pll setup, so move it to the pre_enable hook for those platforms. We can savely do this since on those platforms there's nothing that touches the hardware between the encoder->mode_set and the encoder->pre_enable calls. Also add a comment that port A is ilk+ only. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16drm/i915: Track has_audio in the pipe configDaniel Vetter
Including state readout and cross-checking. This allows us to get rid of crtc->eld_vld on hsw+. It also means that fastboot will be unhappy if the BIOS hasn't set up the audio routing like we want it too. Wrt fastboot and external screens I see a few options: - Don't. - Try to fix up eld, infoframes and audio settings after the fact. But that means some pretty extensive reworking of our code which currently does all this while the pipe/port is still off. I won't bother with converting SDVO over to this because the audio support for SDVO is very lacking: - We don't update the eld. - We don't update the audio state on the sdvo encoder. - We don't check whether the platform can even feed audio to the sdvo encoder. I've converted hdmi, dp & ddi all in one go since ddi needs both hdmi and dp converted and so doing it step-by-step would have required a few intermediate hacks. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16drm/i915: Simplify audio handling on DDI portsDaniel Vetter
There's no need to check whether audio is enabled (which for ddi ports is done through the crtc->eld_vld flag) since at the cost of a potentially unecessary register rmw cycle we can unconditionally do this. Note that the edp check is just paranoia since we won't ever call the write_eld function for an edp panel. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16drm/i915/sdvo: use config->has_hdmi_sinkDaniel Vetter
This way we can rely on the state cross-checker to have a bit assurance that we'll get it right. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16drm/i915: state readout and cross checking for limited_color_rangeDaniel Vetter
At least on those platforms which have a simple bit and don't rely on the fully programmable CSC unit to do this. Note that with the current code this includes CHV, but I guess that platform will match BYT. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16drm/i915/sdvo: Use pipe_config->limited_color_range consistentlyDaniel Vetter
We in the pre_enable hook we should only rely on the pipe config and not on some other state set through properties or detect functions. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16drm/i915: Track hdmi mode in the pipe configDaniel Vetter
Also add state readout and cross-check support. The only invasive change is wiring up the new flag to the ->set_infoframes callbacks. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16drm/i915/hdmi: Enable hdmi mode on g4x, tooDaniel Vetter
For compliance we really should be sending NULL infoframes always when we detect a hdmi capable monitor. Also remove the now redudant setting for the has_audio case and enforce that audio is only possible with a hdmi sink. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15drm/i915: Enable rc6 with bdwMika Kuoppala
Everything should be in place so enable rc6/rps for bdw. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15drm/i915: Fix rc6 options debug infoMika Kuoppala
by correctly displaying result and requested. Suggested-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15drm/i915: Enable PM Interrupts target via Display Interface.Deepak S
In BDW, Apart from unmasking up/down threshold interrupts. we need to umask bit 32 of PM_INTRMASK to route interrupts to target via Display Interface. v2: Add (1<<31) mask (Ville) v3: Add Gen check for the mask (ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15drm/i915/bdw: Implement a basic PM interrupt handlerBen Widawsky
Almost all of it is reusable from the existing code. The primary difference is we need to do even less in the interrupt handler, since interrupts are not shared in the same way. The patch is mostly a copy-paste of the existing snb+ code, with updates to the relevant parts requiring changes to the interrupt handling. As such it /should/ be relatively trivial. It's highly likely that I missed some places where I need a gen8 version of the PM interrupts, but it has become invisible to me by now. This patch could probably be split into adding the new functions, followed by actually handling the interrupts. Since the code is currently disabled (and broken) I think the patch stands better by itself. v2: Move the commit about not touching the ringbuffer interrupt to the snb_* function where it belongs (Rodrigo) v3: Rebased on Paulo's runtime PM changes v4: Not well validated, but rebase on commit 730488b2eddded4497f63f70867b1256cd9e117c Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Mar 7 20:12:32 2014 -0300 drm/i915: kill dev_priv->pm.regsave v5: Rebased on latest code base. (Deepak) v6: Remove conflict markers, Unnecessary empty line and use right IIR interrupt (Ville) v7: mask modified without rmw (Ville Syrjälä) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15drm/i915: Bail out early on gen6_signal if no semaphoresMika Kuoppala
If we dont have semaphores enabled, we allocate 4 dwords for signalling. But end up emitting more regardless. Fix this by bailing out early if semaphores are not enabled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78274 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78283 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15drm/i915: MIPI PPS delays addedShobhit Kumar
Added as generic parameters which will be initialized in the panel driver and are specific to panels. Backlight delays have also kept as placeholders and will be used used once we have MIPI backlight enabling support Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15drm/i915: MIPI init count programming as generic parameterShobhit Kumar
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15drm/i915: Correct MIPI operation mode as per expected values from VBTShobhit Kumar
In VBT fields operation mode is 0 for Video mode and 1 for command mode. This field will be directly used as is in generic panel driver. So adjust accordingly. Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14drm/i915: add null render states for gen6, gen7 and gen8Mika Kuoppala
These are generated with intel-gpu-tools/tools/null_state_gen v2: Don't use header file for states (Daniel Vetter) v3: Proper URB state size for gen8/GT3 (Damien Lespiau) Tested-by: Kristen Carlson Accardi <kristen@linux.intel.com> (v1) Tested-by: Oscar Mateo <oscar.mateo@intel.com> (v2) Acked-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14drm/i915: add render state initializationMika Kuoppala
HW guys say that it is not a cool idea to let device go into rc6 without proper 3d pipeline state. For each new uninitialized context, generate a valid null render state to be run on context creation. This patch introduces a skeleton with empty states. v2: - No need to vmap (Chris Wilson) - use .c files for state (Daniel Vetter) - no need to flush as i915_add_request does it - remove parameter for batch alloc size - don't wait for the init (Ben Widawsky) v3: - move to cpu/gpu (Chris Wilson) Tested-by: Kristen Carlson Accardi <kristen@linux.intel.com> (v1) Tested-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14drm/i915: Only do gtt cleanup in vma_unbind for the global vmaDaniel Vetter
Otherwise we end up tearing down fences when e.g. the client quits way too early. Might or might not fix a fence pin_count BUG Ville has reported. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14drm/i915: Don't drop pinned fencesDaniel Vetter
Userspace can currently provoke this when e.g. trying to use a pinned scanout as a cursor or overlay target. Later on that might lead to some fun fence pin count mayhem. Spurred by Ville's report that something goes wrong here and originally I've thought that this might slip through the pwrite gtt fastpath. But that one checks of obj tiling, so should be ok. But one thing that _does_ blow up is the vma unbinding with more than one address space. The next patch will fix this. v2: Use a WARN_ON - Chris pointed out that we already catch all cases so userspace can't provoke this like I've originally feared. While reviewing relevant code I've noticed a pile of DRM_ERROR in the overlay&cursor code which are all triggerable by userspace. Tune them down while at it. v3: Split out the DRM_ERROR->DRM_DEBUG_KMS change into a separate patch, as requested by Chris. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14drm/i915: use dev_priv directly in i915_driver_unloadDaniel Vetter
Noticed while playing with coccinelle. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14drm/i915: Use the connector name in fbdev debug messagesChris Wilson
During initial probing of the modes to assign to the fbdev console, we use the CRTC and connector ids. These are much harder for us to understand than if we used their actual names (or pipe in the CRTC case). Similarly, we want to manually print the mode size rather than rely on mode->name being set. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14drm/i915: Use for_each_crtc() when iterating through the CRTCsDamien Lespiau
Patch done using the following semantic patch (thanks Daniel for the help!) @@ iterator name list_for_each_entry; iterator name for_each_crtc; struct drm_crtc * crtc; struct drm_device * dev; @@ -list_for_each_entry(crtc,&dev->mode_config.crtc_list, head) { +for_each_crtc(dev,crtc) { ... } Followed by a couple of fixups by hand (that spatch doesn't match the cases where list_for_each_entry() is not followed by a set of '{', '}', but I couldn't figure out a way to leave the '{' out of the iterator match). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14drm/i915: Introduce a for_each_crtc() macroDamien Lespiau
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14drm/i915: Use for_each_intel_crtc() when iterating through intel_crtcsDamien Lespiau
Generated using the semantic patch: @@ iterator name list_for_each_entry; iterator name for_each_intel_crtc; struct intel_crtc * crtc; struct drm_device * dev; @@ -list_for_each_entry(crtc,&dev->mode_config.crtc_list,...) { +for_each_intel_crtc(dev,crtc) { ... } Followed by a couple of fixups by hand (that spatch doesn't match the cases where list_for_each_entry() is not followed by a set of '{', '}', but I couldn't figure out a way to leave the '{' out of the iterator match). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14drm/i915: Introduce a for_each_intel_crtc() macroDamien Lespiau
Fed up with having that long list_for_each_entry() invocation? Use for_each_intel_crtc()! Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13drm/i915: Use ilk_wm_max_level() in latency debugfs filesDamien Lespiau
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Squash in patch that exported ilk_wm_max_level.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13drm/i915: Don't cast void* pointersDamien Lespiau
That's not necessary and makes the code not as neat as it could be. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13drm/i915: Work-around garbage DR4 from UXADaniel Vetter
Somehow UXA submits a completely bogus DR4 value since essentially forever. It was originally introduced in commit bade7d7d2505a10a8a7d24b084aff9742e2d6d64 Author: Eric Anholt <eric@anholt.net> Date: Fri Jun 6 14:03:25 2008 -0700 Use the DRM for submitting batchbuffers when available. and dutifully copied around ever since. Since we want to keep the general dirt catching around just special case the UXA value. This regression was introduced in commit 9cb346648d9c529eccc5c7f30093e82d37004e37 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Apr 24 08:09:11 2014 +0200 drm/i915: Catch dirt in unused execbuffer fields Comment from Chris' review: "To be fair, it is a sensible value if one supposes a Region style API to cliprects. Under that API, DR[14] define the extents of the clip region, and ((0,0), (0,0)) [DR1==DR4==0] would mean all clipped, do not draw anything." v2: Pimp commit message a bit and remove the double space. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78494 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jörg Otte <jrg.otte@gmail.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13drm/i915: WARN_ON fence pin leaksDaniel Vetter
The fence pin count should always be <= the bo pin count. If that's not the case then we have a funny problem and are leaking references somewhere. Which means we can catch fence pin leaks by checking for the same upper limit as we do for the bo pin count. Inspired by a discussion with Ville about a fence leak igt testcase. v2: Also check for fence->pin_count <= ggtt_vma->pin_count, since that might catch a leak even quicker. Also de-inline them, they're getting too big. v3: Don't separately check for MAX_PIN_COUNT since the > vma->pin_count check will catch that already (Chris). Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13drm/i915: Kill vblank waits after pipe enable on gmch platformsVille Syrjälä
The pipe might not start to actually run until the port has been enabled (depends on the platform and port type). So don't try to wait for vblank after we enabled the pipe but haven't yet enabled the port. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> References: https://bugs.freedesktop.org/show_bug.cgi?id=77297 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13drm/i915: Disable/enable planes as the first/last thing during modeset on ↵Ville Syrjälä
gmch platforms We already moved the plane disable/enable to happen as the first/last thing on every other platforms. Follow suit with gmch platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Frob drm_vblank_on conflict, as usual.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13drm/i915: Ringbuffer signal func for the second BSD ringOscar Mateo
This is missing in: commit 78325f2d270897c9ee0887125b7abb963eb8efea Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Tue Apr 29 14:52:29 2014 -0700 drm/i915: Virtualize the ringbuffer signal func Looks to me like a rebase side-effect... Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13x86/gpu: Sprinkle const, __init and __initconst to stolen memory quirksVille Syrjälä
gen8_stolen_size() is missing __init, so add it. Also all the intel_stolen_funcs structures can be marked __initconst. intel_stolen_ids[] can also be made const if we replace the __initdata with __initconst. Cc: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13x86/gpu: Implement stolen memory size early quirk for CHVDamien Lespiau
CHV uses the same bits as SNB/VLV to code the Graphics Mode Select field (GFX stolen memory size) with the addition of finer granularity modes: 4MB increments from 0x11 (8MB) to 0x1d. Values strictly above 0x1d are either reserved or not supported. v2: 4MB increments, not 8MB. 32MB has been omitted from the list of new values (Ville Syrjälä) v3: Also correctly interpret GGMS (GTT Graphics Memory Size) (Ville Syrjälä) v4: Don't assign a value that needs 20bits or more to a u16 (Rafael Barbalho) [vsyrjala: v5: Split from i915 changes and add chv_stolen_funcs] Cc: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com> Tested-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13drm/i915/chv: Implement stolen memory size detectionDamien Lespiau
CHV uses the same bits as SNB/VLV to code the Graphics Mode Select field (GFX stolen memory size) with the addition of finer granularity modes: 4MB increments from 0x11 (8MB) to 0x1d. Values strictly above 0x1d are either reserved or not supported. v2: 4MB increments, not 8MB. 32MB has been omitted from the list of new values (Ville Syrjälä) v3: Also correctly interpret GGMS (GTT Graphics Memory Size) (Ville Syrjälä) v4: Don't assign a value that needs 20bits or more to a u16 (Rafael Barbalho) [vsyrjala: v5: Split the early quirks to another patch] Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com> Tested-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13drm/i915/chv: CHV doesn't have CRT outputVille Syrjälä
No CRT output on CHV, so don't call intel_crt_init(). v2: Don't disable CRT on HAS. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13drm/i915/chv: Add DPLL state readout supportVille Syrjälä
Add chv_crtc_clock_get() to read out the DPLL settings. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Fix compile due to bikeshedded headers in an earlier patch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-12drm/i915/chv: Pipe select change for DP and HDMIChon Ming Lee
With additional of pipe C, current 1 bit registers for pipe select for HDMI and DP are no longer able to gather for 3 pipes. As a result, new bits location in the same registers are added. For HDMI, VLV uses bit 30, CHV uses bit 24-25. For DP, VLV uses bit 30, CHV uses bit 16-17. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-12drm/i915/chv: Add phy supports for CherryviewChon Ming Lee
Added programming phy layer for CHV based on "Application note for 1273 CHV Display phy". v2: Rebase the code and do some cleanup. v3: Rework based on Ville review. -Fix the macro where the ch info need to swap, and add parens to ? operator. -Fix wrong bit define for DPIO_PCS_SWING_CALC_0 and DPIO_PCS_SWING_CALC_1 and rename for meaningful. -Add some comments for CHV specific DPIO registers. -Change the dp margin registery value to decimal to align with the doc. -Fix the not clearing some value in vlv_dpio_read before write again. -Create new hdmi/dp encoder function for chv instead of share with valleyview. v4: Rebase the code after rename the DPIO registers define and upstream change. Based on Ville review. -For unique transition scale selection, after Ville point out, look like the doc might wrong for the bit 26. Use bit 27 for ch0 and ch1. -Break up some dpio write value into two/three steps for readability. -Remove unrelated change. -Add some shift define for some registers instead just give the hex value. -Fix a bug where write to wrong VLV_TX_DW3. v5: Based on Ville review. - Move tx lane latency optimal setting from chv_dp_pre_pll_enable to chv_pre_enable_dp, and chv_hdmi_pre_pll_enable to chv_hdmi_pre_enable respectively. - Fix typo in one margin_reg_value for DP_TRAIN_VOLTAGE_SWING_400. - Clear DPIO_TX_UNIQ_TRANS_SCALE_EN for DP and HDMI. - Mask the old deemph and swing bits for hdmi. v6: Remove stub for pre_pll_enable for dp and hdmi. Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [vsyrjala: Don't touch panel power sequencing on DP] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-12drm/i915/chv: Add update and enable pll for CherryviewChon Ming Lee
Added programming PLL for CHV based on "Application note for 1273 CHV Display phy". v2: -Break the common lane reset into another patch. -Break the clock calculation into another patch. -The changes are based on Ville review. -Rework based on DPIO register define naming convention change. -Break the dpio write into few lines to improve readability. -Correct the udelay during chv_enable_pll. -clean up some magic numbers with some new define. -program the afc recal bit which was missed. v3: Based on Ville review - minor correction of the bit defination - add deassert/propagate data lane reset v4: Corrected the udelay between dclkp enable and pll enable. Minor comment and better way to clear the TX lane reset. v5: Squash in fixup from Rafael Barbalho. [vsyrjala: v6: Polish the defines (Imre)] Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-12drm/i915/chv: find the best divisor for the target clock v4Chon Ming Lee
Based on the chv clock limit, find the best divisor. The divisor data has been verified with this spreadsheet. P1273_DPLL_Programming Spreadsheet. v2: Rebase the code and change the chv_find_best_dpll based on new standard way to use intel_PLL_is_valid. Besides, clean up some extra variables. v3: Ville suggest better fixed point for m2 calculation. v4: -Add comment for the limit is compute using fast clock. (Ville) -Don't pass the request clock to chv_clock, as the same function will be use clock readout, which doens't have request clock. (Ville) -Add and use DIV_ROUND_CLOSEST_ULL to consistent with other clock calculation. (Ville) -Fix the dp m2 after m2 has stored fixed point. (Ville) Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> [vsyrjala: Avoid div-by-zero in chv_clock()] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-12drm/i915/chv: Trigger phy common lane resetChon Ming Lee
During cold boot, the display controller needs to deassert the common lane reset. Only do it once during intel_init_dpio for both PHYx2 and PHYx1. Besides, assert the common lane reset when disable pll. This still to be determined whether need to do it by driver. Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> [vsyrjala: Don't disable DPIO PLL when using DSI] [vsyrjala: Don't call vlv_disable_pll() by accident on CHV] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Move part of a moved comment back as suggested by Imre since it's valid for both byt and chv.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-12drm/i915/chv: Add vlv_pipe_to_channelChon Ming Lee
Cherryview has 3 pipes. Some of the pll dpio offset calculation is based on pipe number. Need to use vlv_pipe_to_channel to calculate the correct phy channel to use for the pipe. Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-12drm/i915/chv: Update Cherryview DPLL changes to support Port D. v2Chon Ming Lee
The additional DPLL registers added to support Port D. Besides, add some new PHY control and status registers based on B-spec. v2: Based on Ville review - Corrected DPIO_PHY_STATUS offset and name. - Rebase based on upstream change after introduce enum dpio_phy and enum dpio_channel. v3: Rebased on top of Antti's 3-pipe prep patch. Note that the new offsets for the DPLL registers aren't in place yet, so this introduces a slight regression. But since 3 pipe support isn't fully enabled yet anyaway in -internal this shouldn't matter too much. Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-12drm/i915/chv: Add DPIO offset for Cherryview. v3Chon Ming Lee
CHV has 2 display phys. First phy (IOSF offset 0x1A) has two channels, and second phy (IOSF offset 0x12) has single channel. The first phy is used for port B and port C, while second phy is only for port D. v2: Move the pipe to determine which phy to select for vlv_dpio_read/vlv_dpio_write to another patch. (Daniel) v3: Rebase the code based on rework on how to calculate DPIO offset. Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 22:53:57 +0000