- 14 Sep, 2015 18 commits
-
-
Sagar Arun Kamble authored
Shared frontbuffer bits are causing warnings when same FB is displayed in another plane without clearing the bits from previous plane. v2: Removing coversion of fb bits to 64 bit as it is not needed for now. (Daniel) Change-Id: Ic2df80747f314b82afd22f8326297c57d1e652c6 Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
Kumar, Mahesh <mahesh1.kumar@intel.com> [danvet: Drop INTEL_FRONTBUFFER_SPRITE_MASK since unused.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Robert Beckett authored
WaDisableSTUnitPowerOptimization:skl,bxt Signed-off-by:
Robert Beckett <robert.beckett@intel.com> Signed-off-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
This stolen reserved stuff was introduced on g4x, so no need to waste stolen on older platforms. Unfortunately configdb is no more so I can't look up the right way to detect this stuff. I do have one hint as to where the register might be on ctg, but I don't have a ctg to test it, and on the elk I have here it doesn't contain sensible looking data. For ilk grits suggegsts it might be in the same place as on snb (the original PCI reg, not the mirror) but I can't be entirely sure about it The register shows a round zero on my ilk. So when there's no really good data for any of these platforms leave the current "assume 1MiB" approach in place. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Masanari Iida authored
This patch fix following warnings while "make xmldocs". .//drivers/gpu/drm/i915/intel_lrc.c:780: warning: No description found for parameter 'req' .//drivers/gpu/drm/i915/intel_lrc.c:780: warning: Excess function parameter 'request' description in 'intel_logical_ring_begin' .//drivers/gpu/drm/i915/intel_lrc.c:780: warning: Excess function parameter 'ctx' description in 'intel_logical_ring_begin' Signed-off-by:
Masanari Iida <standby24x7@gmail.com> Signed-off-by:
-
Nick Hoath authored
Extend init/init_hw split to context init. - Move context initialisation in to i915_gem_init_hw - Move one off initialisation for render ring to i915_gem_validate_context - Move default context initialisation to logical_ring_init Rename intel_lr_context_deferred_create to intel_lr_context_deferred_alloc, to reflect reduced functionality & alloc/init split. This patch is intended to split out the allocation of resources & initialisation to allow easier reuse of code for resume/gpu reset. v2: Removed function ptr wrapping of do_switch_context (Daniel Vetter) Left ->init_context int intel_lr_context_deferred_alloc (Daniel Vetter) Remove unnecessary init flag & ring type test. (Daniel Vetter) Improve commit message (Daniel Vetter) v3: On init/reinit, set the hw next sequence number to the sw next sequence number. This is set to 1 at driver load time. This prevents the seqno being reset on reinit (Chris Wilson) v4: Set seqno back to ~0 - 0x1000 at start-of-day, and increment by 0x100 on reset. This makes it obvious which bbs are which after a reset. (David Gordon & John Harrison) Rebase. v5: Rebase. Fixed rebase breakage. Put context pinning in separate function. Removed code churn. (Thomas Daniel) v6: Cleanup up issues introduced in v2 & v5 (Thomas Daniel) Issue: VIZ-4798 Signed-off-by:Nick Hoath <nicholas.hoath@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: John Harrison <john.c.harrison@intel.com> Cc: David Gordon <david.s.gordon@intel.com> Cc: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by:
Thomas Daniel <thomas.daniel@intel.com> Signed-off-by:
-
Jesse Barnes authored
This avoids some bad register writes and generally feels more correct than unconditionally trying to redirect interrupts and such. References: https://bugs.freedesktop.org/show_bug.cgi?id=91777Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Jesse Barnes authored
Use WARN_ONCE in a bunch of places and demote a message that would continually spam us. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Acked-by:
-
Nick Hoath authored
Signed-off-by:
-
Arun Siluvery authored
Signed-off-by:
-
Arun Siluvery authored
Signed-off-by:
-
Sonika Jindal authored
Using intel_encoder's hpd_pin to check the live status because of BXT A0/A1 WA for HPD pins and hpd_pin contains the updated pin for the corresponding port. Signed-off-by:
Sonika Jindal <sonika.jindal@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Michel Thierry authored
When WaEnableForceRestoreInCtxtDescForVCS is required, it is only safe to send new contexts if the last reported event is "active to idle". Otherwise the same context can fully preempt itself because lite-restore is disabled. Testcase: igt/gem_concurrent_blit Reported-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
-
Michel Thierry authored
Also check for correct revision id in each Gen9 platform (SKL until B0 and BXT until A0). Cc: Nick Hoath <nicholas.hoath@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
This is done as a separate commit, to make it easier to revert when things break. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Maarten Lankhorst authored
Instead of doing a hack during primary plane commit the state is updated during atomic evasion. It handles differences in pipe size and the panel fitter. This is continuing on top of Daniel's work to make faster modesets atomic, and not yet enabled by default. Signed-off-by:
-
Maarten Lankhorst authored
The initial state is read out correctly and the state is atomic, so it's safe to preserve the fb without any hacks if it's suitable. Signed-off-by:
-
Maarten Lankhorst authored
It should really use the atomic state. Signed-off-by:
-
Maarten Lankhorst authored
This might not have been set during boot, and when we preserve the initial mode this can result in a black screen. Cc: Daniel Stone <daniels@collabora.com> Signed-off-by:
-
- 11 Sep, 2015 1 commit
-
-
Daniel Vetter authored
Signed-off-by:
-
- 10 Sep, 2015 9 commits
-
-
Tvrtko Ursulin authored
Comment disagrees with the code which has changed a lot since it was documented. Note that the logic to remove -EIO handling was dropped in commit 1488fc08 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 24 15:47:31 2012 +0100 drm/i915: Remove the deferred-free list Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
In async mode crtc->config can be updated after the locks are released, resulting in the wrong state being duplicated. Note that this also removes a spurious assignment of crtc_state->crtc introduced in commit f0c60574 Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Tue Apr 21 17:12:58 2015 +0300 drm/i915: Call drm helpers when duplicating crtc and plane states Signed-off-by:
-
Maarten Lankhorst authored
With the conversion to atomic this cannot happen any more. Signed-off-by:
-
Maarten Lankhorst authored
Unfortunately fbc still depends on legacy primary state, so it can't be killed off completely yet. Signed-off-by:
-
Maarten Lankhorst authored
Signed-off-by:
-
Maarten Lankhorst authored
This function was still using the legacy state, convert it to atomic. While we're at it, fix the FIXME too and disable the primary plane. v2 (Daniel): - Add FIXME explaining that update_primary_planes should soon get removed anyway. - Don't call ->disable_plane since we can't disable the primary plane with a CS flip (noticed by Ville). Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (v1) Signed-off-by: -
Maarten Lankhorst authored
Legacy state might not be updated any more. Signed-off-by:
-
Maarten Lankhorst authored
Signed-off-by:
-
Shashank Sharma authored
This patch adds the intel_connector initialized to intel_hdmi display, during the init phase, just like the other encoders do. This attachment is very useful when we need to extract the connector pointer during the hotplug handler function Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
-
- 07 Sep, 2015 4 commits
-
-
Jani Nikula authored
Fall back to VBT based backlight modulation frequency if it's not set. Do not hard code. This could be a problem if there is no VBT. Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Tested-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Reviewed-by:
-
Jani Nikula authored
Normally we determine the backlight PWM modulation frequency (which we also use as backlight max value) from the backlight registers at module load time, expecting the registers have been initialized by the BIOS. If this is not the case, we fail. The VBT contains the backlight modulation frequency in Hz. Add platform specific functions to convert the frequency in Hz to backlight PWM modulation frequency, and use them to initialize the backlight when the registers are not initialized by the BIOS. v2: Fix SPT and VLV. Thanks to Clint for the VLV code. Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
Jani Nikula authored
Currently the difference between backlight control on HSW vs. BDW/SKL is that on HSW we modify the duty cycle on the CPU register, and have the hardware pass the changes on to the PCH registers. We still drive the PCH PWM on both. While HSW and BDW use the same LPT PCH, BDW does not pass these messages on to the PCH. Therefore on BDW we need to enable the PCH override bit, and program the PCH directly. (On SPT PCH, this mode is the default.) We could as well do this on HSW too, and in fact I've been told this is what a certain other operating system does. So use PCH backlight override on HSW too. This simplifies some follow-up code, but it does have the danger of breaking backlight on HSW machines. It should work, but mysterious are the ways of backlight. While at it, name the related backlight hooks according to the PCH rather than the CPU for clarity. Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
Nick Hoath authored
Add stepping check for A0 workarounds, and remove the associated FIXME tags. Split out unrelated WAs for later condition checking. v2: Fixed format (PeterL) v3: Corrected stepping check for WaDisableSDEUnitClockGating - Ignoring comment, following hardware spec instead. (ChrisH) Added description for TILECTL setting (JonB) Cc: Peter Lawthers <peter.lawthers@intel.com> Cc: Chris Harris <chris.harris@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by:Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
- 04 Sep, 2015 8 commits
-
-
Chris Wilson authored
Fixes regression from commit f1afe24f Author: Arun Siluvery <arun.siluvery@linux.intel.com> Date: Tue Aug 4 16:22:20 2015 +0100 drm/i915: Change SRM, LRM instructions to use correct length which forgot to account for the length bias when declaring the fixed length. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91844Reported-by:
Andreas Reis <andreas.reis@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
The pfit state is stored as register values, so dump them as hex instead of decimal to make some sense of the error messages. Signed-off-by:
-
Imre Deak authored
These registers exist only before GEN5, so currently we may access undefined registers on VLV/CHV and BXT. Apply the workaround only pre GEN5. Since the workaround is relevant only when LVDS is present, for clarity apply it only if this is the case. This triggered an unclaimed register access warning on BXT. v2: (Ville) - move the workaround to the LVDS init code - print a debug note about the workaround Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
This register exists only pre GEN5, but atm we also access it on VLV/BXT/CHV. Prevent accessing it on these latter platforms. Signed-off-by:
-
Chris Wilson authored
A small, very small, step to sharing the duplicate code between execlists and legacy submission engines, starting with the ringbuffer allocation code. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Jani Nikula authored
Reviewed-by:
-
Jani Nikula authored
TPS3 is mandatory for downstream devices that support HBR2, and Intel platforms that support HBR2 also support TPS3. Whenever TPS3 is supported by both the source and sink, it should be used. In other words, whenever the source and sink are capable of 5.4 Gbps link, we should anyway go for TPS3, regardless of the link rate being selected. Log an error if the sink has advertized HBR2 capability without TPS3 capability. Reviewed-by:
-
Jani Nikula authored
There is no need to have a separate flag for tps3 as the information is only used at one location. Move the logic there to make it easier to follow. Reviewed-by:
-
