- 22 Jun, 2015 16 commits
-
-
Maarten Lankhorst authored
No need to repeatedly call update_watermarks, or update_fbc. Down to a single call to update_watermarks in .crtc_enable Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
Now that all planes are added during a modeset we can use the calculated changes before disabling a plane, and then either commit or force disable a plane before disabling the crtc. The code is shared with atomic_begin/flush, except watermark updating and vblank evasion are not used. This is needed for proper atomic suspend/resume support. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90868Signed-off-by:
-
Maarten Lankhorst authored
Read out the initial state, and add a quirk to force add all planes to crtc_state->plane_mask during initial commit. This will disable all planes during the initial modeset. The initial plane quirk is temporary, and will go away when hardware readout is fully atomic, and the watermark updates in intel_sprite.c are removed. Changes since v1: - Unset state->visible on !primary planes. - Do not rely on the plane->crtc pointer in intel_atomic_plane, instead assume planes are invisible until modeset. Signed-off-by:
-
Maarten Lankhorst authored
All the checks in intel_modeset_checks are only useful when a modeset occurs, because there is nothing to update otherwise. Same for power/cdclk changes, if there is no modeset they are noops. Unfortunately intel_modeset_pipe_config still gets called without modeset, because atomic hw readout isn't done yet. Signed-off-by:
-
Maarten Lankhorst authored
To allow them to be used in intel_set_mode. Signed-off-by:
-
Maarten Lankhorst authored
This is probably intended to be be done during vblank evasion. Signed-off-by:
-
Maarten Lankhorst authored
The idea was good, but planes can have a fb even though they're disabled. This makes the force argument useless and always true, because only the commit function updates state. Signed-off-by:
-
Maarten Lankhorst authored
By passing crtc_state to the check_plane functions a lot of duplicated code can be removed. There are still some transitional helper calls, they will be removed later. Changes since v1: - Revert state->visible changes. - Use plane->state->crtc instead of plane->crtc. - Use drm_atomic_get_existing_crtc_state. Signed-off-by:
-
Maarten Lankhorst authored
No point in hiding behind big ifs. This will be true most of the time. Signed-off-by:
-
Maarten Lankhorst authored
This makes it easier to verify that no changes are done when calling this from crtc instead. Changes since v1: - Make intel_wm_need_update static and always check it. Signed-off-by:
-
Maarten Lankhorst authored
commit 2c310b9d2859863826c3688c88218d607d5dd19a Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Mon May 18 12:28:52 2015 +0200 drm/i915: Split skl_update_scaler, v4. It's easier to read separate functions for crtc and plane scaler state. Changes since v1: - Update documentation. Changes since v2: - Get rid of parameters to skl_update_scaler only used for traces. This avoids needing to document the other parameters. Changes since v3: - Rename scaler_idx to scaler_user. Signed-off-by:
-
Maarten Lankhorst authored
It saves another loop over all crtc's in the state, and computing clock is more of a per crtc thing. Signed-off-by:
-
Maarten Lankhorst authored
The scaler setup may add planes, but since they're unchanged we only have to wait for primary flips. Also set planes_changed to indicate at least 1 plane is modified. Changes since v1: - Instead of removing planes, do minimal validation needed. Signed-off-by:
-
Maarten Lankhorst authored
Move the check for encoder cloning here. Changes since v1: - Remove was/is crtc_disabled. (mattrope) - Rename function to intel_crtc_atomic_check. (mattrope) Signed-off-by:
-
Maarten Lankhorst authored
Get rid of a whole lot of ternary operators and assign the index in scaler_id, instead of the id. They're the same thing. Signed-off-by:
-
Maarten Lankhorst authored
Grabbing crtc state from atomic state is a lot more involved, and make sure connectors are added before calling this function. Move check_digital_port_conflicts to intel_modeset_checks, it's only useful to check it on a modeset. Signed-off-by:
-
- 19 Jun, 2015 1 commit
-
-
Daniel Vetter authored
Signed-off-by:
-
- 18 Jun, 2015 2 commits
-
-
Mika Kuoppala authored
In order for gen8+ hardware to guarantee that no context switch takes place during engine reset and that current context is properly saved, the driver needs to notify and query hw before commencing with reset. There are gpu hangs where the engine gets so stuck that it never will report to be ready for reset. We could proceed with reset anyway, but with some hangs with skl, the forced gpu reset will result in a system hang. By inspecting the unreadiness for reset seems to correlate with the probable system hang. We will only proceed with reset if all engines report that they are ready for reset. If root cause for system hang is found and can be worked around with another means, we can reconsider if we can reinstate full reset for unreadiness case. v2: -EIO, Recovery, gen8 (Chris, Tomas, Daniel) v3: updated commit msg v4: timeout_ms, simpler error path (Chris) References: https://bugs.freedesktop.org/show_bug.cgi?id=89959 References: https://bugs.freedesktop.org/show_bug.cgi?id=90854 Testcase: igt/gem_concurrent_blit/prw-blt-overwrite-source-read-rcs-forked Testcase: igt/gem_concurrent_blit/gtt-blt-overwrite-source-read-rcs-forked Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tomas Elf <tomas.elf@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Vandana Kannan authored
Changes for BXT - added a IS_BROXTON check to use the macro related to PPS registers for BXT. BXT does not have PP_DIV register. Making changes to handle this. Second set of PPS registers have been defined but will be used when VBT provides a selection between the 2 sets of registers. v2: [Jani] Added 2nd set of PPS registers and the macro Jani's review comments - remove reference in i915_suspend.c - Use BXT PP macro Squashing all PPS related patches into one. v3: Jani's review comments addressed - Use pp_ctl instead of pp - ironlake_get_pp_control() is not required for BXT - correct the use of && in the print statement - drop the shift in the print statement v4: Jani's comments - modify ironlake_get_pp_control() - dont set unlock key for bxt v5: Sonika's comments addressed - check alignment - move pp_ctrl_reg write (after ironlake_get_pp_control()) to !IS_BROXTON case. - check before subtracting 1 for t11_t12 Signed-off-by:
Vandana Kannan <vandana.kannan@intel.com> Signed-off-by:
A.Sunil Kamath <sunil.kamath@intel.com> Reviewed-by:
Sonika Jindal <sonika.jindal@intel.com> Signed-off-by:
-
- 17 Jun, 2015 1 commit
-
-
Matt Roper authored
We need to call drm_atomic_set_mode_for_crtc() rather than copying the mode in manually. As of commit commit 99cf4a29 Author: Daniel Stone <daniels@collabora.com> Date: Mon May 25 19:11:51 2015 +0100 drm/atomic: Add current-mode blob to CRTC state the helper now also takes care of setting up the mode property blob for us; if we don't use the helper and never setup the mode blob, this will also trigger a failure in drm_atomic_crtc_check() when we have the DRIVER_ATOMIC flag set (i.e., when using the nuclear pageflip support via i915.nuclear_pageflip kernel command line parameter). Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
- 15 Jun, 2015 20 commits
-
-
Daniel Vetter authored
Leftover from the big purge commit a5611654 Author: John Harrison <John.C.Harrison@Intel.com> Date: Thu Mar 5 14:03:03 2015 +0000 drm/i915: Remove ironlake rc6 support Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Rob Clark <robdclark@gmail.com> Reported-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Mika Kahola authored
Limit CHV maximum cdclk to 320MHz. v2: Rebase to the latest v3: Clean up of if-else tree Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Paulo Zanoni authored
This commit is just to make the intentions explicit: on HSW+ these bits are MBZ, but since we only support plane A and the macro evaluates to zero when plane A is the parameter, we're not fixing any bug. v2: - Remove useless extra blank like (Chris). - Init dpfc_ctl in another place (Chris). Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Paulo Zanoni authored
This commit has two main advantages: simplify intel_fbc_update() and deduplicate the strings. v2: - Rebase due to changes on P1. - set_no_fbc_reason() can now return void (Chris). Signed-off-by:
-
Paulo Zanoni authored
Because we're currently using FBC_UNSUPPORTED_MODE for two different cases. This commit will also allow us to write the next one without hiding information from the user. Signed-off-by:
-
Paulo Zanoni authored
We already had a few bugs in the past where FBC was compressing nothing when it was enabled, which makes the feature quite useless. Add this information to debugfs so the test suites can check for regressions in this piece of the code. Our igt/tests/kms_frontbuffer_tracking already has support for this message. v2: - Remove pointless VLV check (Ville). Signed-off-by:
-
Ville Syrjälä authored
The docs don't support the 64k linear scanout alignment we impose on gen2/3. And it really makes no sense since we have no DSPSURF register, so the only thing that the hardware will see is the linear offset which will be just pixel aligned anyway. There is one case where 64k comes into the picture, and that's FBC. The start of the line length buffer corresponds to a 64k aligned address of the uncompressed framebuffer. So if the uncompressed fb is not 64k aligned, the first actually used entry in the line length buffer will not be byte 0. There are 32 extra entries in the line length buffer to account for this extra alignment so we shouldn't have to worry about it when mapping the uncompressed fb to the GTT. Signed-off-by:
-
Ville Syrjälä authored
VLV/CHV have problems with 4k aligned linear scanout buffers. The VLV docs got updated at some point to say that we need to align them to 128k, just like we do on gen4. So far I've seen the problem manifest when the stride is an odd multiple of 512 bytes, and the surface address meets the following pattern '(addr & 0xf000) == 0x1000' (also == 0x2000 is problematic on VLV). The result is a starcase effect (so some pages get dropped maybe?), with a few pages here and there clearly getting scannout out at the wrong position. I've not actually been able to reproduce this problem on gen4, so it's not clear of the issue is any way related to the 128k restrictions supposedly inherited from gen4. But let's hope the 128k alignment is sufficient to hide it all. Signed-off-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Reviewed-by:
Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Currently intel_gen4_compute_page_offset() simply picks the closest page boundary below the linear offset. That however may not be suitably aligned to satisfy any hardware specific restrictions. So let's make sure the page boundary we choose is properly aligned. Also to play it a bit safer lets split the remaining linear offset into x and y values instead of just x. This should make no difference for most platforms since we convert the x and y offsets back into a linear offset before feeding them to the hardware. HSW+ are different however and use x and y offsets even with linear buffers, so they might have trouble if either the x or y get too big. Signed-off-by:
-
Chandra Konduru authored
Delete the duplicate #defines introduced by: commit 6b457d31 Author: A.Sunil Kamath <sunil.kamath@intel.com> Date: Thu Apr 16 14:22:09 2015 +0530 drm/i915/skl: Implement enable/disable for Display C5 state. Signed-off-by:
Chandra Konduru <chandra.konduru@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Ramalingam C authored
Corrected the documentation on the intel_edp_drrs_flush and intel_edp_drrs_invalidate. And accordingly edp_drrs_flush function is modified to restart the idleness detection after upclocking. v2: Update kerneldoc Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (v1) Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
-
Daniel Vetter authored
The i915 atomic conversion is a real beast and it's not getting easier wrangling in a separate branch. I'm might be regretting this, but right after vacation nothing can burst my little bubble here! Signed-off-by: -
Chris Wilson authored
In igt, we want to test handling of GPU hangs, both for recovery purposes and for reporting. However, we don't want to inject a genuine GPU hang onto a machine that cannot recover and so be permenantly wedged. Rather than embed heuristics into igt, have the kernel report exactly when it expects the GPU reset to work. This can also be usefully extended in future to indicate different levels of fine-grained resets. Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_runtime_pm_status’: drivers/gpu/drm/i915/i915_debugfs.c:2528:34: error: ‘struct dev_pm_info’ has no member named ‘usage_count’ atomic_read(&dev->dev->power.usage_count)); Regression from commit a6aaec8b Author: Damien Lespiau <damien.lespiau@intel.com> Date: Thu Jun 4 18:23:58 2015 +0100 drm/i915: Add runtime PM's usage_count in i915_runtime_pm_status Signed-off-by: -
Damien Lespiau authored
I noticed one of those and it turned out we have a few lingering around. Signed-off-by:
-
Damien Lespiau authored
It's handy to have debug message for the "big" events and this one qualifies IMHO. Also helpful to see what's happening while we're loading the firwmare and how much time it takes. Signed-off-by:
-
Damien Lespiau authored
In Linux, macros are usually well done and protect their arguments properly, even avoiding multiple evaluations of the parameters. Extra () are really not needed. Cc: Suketu Shah <suketu.j.shah@intel.com> Signed-off-by:
-
Francisco Jerez authored
Only bit 27 of SCRATCH1 and bit 6 of ROW_CHICKEN3 are allowed to be set because of security-sensitive bits we don't want userspace to mess with. On HSW hardware the whitelisted bits control whether atomic read-modify-write operations are performed on L3 or on GTI, and when set to L3 (which can be 10x-30x better performing than on GTI, depending on the application) require great care to avoid a system hang, so we currently program them to be handled on GTI by default. Beignet can immediately start taking advantage of this change to enable L3 atomics. Mesa should eventually switch to L3 atomics too, but a number of non-trivial changes are still required so it will continue using GTI atomics for now. Signed-off-by:
Francisco Jerez <currojerez@riseup.net> Reviewed-by:
Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by:
-
Francisco Jerez authored
In some cases it might be unnecessary or dangerous to give userspace the right to write arbitrary values to some register, even though it might be desirable to give it control of some of its bits. This patch extends the register whitelist entries to contain a mask/value pair in addition to the register offset. For registers with non-zero mask, any LRM writes and LRI writes where the bits of the immediate given by the mask don't match the specified value will be rejected. This will be used in my next patch to grant userspace partial write access to some sensitive registers. Signed-off-by:
-
Francisco Jerez authored
Until now the software command checker assumed that commands could read or write at most a single register per packet. This is not necessarily the case, MI_LOAD_REGISTER_IMM expects a variable-length list of offset/value pairs and writes them in sequence. The previous code would only check whether the first entry was valid, effectively allowing userspace to write unrestricted registers of the MMIO space by sending a multi-register write with a legal first register, with potential security implications on Gen6 and 7 hardware. Fix it by extending the drm_i915_cmd_descriptor table to represent multi-register access and making validate_cmd() iterate for all register offsets present in the command packet. Signed-off-by:
-
