- 11 Nov, 2012 40 commits
-
-
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:
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:
-
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:
-
Paulo Zanoni authored
This function is only for the previous gens. Signed-off-by:
-
Paulo Zanoni authored
These workarounds are documented on the CRT mode set sequence. Signed-off-by:
-
Paulo Zanoni authored
... instead of "pipe", which is wrong. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Paulo Zanoni authored
... instead of PIPECONF_INTERLACE_MASK. Signed-off-by:
-
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 authored
Because we already set all the bits we can set. Signed-off-by:
-
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 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 authored
Signed-off-by:
-
Paulo Zanoni authored
Since now we have lpt_enable_pch_transcoder. Signed-off-by:
-
Paulo Zanoni authored
For now the new functions are just copies. Differences will be added later. Signed-off-by:
-
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 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 authored
There is no LVDS, so don't poke the LVDS registers. Signed-off-by:
-
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 authored
Because this function is only for the older PCHs, not the newer ones. Signed-off-by:
-
Paulo Zanoni authored
Since this function will only run on Haswell/LPT and newer. Signed-off-by:
-
Paulo Zanoni authored
Since now we have lpt_pch_enable for them. Signed-off-by:
-
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 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 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:
-
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:
-
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:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
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ä authored
Use drm_format_plane_cpp() to get 'pixel_size' in the sprite code. Signed-off-by:
-
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ä 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ä 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:
-
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:
-
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 authored
This will make the calculations of size easier to read instead of just assuming uint32_t everywhere. Signed-off-by:
-
Ben Widawsky authored
Some subsequent commits will need to know what generation we're running on to do different pte encoding for the ppgtt. Since it's not much hassle or overhead to store it in the ppgtt structure, do that. Signed-off-by:
-
Ben Widawsky authored
The mid-level cache or as it's more commonly referred to now as L3, is not setup this way on HSW. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
Mika Kuoppala authored
Make intel_render_ring_init_dri and intel_init_ring_buffer symmetrical with regards of workaround introduced by: commit 27c1cbd0 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Apr 9 13:59:46 2012 +0100 drm/i915/ringbuffer: Exclude last 2 cachlines of ring on 845g Signed-off-by:
-
Paulo Zanoni authored
Now intel_ddi_init is just like intel_hdmi_init and intel_dp_init: it inits the encoder and then calls the proper init_connector functions. Notice that for non-eDP ports we call both HDMI and DP connector init, so we have 2 connectors attached to each DDI encoder. After this change, intel_hdmi_init and intel_dp_init are only called by Ivy Bridge and earlier, while hardware containing DDI outputs should call intel_ddi_init. Also added/removed quite a few "static" keywords due to the fact that some function pointers were moved from intel_dp.c and intel_hdmi.c to intel_ddi.c. DP finally works on Haswell now! \o/ Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Paulo Zanoni authored
We need this since now on DDI we will have 2 connectors on each encoder. Signed-off-by:
-
