- 04 Jun, 2013 8 commits
-
-
Daniel Vetter authored
... not the port clock. This allows us to kill the funny semantics around pixel_target_clock. Since the dpll code still needs the real port clock, add a new port_clock field to the pipe configuration. Handling the default case for that one is a bit tricky, since encoders might not consistently overwrite it when retrying the crtc/encoder bw arbitrage step in the compute config stage. Hence we need to always clear port_clock and update it again if the encoder hasn't put in something more specific. This can't be done in one step since the encoder might want to adjust the mode first. I was a bit on the fence whether I should subsume the pixel multiplier handling into the port_clock, too. But then I decided against this since it's on an abstract level still the dotclock of the adjusted mode, and only our hw makes it a bit special due to the separate pixel mulitplier setting (which requires that the dpll runs at the non-multiplied dotclock). So after this patch the adjusted_mode accurately describes the mode we feed into the port, after the panel fitter and pixel multiplier (or line doubling, if we ever bother with that) have done their job. Since the fdi link is between the pfit and the pixel multiplier steps we need to be careful with calculating the fdi link config. v2: Fix up ilk cpu pll handling. v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config to make it clearer that we transmit the adjusted_mode without the pixel multiplier taken into account. The old code multiplied the the available link bw with the pixel multiplier, which results in the same fdi configuration, but is much more confusing. v4: Rebase on top of Imre's is_cpu_edp removal. v5: Rebase on top of Paulo's haswell watermark fixes, which introduce a new place which looked at the pixel_clock and so needed conversion. v6: Split out prep patches as requested by Paulo Zanoni. Also rebase on top of the fdi dotclock handling fix in the fdi lanes/bw computation code. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v6) Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
This prepares a bit for the next big patch, where we switch the semantics of the different clocks in the pipe config around. Since I've broken cpu eDP PLL handling in the first version I've figured some refactoring is in order. Split out on request from Paulo Zanoni. Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Daniel Vetter authored
We currently mutliply the link_bw of the fdi link with the pixel multiplier, which is wrong: The FDI link doesn't suddenly grow more bandwidth. In reality the pixel mutliplication only happens in the PCH, before the pixels are fed into the port. But since we our code treats the uses the target clock after pixels are doubled (tripled, ...) already, we need to correct this. Semantically it's clearer to divide the target clock to get the fdi dotclock instead of multiplying the bw, so do that instead. Note that the target clock is already multiplied by the same factor, so the division will never loose accuracy for the M/N computation. The lane computation otoh used the wrong value, we also need to feed the fdi dotclock to that. Split out on a request from Paulo Zanoni. v2: Also fix the lane computation, it used the target clock to compute the bw requirements, not the fdi dotclock (i.e. adjusted with the pixel multiplier). Since sdvo only uses the pixel multiplier for low-res modes (with a dotclock below 100MHz) we wouldn't ever have rejected a bogus mode, but just used an inefficient fdi config. v3: Amend the commit message to explain better what the change for the fdi lane config computation is all about. Requested by Paulo. Reviewed-by:
-
Daniel Vetter authored
Since I stand by my rule that splitting functions should only do an exact copy, this is a follow-up patch. Suggested-by:
Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
-
Daniel Vetter authored
Now that the DP madness is cleared out, this is all only per-platform. So move it out from the intel clock limits structure. While at it drop the intel prefix on the static functions, call the vtable entry find_dpll (since it's for the display pll) and rip out the now unnecessary forward declarations. Note that the parameters of ->find_dpll are still unchanged, but they eventually need to be moved over to just take in a pipe configuration. But currently a lot of things are still missing from the pipe configuration (reflock, output-specific dpll limits and preferences, downclocked dotclock). So this will happen in a later step. Note that intel_g4x_limit has a peculiar case where it selects intel_limits_i9xx_sdvo as the limit. This is pretty bogus and also not used since the only output types left are DP and native TV-out which both use special pre-tuned dpll values. v2: Re-add comment for the find_pll callback (requested by Paulo) and elaborate on why the transformation is correct for g4x platforms (to clarify a review question from Paulo). Double up on that by adding a WARN as suggested by Paulo Zanoni on irc. v3: Initialize limits to NULL since gcc is now unhappy. v4: v2/3 will blow up with a NULL dereference in ->find_dpll for dp and TV-out ports, spotted by Paulo on irc. So just give up on this madness for now, and leave this to be fixed in a later patch. v5: Since the ever-so-slight change for g4x might result in some dpll parameter computation failing spuriously where before it didn't for ports with preset dpll settings (DP & TV-out) override this. For paranoia also do it in the ilk+ code. Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
-
Daniel Vetter authored
Pineview is just different. Also split out i9xx_clock from intel_clock and drop the now redundant struct device * parameter. Note that in this patch I kill an XXX comment about 100MHz clocks. I couldn't figure out what this is about, and we don't seem to have any bug reports about this either. I suspect that it's a remnant from when the i9xx and ilk+ modeset code was all in the same file since ilk+ does indeed have a 100MHz clock. So I've just killed it to stop the cargo-culting. Reviewed-by:
-
Daniel Vetter authored
Since this is run in the compute config stage we need to check the new_ pointers, i.e the stage output routing, not the current modeset layout. Also there was a little logic bug in properly skipping connectors: The old code did not skip any unused connectors and so clamped to whatever was left in there (usually 0 if that connector hasn't seen a EDID 1.4 screen ever since boot-up). This has been broken when moving the pipe bpp selection in commit 4e53c2e0 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw To avoid too much casting switch from drm_ to intel_ types. Also add a bit of debug output to help reconstructing what's going on. v2: Try to clarify this a bit: - s/pipe_config_set_bpp/compute_baseline_pipe_bpp/ to make it clearer at which stage this function is run. Also add a comment about what it does. - Extract the sink clamping into it's own function. v3: Actually make it compile. v4: Split out all the prep refactoring to make the bugfix stick out really badly. Also elaborate a bit in the commit message about the nature of the bugfix. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
As a prep work to fix it up: - Use intel_connector instead of drm_connector to avoid too much upcasting in the bugfix patch. - Extract the connector bpp clamping from the loop-over-connectors logic. - Bikeshed function names (to make it clearer that acompute_baseline_pipe_bpp runs in the compute stage of the modeset sequence) and add a comment to make it clearer what it does. No functional change in this patch. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
- 03 Jun, 2013 10 commits
-
-
Daniel Vetter authored
We only need to do them if the pipe is actually running and if the framebuffers have changed. Removes two "wait for vblank timed out" messages when doing a suspend/resume cycle on my i855gm. v2: s/to_intel_ctrc(crtc)/intel_crtc/ spotted by Chris. Reviewed-by:
-
Ville Syrjälä authored
People don't like typedefs these days. Eliminate their use from intel_fb.c. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
Use container_of() instead of a cast to get struct intel_fbdev from struct drm_fb_helper. Also populate the fb_info->par correctly with the drm_fb_helper pointer instead of the intel_fbdev pointer. There's no actual functional change since the drm_fb_helper happens to be the first member inside intel_fbdev. Signed-off-by:
-
Mika Kuoppala authored
Rework of per ring hangcheck made this obsolete. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Mika Kuoppala authored
Keep track of ring seqno progress and if there are no progress detected, declare hang. Use actual head (acthd) to distinguish between ring stuck and batchbuffer looping situation. Stuck ring will be kicked to trigger progress. This commit adds a hard limit for batchbuffer completion time. If batchbuffer completion time is more than 4.5 seconds, the gpu will be declared hung. Review comment from Ben which nicely clarifies the semantic change: "Maybe I'm just stating the functional changes of the patch, but in case they were unintended here is what I see as potential issues: 1. "If ring B is waiting on ring A via semaphore, and ring A is making progress, albeit slowly - the hangcheck will fire. The check will determine that A is moving, however ring B will appear hung because the ACTHD doesn't move. I honestly can't say if that's actually a realistic problem to hit it probably implies the timeout value is too low. 2. "There's also another corner case on the kick. If the seqno = 2 (though not stuck), and on the 3rd hangcheck, the ring is stuck, and we try to kick it... we don't actually try to find out if the kick helped" v2: use atchd to detect stuck ring from loop (Ben Widawsky) v3: Use acthd to check when ring needs kicking. Declare hang on third time in order to give time for kick_ring to take effect. v4: Update commit msg Signed-off-by:
-
Ben Widawsky authored
Since it will be used for the global bound/unbound list with full PPGTT, this helps clarify things for upcoming code rework. Recommended-by:
-
Ben Widawsky authored
If we properly keep track of the pages_pin_count, then when we later add multiple address spaces, the put_pages doesn't need any special checks to be able to perform it's job. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ben Widawsky authored
The way the stolen handling works is we take a pin on the backing pages, but we never actually get a reference to the bo. On freeing objects allocated with stolen memory, the final unref will end up freeing the object with pinned pages count left. To enable an assertion to catch bugs in this code path, this patch cleans up that remaining pin. Signed-off-by:
-
Ben Widawsky authored
This makes it easier to catch leaks. Signed-off-by:
-
Ben Widawsky authored
It's not terribly interesting to know that a parameter doesn't exist, and it can get in the way of interesting messages, especially with the staggered VECS merging as we've done. Signed-off-by:
-
- 31 May, 2013 22 commits
-
-
Paulo Zanoni authored
It just prints whether it's supported/enabled/disabled. Feature requested by the power management team. v2: Checkpatch started complaining about seq_printf with 1 argument. Requested-by:
Kristen Accardi <kristen.c.accardi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Paulo Zanoni authored
IPS is still enabled by default. Feature requested by the power management team. This should also help testing the feature on some early pre-production hardware where there were relationship problems between IPS and PSR. v2: Rebase on top of the newest IPS implementation. v3: Check i915_enable_ips at compute_config, not supports_ips, so the kernel parameter will be ignored at haswell_get_pipe_config. Requested-by: -
Paulo Zanoni authored
Intermediate Pixel Storage is a feature that should reduce the number of times the display engine wakes up memory to read pixels, so it should allow deeper PC states. IPS can only be enabled on ULT pipe A with 8:8:8 pipe pixel formats. With eDP 1920x1080 and correct watermarks but without FBC this moves my PC7 residency from 2.5% to around 38%. v2: - It's tied to pipe A, not port A - Add pipe_config support (Chris) - Add some assertions (Chris) - Rebase against latest dinq v3: - Don't ever set ips_enabled to false (Daniel) - Only check for ips_enabled at hsw_disable_ips (Daniel) v4: - Add hsw_compute_ips_config (Daniel) - Use the new dump_pipe_config (Daniel) Signed-off-by: -
Daniel Vetter authored
Now that we track the cpu transcoder we need accurately in the pipe config we can finally fix up the transcoder check. With the current code eDP on port D will be broken since we'd errornously cut the power. For reference see commit 2124b72e Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Mar 22 14:07:23 2013 -0300 drm/i915: don't disable the power well yet v2: - Kill the now outdated comment (Paulo) - Add the missing crtc->base.enabled check and consolidate it (Paulo) - Smash all checks together, looks neater that way. v3: Kill the unused encoder variable. Cc: Takashi Iwai <tiwai@suse.de> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Xiang, Haihao authored
This will let userland only try to use the new ring when the appropriate kernel is present Signed-off-by:
Xiang, Haihao <haihao.xiang@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Xiang, Haihao authored
A user can run batchbuffer via VEBOX ring. Signed-off-by:
-
Xiang, Haihao authored
v2: Removed rebase relic VECS ring from i915_gem_request_info (Damien) v3: s/hsw/hws in debugfs which I introduced in v2 (Jon) Signed-off-by:
-
Ben Widawsky authored
Similar to a patch originally written by: v2: Reversed the meanings of masked and enabled (Haihao) Made non-destructive writes in case enable/disabler rps runs first (Haihao) v3: Reword error message (Damien) Modify postinstall to do the right thing based on previous fixup. (Ben) CC: Xiang, Haihao <haihao.xiang@intel.com> Reviewed-by:
-
Ben Widawsky authored
v2: Use the correct lock to protect PM interrupt regs, this was accidentally lost from earlier (Haihao) Fix return types (Ben) Reviewed-by:
-
Ben Widawsky authored
The motivation here is we're going to add some new interrupt definitions and handling outside of the GT interrupts which is all we've managed so far (with some RPS exceptions). By consolidating the names in the future we can make thing a bit cleaner as we don't need to define register names twice, and we can leverage pretty decent overlap in HW registers since ILK. To explain briefly what is in the comments: there are two sets of interrupt masking/enabling registers. At least so far, the definitions of the two sets overlap. The old code setup distinct names for interrupts in each set, ie. one for global, and one for ring. This made things confusing when using the wrong defines in the wrong places. rebase: Modified VLV bits v2: Renamed GT_RENDER_MASTER to GT_RENDER_CS_MASTER (Damien) Reviewed-by:
-
Ben Widawsky authored
It's overkill on older gens, but it's useful for newer gens. Reviewed-by:
-
Ben Widawsky authored
PM interrupts have an expanded role on HSW. It helps route the EBOX interrupts. This patch is necessary to make the existing code which touches the mask, and enable registers more friendly to other code paths that also will need these registers. To be more explicit: At preinstall all interrupts are masked and disabled. This implies that preinstall should always happen before any enabling/disabling of RPS or other interrupts. The PMIMR is touched by the workqueue, so enable/disable touch IER and IIR. Similarly, the code currently expects IMR has no use outside of the RPS related interrupts so they unconditionally set 0, or ~0. We could use IER in the workqueue, and IMR elsewhere, but since the workqueue use-case is more transient the existing usage makes sense. Disable RPS events: IER := IER & ~GEN6_PM_RPS_EVENTS // Disable RPS related interrupts IIR := GEN6_PM_RPS_EVENTS // Disable any outstanding interrupts Enable RPS events: IER := IER | GEN6_PM_RPS_EVENTS // Enable the RPS related interrupts IIR := GEN6_PM_RPS_EVENTS // Make sure there were no leftover events (really shouldn't happen) v2: Shouldn't destroy PMIIR or PMIMR VEBOX interrupt state in enable/disable rps functions (Haihao) v3: Bug found by Chris where we were clearing the wrong bits at rps disable. expanded commit message v4: v3 was based off the wrong branch v5: Added the setting of PMIMR because of previous patch update CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: -
Ben Widawsky authored
At the moment, these values are wiped out anyway by the rps enable/disable. That will be changed in the next patch though. v2: Add post install setup to address issue found by Damien in the next patch. replaced WARN_ON(dev_priv->rps.pm_iir != 0); with rps.pm_iir = 0; With the v2 of this patch and the deferred pm enabling (which changed since the original patches) we're now able to get PM interrupts before we've brought up enabled rps. At this point in boot, we don't want to do anything about it, so we simply ignore it. Since writing the original assertion, the code has changed quite a bit, and I believe removing this assertion is perfectly safe. Signed-off-by:
-
Ben Widawsky authored
Just duplicates ironlake_irq_preinstall for now. v2: Add new PCH_NOP check (Damien) Add SDEIMR comment (Damien) Signed-off-by:
-
Ben Widawsky authored
HSW has some special requirements for the VEBOX. Splitting out the interrupt handler will make the code a bit nicer and less error prone when we begin to handle those. The slight functional change in this patch (queueing work while holding the spinlock) is intentional as it makes a subsequent patch a bit nicer. The change should also only effect HSW platforms. Reviewed-by:
-
Paulo Zanoni authored
Now we compute the results for both 1/2 and 5/6 partitioning and then use hsw_find_best_result to choose which one to use. With this patch, Haswell watermarks support should be in good shape. The only improvement we're missing is the case where the primary plane is disabled: we always assume it's enabled, so we take it into consideration when calculating the watermarks. v2: - Check the latency when finding the best result Signed-off-by:
-
Paulo Zanoni authored
We were previously only setting the WM_PIPE registers, now we are setting the LP watermark registers. This should allow deeper PC states, resulting in power savings. We're only using 1/2 data buffer partitioning for now. v2: Merge both hsw_compute_pri_wm_* functions (Ville) v3: - Simplify hsw_compute_wm_results (Ville) - Rebase due to changes on the previous patch v4: Unconfuse wm_lp/level (Ville) Signed-off-by: -
Paulo Zanoni authored
We were previously calling sandybridge_update_wm on HSW, but the SNB function didn't really match the HSW specification, so we were just writing the wrong values. With this patch, the haswell_update_wm function will set the correct values for the WM_PIPE registers, but it will still keep all the LP watermarks disabled. The patch may look a little bit over-complicated for now, but it's because much of the infrastructure for setting the LP watermarks is already in place, so we won't have too much code churn on the patch that sets the LP watermarks. v2: - Fix pixel_rate on panel fitter case (Ville) - Try to not overflow (Ville) - Remove useless variable (Ville) - Fix p->pri_horiz_pixels (Paulo) v3: - Fix rounding errors on hsw_wm_method2 (Ville) v4: - Fix memcmp bug (Paulo) Signed-off-by: -
Daniel Vetter authored
This was accidentally broken in the south error interrupt handling work: commit 8664281b Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Apr 12 17:57:57 2013 -0300 drm/i915: report Gen5+ CPU and PCH FIFO underruns Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
-
Ben Widawsky authored
v2: Add set_seqno which didn't exist before rebase (Haihao) Signed-off-by:
-
Xiang, Haihao authored
The flag will be useful to help share code between IVB, and HSW as the programming is similar in many places with this as one of the major differences. Signed-off-by:
-
Ben Widawsky authored
Historically we considered the render ring to have special flush semantics and everything else to fall under a more general umbrella. Probably by coincidence more than anything we decided to make the bsd ring have the default *other* flush. As the new vebox ring exposes, the bsd ring is actually the weird one. Doing this allows us to call gen6_ring_flush for the vebox because calling blt_ring_flush would be weird... This patch should have no functional change. Reviewed-by:
-
