- May 01, 2013
-
-
Mika Kuoppala authored
Enabling PPGTT and also the need to track which context was guilty of gpu hang (arb robustness enabling) have put pressure for struct i915_hw_context to be more than just a placeholder for hw context state. In order to track object lifetime properly in a multi peer usage, add reference counting for i915_hw_context. v2: track i915_hw_context pointers instead of using ctx_ids (from Chris Wilson) v3 (Ben): Get rid of do_release() and handle refcounting more compactly. (recommended by Chis) v4: kref_* put inside static inlines (Daniel Vetter) remove code duplication on freeing context (Chris Wilson) v5: idr_remove and ctx->file_priv = NULL in destroy ioctl (Chris) This actually will cause a problem if one destroys a context and later refers to the idea of the context (multiple contexts may have the same id, but only 1 will exist in the idr). v6: Strip out the request related stuff. Reworded commit message. Got rid of do_destroy and introduced i915_gem_context_release_handle, suggested by Chris Wilson. v7: idr_remove can't be called inside idr_for_each (Chris Wilson) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v5) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> (v7) Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> [danvet: Squash sob lines, the patch ping-ponged between Ben and Mika a bit ...] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Reduce the size of the the src/dst viewport to keep the scalign ratios in check. v2: Below min size sprite handling squashed to previous patch Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Properly clip the source when the destination gets clipped by the pipe dimensions. Sadly the video sprite hardware is rather limited so it can't do proper sub-pixel postitioning. Resort to truncating the source coordinates to (macro)pixel boundary. The scaling checks are done using the strict drm_region functions. Which means that an error is returned when the min/max scaling ratios are exceeded. Also do some additional checking against various hardware limits. v2: Truncate src coords instead of rounding to avoid increasing src viewport size, and adapt to changes in drm_calc_{h,v}scale(). v3: Adapt to drm_region->drm_rect rename. Fix misaligned crtc_w for packed YUV formats when scaling isn't supported. v4: Use stricter scaling checks, use drm_rect_equals() v5: If sprite is below min size, make it invisible instead returning an error. Use WARN_ON() instead if BUG_ON(), and add one to sanity check the src viewport size. v6: Add comments to remind about src and dst coordinate types Reviewed-by: -
Ville Syrjälä authored
drm_rect_equals() tells whether two drm_rects are equal. Reviewed-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Add a debug function to print the rectangle in a human readable format. v2: Renamed drm_region to drm_rect, the function from drm_region_debug to drm_rect_debug_print(), and use %+d instead of +%d in the format. v3: Use %d format for width/height in the non fixed point case as well Reviewed-by: -
Ville Syrjälä authored
These functions calculate the scaling factor based on the source and destination rectangles. There are two version of the functions, the strict ones that will return an error if the min/max scaling factor is exceeded, and the relaxed versions that will adjust the src/dst rectangles in order to keep the scaling factor withing the limits. v2: Return error instead of adjusting regions, refactor common parts into one function, and split into strict and relaxed versions. v3: Renamed drm_region to drm_rect, add "_rect_" to the function names. v4: Fix "calculcate" typos Reviewed-by: -
Ville Syrjälä authored
struct drm_rect represents a simple rectangle. The utility functions are there to help driver writers. v2: Moved the region stuff into its own file, made the smaller funcs static inline, used 64bit maths in the scaled clipping function to avoid overflows (instead it will saturate to INT_MIN or INT_MAX). v3: Renamed drm_region to drm_rect, drm_region_clip to drm_rect_intersect, and drm_region_subsample to drm_rect_downscale. v4: Renamed some function parameters, improve kernel-doc comments a bit, and actually generate documentation for drm_rect.[ch]. v5: s/RETUTRNS/RETURNS/ Reviewed-by:Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
- Apr 30, 2013
-
-
Daniel Vetter authored
Writing hw registers from compute_config? Just say no! In this case not too horrible since we write a constant 0, and only debugging would put something else in there. But while checking that code I've noticed that this register disappeared on pch platforms, so fix that up, too. And adjust the comment a bit, it's outdated. Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Daniel Vetter authored
This was still required a bit (on the cargo-cult side though) when the state was stored in dev_priv, and when the enable/disable sequence was botched a bit (to avoid too many updates). But with pipeconfig we always get a clean slate, so this is pointless. Rip it out. Reviewed-by:
-
Daniel Vetter authored
pipe_config is the new dev_priv! More seriously, this is actually better since a pipe_config can be thrown away if the modeset compute config stage fails. Whereas any state stored in dev_prive needs to be painstakingly restored, since otherwise a dpms off/on will wreak massive havoc. Yes, that even applies to state only used in ->mode_set callbacks, since we need to call those even for dpms on when the Haswell power well cleared everything out. Reviewed-by:
-
Jani Nikula authored
Both intel_opregion_enable_asle() and intel_enable_asle() have shrunk considerably. Merge them together into a static function in i915_irq.c, and rename to better reflect the purpose and the related platforms. No functional changes. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Jani Nikula authored
Realize that intel_enable_asle() is never called on PCH-split platforms or on VLV. Rip out the GSE irq enable for PCH-split platforms, which also happens to be incorrect for IVB+. This should not cause any functional changes. Signed-off-by:
-
Jani Nikula authored
Stop calling intel_opregion_enable_asle() and consequently intel_enable_asle() on opregion init. It should not be necessary for these reasons: 1) On PCH split platforms, it only enables GSE interrupt, which is enabled in irq postinstall anyway. Moreover, the irq enable uses the wrong bit on IVB+. 2) On gen 2, it would enable a reserved pipestat bit. If there were gen 2 systems with opregion asle support, that is. And the gen 2 irq handler won't handle it anyway. 3) On gen 3-4, the irq postinstall will call intel_opregion_enable_asle() to enable the pipestat. In short, move the asle irq/pipestat enable responsibility to irq postinstall, which already happens to be in place. This should not cause any functional changes, but only do the one line change here for easier bisectability, just in case, and leave all the cleanups this allows to followup patches. Signed-off-by:
-
Jani Nikula authored
Only set ASLE driver readiness (ARDY) and technology enabled indicator (TCHE) once per opregion init. There should be no need to do that at irq postinstall time. Also clear driver readiness at fini. While at it, add defines for driver readiness. Signed-off-by:
-
Jani Nikula authored
Move near other defines, add TCHE in the name. No functional changes. Signed-off-by:
-
Daniel Vetter authored
This does duplicate the logic in intel_crtc_mode_get a bit, but the issue is that we also should handle interlace modes and other insanity correctly. Hence I've opted for a sligthly more elaborate route where we first read out the crtc timings for the adjusted mode, and then optionally (not sure if we really need it) compute the modeline from that. v2: Also read out the pipe source dimensions into the requested mode. v3: Rebase on top of the moved cpu_transcoder. v4: Simplify CHECK_FLAGS logic as suggested by Chris Wilson. Also properly #undef that macro again. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (v3) [danvet: Use the existing mask for interlaced bits, spotted by Mika.] Signed-off-by: -
Daniel Vetter authored
We want to use the fdi m/n values to easily compute the adjusted mode dotclock on pch ports. Hence make sure the values stored in the pipe config are always reliable. v2: Fixup FDI TU readout. v3: Rebase on top of moved cpu_transcoder. Reviewed-by:
-
Daniel Vetter authored
This code will get _really_ repetive, and we'll end up with tons more of this kind. So extract the common patterns. This should also help when we add a lazy pipe_config compare mode for fastboot. Reviewed-by:
-
Daniel Vetter authored
Spotted while changing related code. Reviewed-by:
-
Daniel Vetter authored
So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit into this, among them the default 1080p mode. The solution is to dither down the pipe a bit so that everything fits, which this patch implements. But ports compute their state under the assumption that the bpp they pick will be the one selected, e.g. the display port bw computations won't work otherwise. Now we could adjust our code to again up-dither to the computed DP link parameters, but that's pointless. So instead when the pipe needs to adjust parameters we need to retry the pipe_config computation at the encoder stage. Furthermore we need to inform encoders that they should not increase bandwidth requirements if possible. This is required for the hdmi code, which prefers the pipe to up-dither to either of the two possible hdmi bpc values. LVDS has a similar requirement, although that's probably only theoretical in nature: It's unlikely that we'll ever see an 8bpc high-res lvds panel (which is required to hit the 2 fdi lane limit). eDP is the only thing which could increase the pipe_bpp setting again, even when in the retry-loop. This could hit the WARN. Two reasons for not bothering: - On many eDP panels we'll get a black screen if the bpp settings don't match vbt. So failing the modeset is the right thing to do. But since that also means it's the only way to light up the panel, it should work. So we shouldn't be able to hit this WARN. - There are still opens around the eDP panel handling, and maybe we need additional tricks. Before that happens it's imo no use trying to be too clever. Worst case we just need to kill that WARN or maybe fail the compute config stage if the eDP connector can't get the bpp setting it wants. And since this can only happen with an fdi link in between and so for pch eDP panels it's rather unlikely to blow up, if ever. v2: Rebased on top of a bikeshed from Paulo. v3: Improve commit message around eDP handling with the stuff things with Imre. Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Daniel Vetter authored
We need to multiply the hdmi port dotclock by 1.5x since it's not really a dotclock, but the 10/8 encoding bitclock divided by 10. Also add correct limit checks for the dotclock and reject modes which don't fit. HDMI 1.4 would allow more, but our hw doesn't support that unfortunately :( Somehow I suspect 12bpc hdmi output never really worked - we really need an i-g-t testcase to check all the different pixel modes and outputs. v2: Fixup the adjusted port clock handling - we need to make sure that the fdi link code still gets the real pixelclock. v3: g4x/vlv don't support 12bpc hdmi output so drop the bogus comment. Acked-by:
-
Daniel Vetter authored
This allows us to use all 4 fdi lanes on fdi B when the cpu eDP is running on pipe C. Yay! v2: Encapsulate test into a little helper function, as suggested by Chris Wilson. Reviewed-by:
-
Daniel Vetter authored
This nicely allows us to drop some hacks which have only been used to work around modeset failures due to lack of fdi lanes. v2: Implement proper checking for Haswell platforms - the fdi link to the LPT PCH has only 2 lanes. Note that we already filter out impossible modes in intel_crt_mode_valid. Unfortunately LPT does not support 6bpc on the fdi rx, so we can't pull clever tricks to squeeze in a few more modes. v2: Rebased on top of Ben Widawsky's num_pipes reorg. v3: Rebase on top of Ville's pipe debug output ocd rampage. v4: Fixup rebase fail spotted by Ville. v5: Fixup rebase fail spotted by Imre Deak. I suck. Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
Again in preparation to move the configuration checks into the pipe_config computation stage of the modeset sequence. Reviewed-by:
-
Daniel Vetter authored
Now that it's split up, we can easily move it around and precompute the fdi lane configuration. Reviewed-by:
-
Daniel Vetter authored
And also move the computed m_n values into the pipe_config. This is a prep step to move the fdi state computation completely into the prepare phase of the modeset sequence. Which will allow us to handle fdi link bw constraints in a better way. Reviewed-by:
-
Daniel Vetter authored
v2: Introduce some nice #defines for the FDI lane width fields and put them to good use. Suggested by Ville. v3: Fixup the mask vs. shift copy&pasta fail Imre Deak spotted, and use the shift #define also in the mask. Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
We need this for two reasons: - Correct handling of shared fdi lanes on ivb with fastboot. - Handling fdi link bw limits when we only have two fdi lanes by dithering down a bit. Just search&replace in this patch, no functional change at all. Reviewed-by:
-
Daniel Vetter authored
Totally untested due to lack of screens supporting more than 8bpc. But now we should have closed all holes in our bpp handling, so this should be safe. The last missing piece was 10bpc support for g4x/vlv, since we directly use the pipe bpp to feed the display link (and anyway, only the cpt has any means to have a pipe bpp != the display link bpp). Reviewed-by:
-
Daniel Vetter authored
The current code is rather ... ugly. The only thing it managed to pull off is getting 6bpc on DP working on g4x. Then someone added another custom hack for 6bpc eDP on vlv. Fix up this entire mess by properly implementing the PIPECONF-based dither/bpc controls on g4x/vlv. Note that compared to pch based platforms g4x/vlv don't support 12bpc modes. g4x is already caught, extend the check for vlv. The other fixup is to restrict the lvds-specific dithering to early gen4 devices - g4x should use the pipeconf dither controls. Note that on gen2/3 the dither control is in the panel fitter even. v2: Don't enable dithering when the pipe is in 10 bpc mode. Quoting from Bspec "PIPEACONF - Pipe A Configuration Register, bit 4": "Programming note: Dithering should only be enabled for 8 bpc or 6 bpc." v3: Actually drop the old ugly dither code. v4: Explain in a short comment why g4x/vlv shouldn't dither for 30 bpp pipes (Jesse). v5: Also clear the dither type correctly as spotted by Ville. v6: As Ville pointed out we need to indeed set the dithering both in the pipeconf register (for DP outputs) and in the LVDS port register (for LVDS ouputs). Otherwise LVDS panel will not get properly dithered. The old patch got away with this since it forgot to clear the LVDS dither bit ... v7: Remove redundant BPC_MASK clearing, spotted by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
They can get at the adjusted mode through intel_crtc->config. Reviewed-by:
-
Daniel Vetter authored
We've had our fair share of woes already which showed that we can't rely on the bpc limits in the EDID for eDP panels without risking black screens. So now we limit the depth by what the BIOS recommends in the VBT: commit 2f4f649a Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Nov 12 14:33:44 2012 +0200 drm/i915: do not ignore eDP bpc settings from vbt But that's not enough, since at least the panel on my ASUS Zenbook Prime here is also unhappy if the bpc is too low. Hence just take the firmware value and dither to get what flimsy panels want. Like before we ensure that we don't change the bpp if the firmware doesn't provide a value, see commit 9a30a61f Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Nov 12 14:33:45 2012 +0200 drm/i915: do not default to 18 bpp for eDP if missing from VBT v2: Apparently there are some horribly broken eDP panels around which only work if the DP link is set up as if we want to driver a 24bpp mode, but still only work if the data is feed at 18bpp. See commit 57c21963 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Apr 4 17:19:37 2013 +0200 drm/i915: revert eDP bpp clamping code changes for the gory details. Adjust the patch accordingly and update all the relevant comments. v3: Give up on the cargo-culting v2 attempt and just enfore the edp bpp value if it's there. Broken panels be damned! Cc: Jani Nikula <jani.nikula@intel.com> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
-
Daniel Vetter authored
This hack is getting a bit messy, but this plugs the leak for now until we have the cpu_transcoder properly pipe_config'ed. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
- Apr 27, 2013
-
-
Chris Wilson authored
Instead of repeatedly bombarding the user with a request to reboot and increase the stolen size with every fb refresh, just inform them the first time only. v2: Rearrange code so the hint to increase the amount of memory stolen by the BIOS is only emitted if we fail to find sufficient stolen memory for FBC. Signed-off-by:
-
Jesse Barnes authored
Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
- Apr 26, 2013
-
-
Jesse Barnes authored
We prevent invalid ones from getting here in the first place, but it doesn't hurt to have an extra sanity check. Signed-off-by:
-
Jesse Barnes authored
And put the pfit stuff into substructs while we're at it. Signed-off-by:
-
Jesse Barnes authored
This gets the panel fitter working on eDP on VLV, and should also apply to eDP panels on G4x chipsets (if we ever detect and mark an all-in-one panel as eDP anyway). A few cleanups are still possible on top of this, for example the LVDS border control could be placed in the LVDS encoder structure and updated based on the result of the panel fitter calculation. Multi-pipe fitting isn't handled correctly either if we ever get a config that wants to try the panel fitter on more than one output at a time. v2: use pipe_config for storing pfit values (Daniel) add i9xx_pfit_enable function for use by 9xx and VLV (Daniel) v3: fixup conflicts and lvds_dither check Reviewed-by: -
Daniel Vetter authored
We only ever check whether it's strictly bigger than one, so all the is_sdvo/is_hdmi checks are redundant. Flatten the code a bit. Also, s/temp/dpll_md/ Reviewed-by:
-
Daniel Vetter authored
If we compute the pch pll state, we _have_ a pch encoder. Reviewed-by:
-
