- 17 Sep, 2013 10 commits
-
-
Ville Syrjälä authored
Double wide mode is only available on pipe A, except on GDG where pipe B is also double wide capable. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Pipe horizontal source size must be even when either LVDS dual channel mode, DVO ganged mode, or pipe double wide mode is used. We must round it down since we can never increase the user specified viewport size. The actual error from an odd pipe source width looks like a diagonal shift, like you might get from a bad stride. v2: s/ganaged/ganged/ Signed-off-by:
-
Ville Syrjälä authored
We don't want to try to push the hardware beyond it's capabilities, so check the pixel clock against the display core clock limit. Do it for pre-gen4 for now since that's where we alread have the double wide pixel clock limit check. Let's assume that when double wide mode is enabled the max pixel clock limit is also doubled. FIXME: panel fitter downscaling probably affects the limit on non-pch platforms too, so we'd need another version of ilk_pipe_pixel_rate() to figure that out. FIXME: should check the limits on all platforms. Also sprites affect the max allowed pixel rate on some platforms, so we need to eventually tie all the planes and pipes into one check in the future. But we need plane state pre-compute before that can happen. Signed-off-by:
-
Ville Syrjälä authored
Read the double wide pipe information from hardware in i9xx_get_pipe_config(), and check it in intel_pipe_config_compare() For gen4+ double_wide is always false so the comparison can be done on all platforms. Signed-off-by:
-
Ville Syrjälä authored
Determine the need for double wide mode already in compute_config stage as we need that information to figure out if horizontal coordinates need to be adjusted. Signed-off-by:
-
Daniel Vetter authored
Simply inline the 100MHz default we're using. Having gunk around that has leftover LVDS support on a platform that just doesn't have this isn't of any use. Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Ville Syrjälä authored
First of all we should not be looking at fb->{width,height} as those do not tell us what the actual pipe size is. Second of all we need to use >= for the comparison. So fix the comparison, and make use of the new pipe_src_{w,h} to determine the real pipe source dimensions. Reviewed-by:Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
When the cursor x coordinate is exactly -cursor_width, the cursor is invisible. And obviously the same holds for the y coordinate and cursor_height. Reviewed-by:
-
Ville Syrjälä authored
Try to clarify the purpose of requested_mode. Signed-off-by:
-
Daniel Vetter authored
Especially intel_gmch_panel_fitting was shifting way too much over the right edge and also was way too long. So extract two helpers, one for gen4+ and one for gen2/3. Now the entire thing is again almost readable ... Spurred by checkpatch freaking out about a Ville's pipeconfig rework in intel_panel.c Otherwise just two lines that needed appropriate breaking. Not functional change in this patch. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 16 Sep, 2013 17 commits
-
-
Ville Syrjälä authored
Rather that mess about with hdisplay/vdisplay from requested_mode, add explicit pipe src size information to pipe config. Now requested_mode is only really relevant for dvo/sdvo output timings. For everything else either adjusted_mode or pipe src size should be used. In many places where we end up using pipe source size, we should actually use the primary plane size, but we don't currently store that information explicitly. As long as we treat primaries as full screen only, we can get away with this. Eventually when we move primaries over to drm_plane, we need to fix it all up. v2: Add a comment to explain what pipe_src_{w,h} are Add a note about primary planes to commit message Signed-off-by: -
Ville Syrjälä authored
adjusted_mode contains our real timings, not requested_mode. Use the correct thing in DSI PLL code. Also constify adjusted_mode since we don't change it. Signed-off-by:
-
Ville Syrjälä authored
Rather than dig up the pipe source size from crtc->mode, use intel_crtc->config.requested_mode. Signed-off-by:
-
Ville Syrjälä authored
Move intel_crtc_active() to intel_display.c and make it available elsewhere as well. intel_edp_psr_match_conditions() already has one open coded copy, so replace that one with a call to intel_crtc_active(). v2: Copy paste a big comment from danvet's mail explaining when we can ditch the extra checks Signed-off-by: -
Ville Syrjälä authored
intel_edp_psr_match_conditions() currently looks at crtc->mode when it really needs to look at adjusted_mode. Fix it. Signed-off-by:
-
Ville Syrjälä authored
The clock in crtc->mode doesn't necessarily mean anything. Let's look at the clock in adjusted_mode instead. Signed-off-by:
-
Ville Syrjälä authored
Currently most of the watermark code looks at crtc->mode which is the user requested mode. The only piece of information there that is relevant is hdisplay, the rest must come from adjusted_mode. Convert all of the code to use requested_mode and adjusted_mode from pipe config appropriately. Signed-off-by:
-
Ville Syrjälä authored
Check the mode flags from the adjusted_mode, not user requested mode. The hdisplay/vdisplay check actually checkes the primary plane size, so those still need to come from the user requested mode. Extract both modes from pipe config instead of the drm_crtc. Signed-off-by:
-
Ville Syrjälä authored
The pixel clock should come from adjusted_mode not requested_mode. In this case the two should be the same as we don't currently overwrite the clock in the case of HDMI. But let's make the code safe against such things happening in the future. Signed-off-by:
-
Ville Syrjälä authored
lpt_program_iclkip() wants to know the pixel clock. It should get that information from adjusted_mode, not crtc->mode. Signed-off-by:
-
Ville Syrjälä authored
i9xx_set_pipeconf() attempts to get the current pixel clock from requested_mode. requested_mode.clock may be totally bogus, so the clock should come from adjusted_mode. v2: Dropped the intel_compute_config() hunk due to killing of the INTEL_FDI_FREQ check Signed-off-by: -
Ville Syrjälä authored
Check and dump for port_clock. v2: Also dump port_clock Reviewed-by:
-
Ville Syrjälä authored
Add a new pipe config check macro PIPE_CONF_CHECK_CLOCK_FUZZY() to make it trivial and error proof to compare clocks in a fuzzy manner. v2: Drop extra curly braces Reviewed-by:
-
Ville Syrjälä authored
Now that adjusted_mode.clock no longer contains the pixel_multiplier, we can kill the get_clock() callback and instead do the clock readout in get_pipe_config(). Also i9xx_crtc_clock_get() can now extract the frequency of the PCH DPLL, so use it to populate port_clock accurately for PCH encoders. For DP in port A the encoder is still responsible for filling in port_clock. The FDI adjusted_mode.clock extraction is kept in place for some extra sanity checking, but we no longer need to pretend it's also the port_clock. In the encoder get_config() functions fill out adjusted_mode.clock based on port_clock and other details such as the DP M/N values, HDMI 12bpc and SDVO pixel_multiplier. For PCH encoders we will then do an extra sanity check to make sure the dotclock we derived from the FDI configuratiuon matches the one we derive from port_clock. DVO doesn't exist on PCH platforms, so it doesn't need to anything but assign adjusted_mode.clock=port_clock. And DDI is HSW only, so none of the changes apply there. v2: Use hdmi_reg color format to detect 12bpc HDMI case v3: Set adjusted_mode.clock for LVDS too v4: Rename ironlake_crtc_clock_get to ironlake_pch_clock_get, eliminate the useless link_freq variable. Signed-off-by: -
Ville Syrjälä authored
Add the 120MHz refernce clock case for PCH DPLLs. Also determine the reference clock frequency more accurately by checking for the PLLB_REF_INPUT_SPREADSPECTRUMIN refclk input mode. The gen2 code already checked it, but it stil assumed a fixed 66MHz refclk. Instead we need to consult the VBT for the real value. v2: Fix refclk for SSC panel case Signed-off-by:
-
Ville Syrjälä authored
We already extract the DPLL state to pipe_config, so let's make use of it in i9xx_crtc_clock_get() and avoid the register reads. This will also make the function closer to being useable with PCH DPLL since the registers for those live in a different address. Also kill the useless adjusted_mode.clock zeroing. It's already zero at this point. v2: Read out DPLL state in intel_crtc_mode_get() Signed-off-by:
-
Ville Syrjälä authored
Extract the code to calculate the dotclock from the link clock and M/N values into a new function from ironlake_crtc_clock_get(). The new function can be used to calculate the dotclock for both FDI and DP cases. Also simplify the code a bit along the way. v2: Don't forget about non-pch encoders in ironlake_crtc_clock_get() Signed-off-by:
-
- 13 Sep, 2013 12 commits
-
-
Paulo Zanoni authored
We don't seem to be using the pointer after it's unmapped, so this patch doesn't fix any bug I can reproduce. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Jani Nikula authored
The cursor is supposed to be disabled during crtc mode set (disabled by ctrc disable). Assert this is the case. v2: move cursor disabled assert next to plane asserts (Ville) Suggested-by:
-
Ben Widawsky authored
The buf pointer used during l3_write is just char *, therefore it does not require the silly any addition of offset. v2: Also fix i915_l3_read with a suggested logic from Ville Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
-
Ben Widawsky authored
We always read a register for l3 parity reads, and we don't really want to ever let userspace trick us into giving back less than the dword. Writes are okay because we assume everything will be 0 filled, and as such, if a user really wants to write less than a dword, let them. Signed-off-by:
-
Ben Widawsky authored
Sadly, this isn't the first time we've done this: http://lists.freedesktop.org/archives/intel-gfx/2013-June/029065.htmlSigned-off-by:
-
Ville Syrjälä authored
We want to do fuzzy clock checks for other things besides adjusted_mode.clock, so just pass two two clocks to compare to intel_fuzzy_clock_check(). Reviewed-by:
-
Ville Syrjälä authored
Add functions to read out the CPU and PCH transcoder M/N values, and use them to fill out the pipe config dp_m_n information. And while at it populate has_dp_encoder too. Also refactor ironlake_get_fdi_m_n_config() to simply call the new intel_cpu_transcoder_get_m_n() function. v2: Remember the DDI Signed-off-by:
-
Ville Syrjälä authored
On CTG+ read out the pipe bpp setting from hardware and fill it into pipe config. Also check it appropriately. v2: Don't do the pipe_bpp extraction inside the PCH only code block on ILK+. Avoid the PIPECONF read as we already have read it for the PIPECONF_EANBLE check. Signed-off-by: -
Ville Syrjälä authored
It would be easier if adjusted_mode.clock would be the pipe pixel clock, and it actually is, except for the cases where pixel_multiplier > 1. So let's change intel_sdvo to use port_clock as the multiplied clock, and then we can leave adjusted_mode.clock as pipe pixel clock. v2: Improve port_clock documentation Rebased on top of SDVO pixel_multiplier fixes Signed-off-by: -
Ville Syrjälä authored
We feed the non-multiplied clock to intel_link_compute_m_n(), so the opposite operation should use the same order of operations. So we just multiply by pixel_multiplier in the end now. Reviewed-by:
-
Paulo Zanoni authored
Because this PCI config register doesn't exist on Gen5+. Signed-off-by:
-
Paulo Zanoni authored
Both callers had code to sanitize the uncore and restore the GTT mappings just before calling __i915_drm_thaw, so Chris suggested I should unify the code. Signed-off-by:
-
- 12 Sep, 2013 1 commit
-
-
Ben Widawsky authored
When reserving objects during execbuf, it is possible to come across an object which will not fit given the current fragmentation of the address space. We do not have any defragment in drm_mm, so the strategy is to instead evict everything, and reallocate objects. With the upcoming addition of multiple VMs, there is no point to evict everything since doing so is overkill for the specific case mentioned above. Recommended-by:
-
