- 06 Jun, 2013 14 commits
-
-
Paulo Zanoni authored
CTG/ILK/SNB/IVB support 4kx2k surfaces. HSW supports 4kx4k, but without proper front buffer invalidation on the last 2k lines, so don't enable FBC on these cases for now. v2: Use gen >= 5, not gen > 4 (Daniel). Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Incomplete since ilk+ support needs proper pch dpll tracking first. SDVO get_config parts based on a patch from Jesse Barnes, but fixed up to actually work. v2: Make sure that we call encoder->get_config _after_ we get_pipe_config to be consistent in both setup_hw_state and the modeset state checker. Otherwise the clever trick with handling the pixel mutliplier on i915G/GM where the encoder overrides the default value of 1 from the crtc get_pipe_config function doesn't work. Spotted by Imre Deak. v3: Actually cross-check the pixel mutliplier (but not on pch split platforms for now). Now actually also tested on a i915G with a sdvo encoder plugged in. Cc: Imre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Adding more context from Ville's reply to Rodrigo's question why we need this: "The spec says that on some hardware you need to PLL running before you can poke at the palette registers. I didn't actually try to anger the hardware so I'm not really sure what would happen otherwise, but IIRC Jesse said something about a hard system hang..." And generally documenting such ordering constraints with asserts is Just Good. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Spruce up the commit message a lot.] Signed-off-by:
-
Ville Syrjälä authored
Make assert_sprites_disabled() operational on all platforms where we currently have sprite support enabled. Signed-off-by:
-
Ville Syrjälä authored
Ever since gen4 primary planes were fixed to pipes. And for gen2-3, don't check plane B if it doesn't exist. Signed-off-by:
-
Ville Syrjälä authored
Disable/restore sprite planes around mode-set just like we do for the primary and cursor planes. Now that we have working sprite clipping, this actually works quite decently. Previosuly we didn't even bother to disable sprites when changing mode, which could lead to a corrupted sprite appearing on the screen after a modeset (at least on my IVB). Not sure if all hardware generations would be so forgiving when enabled sprites end up outside the pipe dimensons. v2: Disable rather than enable sprites in ironlake_crtc_disable() Signed-off-by:
-
Ville Syrjälä authored
VLV doesn't have the old video overlay. Signed-off-by:
-
Ville Syrjälä authored
First disable FBC, then IPS, then disable all planes, and finally disable the pipe. v2: Mention IPS in the commit message Signed-off-by:
-
Ville Syrjälä authored
Again follow the same sequence for all generations, because doing otherwise just doesn't make sense. Signed-off-by:
-
Ville Syrjälä authored
Follow the same sequence when enabling the cursor plane during modeset. No point in doing this stuff in different order on different generations. This should also avoid a needless wait for vblank for the g4x cursor workaround when the cursor gets enabled anyway. Acked-by:
Egbert Eich <eich@suse.com> Signed-off-by:
-
Ville Syrjälä authored
Loading the palette after the planes are enabled can risk showing incorrect colors. ILK+ already load the palette before even the pipe is enabled. Just follow the same order for gen2-4 and VLV. According to BSpec the requirements for palette access are display core clock and display PLL running. In certain platforms just the core clock may be enough. But we definitely should have both running when this gets called during the modeset. v2: Amend the commit message with some display PLL/core clock info Signed-off-by:
-
Ville Syrjälä authored
We use port I/O for VGA register access, so adding display_mmio_offset is just wrong. This reverts commit 56a12a50. Signed-off-by:
-
Paulo Zanoni authored
So we can remove some duplicate code. All the PCHs are very similar and right now the code is the same. I plan to add more code, so we would have more duplicated code. Signed-off-by:
-
Chris Wilson authored
By stashing a pointer of who opened the device and keeping a list of open fd, we can then walk each client and inspect how many objects they have open. For example, i915_gem_objects: 1102 objects, 613646336 bytes 663 [662] objects, 468783104 [468750336] bytes in gtt 37 [37] active objects, 46874624 [46874624] bytes 626 [625] inactive objects, 421908480 [421875712] bytes 282 unbound objects, 6512640 bytes 85 purgeable objects, 6787072 bytes 28 pinned mappable objects, 3686400 bytes 40 fault mappable objects, 27783168 bytes 2145386496 [536870912] gtt total Xorg: 43 objects, 32243712 bytes (10223616 active, 16683008 inactive, 4096 unbound) gnome-shell: 30 objects, 28381184 bytes (0 active, 28336128 inactive, 0 unbound) xonotic-linux64: 1032 objects, 569933824 bytes (46874624 active, 383545344 inactive, 6508544 unbound) v2: Use existing drm->filelist as pointed out by Ben. v3: Not even stashing the task_struct is required as Ben pointed out drm_file->pid. Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
- 05 Jun, 2013 5 commits
-
-
Daniel Vetter authored
This way we can simplify the code quite a bit. Also add a WARN in the sdvo code to complain about a bogus value and kill the readout code in intel_ddi.c that Jesse sneaked in. HW state readout for the pixel multiplier will work a bit differently in the end. v2: Rebase on top of the fdi pixel mutliplier handling fix. Reviewed-by:
-
Jani Nikula authored
Two exactly same error messages on different error paths makes debugging difficult. Clarify the messages and distinguish them from each other. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Daniel Vetter authored
Only lvds/tv did actually check for cloning or not, but many more places should. Notices because my ivb tried to enable both cpu edp and vga on the first crtc - the resulting confusion between has_pch_encoder, has_dp_encoder but not actually being a pch dp encoder resulting in hilarity (hitting a BUG). We _really_ need an igt to random-walk our modeset space more exhaustively. The bug seems to have been exposed due to a race in the hw load detection support for VGA: Right after a hotplug VGA was still detected as connected, but obviously reading the EDID wasn't possible any more. Hence why restarting X a bit later fixed things. Due to the 1024x756 fallback resolution suddenly more outputs had the same resolution. On top of that SNA was confused with the possible_clones mask, trying to clone outputs which cannot be cloned. That bug is now fixed with commit fc1e0702b25e647cb423851fb7228989fec28bd6 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed May 29 11:25:28 2013 +0100 sna: fixup up possible_clones kms->X impedance mismatch v2: Kill intel_encoder_check_is_cloned, spotted by Paulo. v3: Drop the now unused pipe param. v4: Kill the stray printk Chris spotted. v5: Elaborate on how the bug in userspace happened and why it was racy to reproduce. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Reviewed-by: -
Ville Syrjälä authored
Fix the DSPCLK_GATE_D access for VLV. The code incorrectly tried to poke at the ILK+ version of the register which is at the wrong offset. Signed-off-by:
-
Ville Syrjälä authored
The LP watermark registers don't exist on VLV, so don't touch them. Signed-off-by:
-
- 04 Jun, 2013 10 commits
-
-
Daniel Vetter authored
Panel fitters on ivb/hsw are not created equal since not all of them support the new high-quality upscaling mode. To offset this the hw allows us to freely assign the pfits to pipes. Since our code currently doesn't support this we might fall over when taking over firmware state. So check for this case and WARN about it. We can then improve the code once we've hit this in the wild. Or once we decide to support the improved upscale modes, though that requires global arbitrage of modeset resources across crtcs. v2: Check for IS_GEN7 instead of IS_IVB || IS_HSW as suggested by Paulo in his review comment. Suggested-by:
Mika Kuoppala <mika.kuoppala@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
Daniel Vetter authored
We can get at this easily through intel_crtc->config now. v2: Drop more stuff gcc spotted. v3: Drop even more stuff gcc spotted. v4: Yet more ... Reviewed-by:
-
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 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:
-
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:
-
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ä 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 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 1 commit
-
-
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:
-
