- 11 Nov, 2012 40 commits
-
-
Paulo Zanoni authored
We had 2 places using X2 and one place using X1. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Now that we no longer pretend to have flexibility in matching any north display block with any pch, we can ditch this. v2: Fix the embarassing rebase fail that Paulo Zanoni spotted. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Found in Bspec vol4h South Display Engine Registers [CPT, PPT], section "5.3.1 TRANS_CHICKEN_1—Transcoder Chicken Bits 1" v2: Make it compile. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
We need to set the timing override chicken bit after fdi link training has completed and before we enable the transcoder. We also have to clear that bit again after disabling the pch transcoder. See "Graphics BSpec: vol4g North Display Engine Registers [IVB], Display Mode Set Sequence" and "Graphics BSpec: vol4h South Display Engine Registers [CPT, PPT], South Display Engine Transcoder and FDI Control, Transcoder Debug and DFT, TRANS_CHICKEN_2" bit 31: "Workaround : Enable the override prior to enabling the transcoder. Disable the override after disabling the transcoder." While at it, use the _PIPE macro for the other TRANS_DP register. v2: Keep the w/a as-is, but kill the original (but wrongly placed) workaround introduced in commit 3bcf603f Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Jul 27 11:51:40 2011 -0700 drm/i915: apply timing generator bug workaround on CPT and PPT and commit d4270e57 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Oct 11 10:43:02 2011 -0700 drm/i915: export a CPT mode set verification function Note that this old code has unconditionally set the w/a, which might explain why fdi link training sometimes silently fails, and especially why the auto-train did not seem to work properly. v3: Paulo Zanoni pointed out that this workaround is also required on the LPT PCH. And Arthur Ranyan confirmed that this workaround is requierd for all ports on the pch, not just DP: The important part is that the bit is set whenever the pch transcoder is enabled, and that it is _not_ set while the fdi link is trained. It is also important that the pch transcoder is fully disabled, i.e. we have to wait for bit 30 to clear before clearing the w/a bit. Hence move to workaround into enable/disable_transcoder, where the pch transcoder gets enabled/disabled. v4: Whitespace changes dropped. v5: Don't run the w/a on IBX, we only need it on CPT/PPT and LPT. v6: - resolve conflicts with Paulo's big hsw vga rework - s/!IBX/CPT since hsw paths are now all separate, and Paulo's patch to implement the equivalent w/a for LPT is already merged. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Arthur Ranyan <arthur.j.runyan@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v5) Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v5) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
They are all written for a specific north disaplay->pch combination. So stop pretending otherwise. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
We don't really support fancy north display/pch combinations, so put a big yelling WARN_ON in there. It /should/ be impossible, but alas, the rumours don't stop (mostly due to really early silicon sometimes using older PCHs). v2: Fixup the logic fumble noticed by Paulo Zanoni. I should actually try to test run the patch next time around ... Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
This essentially reverts commit cb0953d7 Author: Adam Jackson <ajax@redhat.com> Date: Fri Jul 16 14:46:29 2010 -0400 drm/i915: Initialize LVDS and eDP outputs before anything else simply because it doesn't scale: It misses SDVO and DVO panels, and now with DDI encoders on haswell this is becoming unmanageable. Instead we simply sort the connector list after everything is set up. Reviewed-by: Adam Jackson <ajax@redhat.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Userspace seems to like this, see commit cb0953d7 Author: Adam Jackson <ajax@redhat.com> Date: Fri Jul 16 14:46:29 2010 -0400 drm/i915: Initialize LVDS and eDP outputs before anything else This makes them sort to the front in X, which makes them likely to be the primary outputs if you haven't specified a preference in your DE, which is likely to be what you want. Signed-off-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net> Sorting the connector list after the fact is much easier than trying to be clever with the init sequence. Acked-by: Dave Airlie <airlied@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
On Haswell/LPT we must disable the PCH transcoder before we disable the FDI, so don't check for disabled FDI there. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
This function is only for the previous gens. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
These workarounds are documented on the CRT mode set sequence. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
... instead of "pipe", which is wrong. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
... instead of PIPECONF_INTERLACE_MASK. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: applied the change by hand due to patch reorder.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
That function is made for IBX. Running it on LPT will trigger tons of "unclaimed register" errors. The only port remaining on LPT is PCH_ADPA. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Because we already set all the bits we can set. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: apply by hand due to dropped patch. Also, obey my OCD a bit and do a s/_TRANSACONF/TRANSCONF(TRANSCODER_A)/, makes it more consisten with other lpt pch code imnsho ...] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
... instead of using "pipe". As already explained in previous commits, since Haswell/LPT cpu_transcoder, pch_transcoder and pipe are not the same thing. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
These asserts are specific to IBX/CPT/PPT. Inside the assert_pch_pll function we even "return" in case we detect LPT, but I prefer to just not call it. In the future we might rename to something like ibx_assert_pch_pll. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Since now we have lpt_enable_pch_transcoder. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
For now the new functions are just copies. Differences will be added later. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
To ironlake_{en,dis}able_pch_transcoder since these functions will be different on Haswell/LPT and since the "transcoder" they {en,dis}able is on the PCH. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: again a small conflict because the fdi disable sequenc looks a bit different here.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
On Haswell/LPT, pipe, cpu_transcoder and pch_transcoder are different things with different values, unlinke the previous gens. So here we use the right thing at the right place. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: apply the patch by hand due to the reorder patch sequence. We also can't kill all uses of pipe where we should, since the fdi link train code isn't fixed up yet on this baselin.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
There is no LVDS, so don't poke the LVDS registers. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
This is just wrong. The lpt_program_iclkip should disable the PCH pixel clocks (and yes, we plan to rename it later). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Because this function is only for the older PCHs, not the newer ones. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Since this function will only run on Haswell/LPT and newer. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Since now we have lpt_pch_enable for them. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
For now it's just a fork of ironlake_pch_enable. The next commits will change this. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Because things changed on Haswell/LPT and the bits checked by intel_crt_get_hw_state have moved to other registers. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Those bits just don't exist on LPT. The CRT DAC, PCH transcoder and FDI RX are always connected to DDI E. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Makes more sense to group the entire mode_set stage into one function. Noticed while discussiing the rather confusing set of function names with Paulo Zanoni. Unfortunately I don't have an idea to make the function names lesss confusion. v2: Use for_each_encoder_on_crtc as suggested by Chris Wilson. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Refactor the code that stores the panning x/y position into the sarea. This also changes the code so that it won't mistakenly update sareaB_x/y for pipe >= C. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
The framebuffer pixel format is already checked by the common code. So there's no way an invalid format could reach the driver. So instead of falling back to a default format, call BUG(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Use drm_format_plane_cpp() to get 'pixel_size' in the sprite code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
The current code can't deal with framebuffers with an offset. Return an error when trying to create such a framebuffer until the rest of the code is fixed to handle them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Make sure the the framebuffer stride is smaller than 32k. That seems to be the limit on recent hardware. Not quite sure if <=Gen4 has smaller limits. Also when using a tiled memory make sure the object stride matches the framebuffer stride. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Fix support for all RGB/BGR pixel formats (except the 16:16:16:16 float format). Fix intel_init_framebuffer() to match hardware and driver limitations: * RGB332 is not supported at all * CI8 is supported * XRGB1555 & co. are supported on Gen3 and earlier * XRGB210101010 & co. are supported from Gen4 onwards * BGR formats are supported from Gen4 onwards * YUV formats are supported from Gen5 onwards (driver limitation) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
In order to handle differences in pte encoding between architectures it is desirable to have one helper function, pte_encode, do it all for us. As such, this commit moves the code around so we're in good shape to do that. Luckily the ppgtt pte and the ggtt pte look very similar. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
HSW will change the PTE encoding, and laying this out now will be helpful when we're ready to implement that. More importantly, GGTT and PPGTT PTE encoding is quite similar, so moving this out into a helper function will enable us to lance the AGP layer. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-