- 16 Sep, 2013 16 commits
-
-
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ä <ville.syrjala@linux.intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
Jani Nikula <jani.nikula@intel.com> Signed-off-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:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-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 3 commits
-
-
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:
-
Ben Widawsky authored
As we'll see in the next patch, being able to evict for just 1 VM is handy. Signed-off-by:
-
Ben Widawsky authored
lifted from Daniel: pread/pwrite isn't about the object's domain at all, but purely about synchronizing for outstanding rendering. Replacing the call to set_to_gtt_domain with a wait_rendering would imo improve code readability. Furthermore we could pimp pread to only block for outstanding writes and not for reads. Since you're not the first one to trip over this: Can I volunteer you for a follow-up patch to fix this? v2: Switch the pwrite patch to use \!read_only. This was a typo in the original code. (Chris, Daniel) Recommended-by:
-
- 10 Sep, 2013 9 commits
-
-
Jesse Barnes authored
Fixed with commit 10603caa Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Aug 26 19:51:06 2013 -0300 drm/i915: Apply the force-detect VGA w/a to Valleyview Signed-off-by:
Jesse Barnes <jbarnes@virtuosugeek.org> Signed-off-by:
-
Ville Syrjälä authored
intel_ddi_enable_transcoder_func() picked the sync flags from crtc->mode instead of the pipe config adjusted_mode. Fix the problem and hopefully rid my HSW machine of the remaining pipe config warnings. Signed-off-by:
-
Chris Wilson authored
The purpose of the function is to find out whether the object is still bound in any address space. This can be easily checked by looking at the vma currently associated with the object, rather than asking if any of the global address spaces have an active vma on the object. Signed-off-by:
-
Chris Wilson authored
Ignoring the legacy DRI1 code, and a couple of special cases (to be discussed later), all access to the ring is mediated through requests. The first write to a ring will grab a seqno and mark the ring as having an outstanding_lazy_request. Either through explicitly adding a request after an execbuffer or through an implicit wait (either by the CPU or by a semaphore), that sequence of writes will be terminated with a request. So we can ellide all the intervening writes to the tail register and send the entire command stream to the GPU at once. This will reduce the number of *serialising* writes to the tail register by a factor or 3-5 times (depending upon architecture and number of workarounds, context switches, etc involved). This becomes even more noticeable when the register write is overloaded with a number of debugging tools. The astute reader will wonder if it is then possible to overflow the ring with a single command. It is not. When we start a command sequence to the ring, we check for available space and issue a wait in case we have not. The ring wait will in this case be forced to flush the outstanding register write and then poll the ACTHD for sufficient space to continue. The exception to the rule where everything is inside a request are a few initialisation cases where we may want to write GPU commands via the CS before userspace wakes up and page flips. Signed-off-by:
-
Ville Syrjälä authored
Pull the expected max WM level determinations out to a separate function. Will have another user soon. Signed-off-by:
-
Ville Syrjälä authored
Unify the code a bit to use ilk_compute_wm_level for all watermark levels. Signed-off-by:
-
Ville Syrjälä authored
hsw_pipe_wm_parameters and hsw_wm_maximums typically are read only. Make them const. Signed-off-by:
-
Ville Syrjälä authored
Make the call to intel_update_watermarks() just once or twice during modeset. Ideally it should happen independently when each plane gets enabled/disabled, but for now it seems better to keep it in central place. We can improve things when we get all the planes sorted out in a better way. When enabling set up the watermarks just before the pipe is enabled. And when disabling we need to wait until we've marked the crtc as inactive, as otherwise intel_crtc_active() would still think the pipe is enabled and the computed watermarks would reflect that. v2: Pimp up the commit message a bit Reviewed-by:
-
Ville Syrjälä authored
Passing the appropriate crtc to intel_update_watermarks() should help in avoiding needless work in the future. v2: Avoid clash with internal 'crtc' variable in some wm functions Reviewed-by:
-
