- 02 Sep, 2019 1 commit
-
-
Ville Syrjälä authored
My attempt at allowing MST to use the higher color depths has regressed some configurations. Apparently people have setups where all MST streams will fit into the DP link with 8bpc but won't fit with higher color depths. What we really should be doing is reducing the bpc for all the streams on the same link until they start to fit. But that requires a bit more work, so in the meantime let's revert back closer to the old behavior and limit MST to at most 8bpc. Cc: stable@vger.kernel.org Cc: Lyude Paul <lyude@redhat.com> Tested-by: Geoffrey Bennett <gmux22@gmail.com> Fixes: f1477219 ("drm/i915: Remove the 8bpc shackles from DP MST") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111505Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190828102059.2512-1-ville.syrjala@linux.intel.comReviewed-by: Lyude Paul <lyude@redhat.com>
-
- 31 Aug, 2019 1 commit
-
-
Chris Wilson authored
We use the context->pin_mutex to serialise updates to the OA config and the registers values written into each new context. Document this relationship and assert we do hold the context->pin_mutex as used by gen8_configure_all_contexts() to serialise updates to the OA config itself. v2: Add a white-lie for when we call intel_gt_resume() from init. v3: Lie while we have the context pinned inside atomic reset. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20190830181929.18663-1-chris@chris-wilson.co.uk
-
- 30 Aug, 2019 19 commits
-
-
Matt Roper authored
The bspec was recently updated with these new cdclk values for ICL, EHL, and TGL. Bspec: 20598 Bspec: 49201 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190826225540.11987-3-matthew.d.roper@intel.com
-
Matt Roper authored
The bspec has just recently been updated with new cdclk values that require the use of a /2 CD2X divider rather than a /1 divider. Once we add the divider selection logic to ICL+ cdclk programming, we have pretty much the same logic we were already using on CNL, so it's simpler to drop icl_set_cdclk() completely and reuse cnl_set_cdclk() on gen11+ platforms as well. v2: - Using ICL_CDCLK_CD2X_PIPE_NONE + BXT_CDCLK_CD2X_PIPE(pipe) for TGL is correct, but looks really confusing. Add some TGL_ macros that alias these to avoid confusion. (Ville) - Use DIV_ROUND_CLOSEST rather than / when applying the divider. (Ville) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190830004828.19359-1-matthew.d.roper@intel.com
-
Maarten Lankhorst authored
When we moved the code to disable crtc's to a separate patch, we forgot to ensure that for_each_oldnew_intel_crtc_in_state_reverse() was moved as well. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 66d9cec8 ("drm/i915/display: Move the commit_tail() disable sequence to separate function") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190830101644.8740-1-maarten.lankhorst@linux.intel.com
-
Chris Wilson authored
Since i915_address_space is now RCU protected, we can do the vm_idr lookup without taking the vm_idr_mutex, just with the rcu_read_lock() instead. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190830180325.7755-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
This is no longer used anywhere and so can be removed. However, tracking the dirty status on the ppgtt doesn't work very well if the ppgtt is shared, so perhaps for the best that it is no longer required. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190830180000.24608-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
With the upcoming change in timing (dramatically reducing the latency between manipulating the ppGTT and execution), no amount of tweaking could save Cherryview, it would always fail to invalidate its TLB. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190830180000.24608-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
With the upcoming change in timing (dramatically reducing the latency between manipulating the ppGTT and execution), no amount of tweaking could save Baytrail, it would always fail to invalidate its TLB. Ville was right, Baytrail is beyond hope. v2: Rollback on all gen7; same timing instability on TLB invalidation. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190830180000.24608-1-chris@chris-wilson.co.uk
-
Lucas De Marchi authored
Use a single function to setup the SDE irq and make MCC, ICP and TGP use it, just like was done for the irq handler. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829211526.30525-4-jose.souza@intel.comSigned-off-by: José Roberto de Souza <jose.souza@intel.com>
-
Lucas De Marchi authored
Ice Lake, Tiger Lake and Elkhart Lake all have different port configurations and all of them can be parameterized the same way to form the SDE hotplug bitmask. Avoid making them a special case an just use the parameterized macros. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829211526.30525-3-jose.souza@intel.comSigned-off-by: José Roberto de Souza <jose.souza@intel.com>
-
Lucas De Marchi authored
The differences are only on the pins, trigger and long_detect function. The MCC handling is already partially merged, so merge TGP as well. Remove the pins argument from icp_irq_handler() so we have all the differences between the 3 set in a common if ladder. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829211526.30525-2-jose.souza@intel.comSigned-off-by: José Roberto de Souza <jose.souza@intel.com>
-
Lucas De Marchi authored
South, follow the north. Instead of defining separate macros for each port, make them take port as parameter as done for TC ports and for north engine. This will allow us to easily extend this as needed. tgp_ddi_port_hotplug_long_detect() is also removed as after the EHL introduction the tgp variant is an exact copy of icp. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829211526.30525-1-jose.souza@intel.comSigned-off-by: José Roberto de Souza <jose.souza@intel.com>
-
Joonas Lahtinen authored
Indent GuC/WOPCM documentation correctly to reside under "Memory Management and Command Submission" section to avoid it escaping to the upper level navigation. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190830085849.12519-2-joonas.lahtinen@linux.intel.com
-
Joonas Lahtinen authored
The referenced documentation section has been removed. Remove the link to avoid warning when building the documentation. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190830085849.12519-1-joonas.lahtinen@linux.intel.com
-
Ramalingam C authored
>From Gen12 onwards, HDCP HW block is implemented within transcoders. Till Gen11 HDCP HW block was part of DDI. Hence required changes in HW programming is handled here. As ME FW needs the transcoder detail on which HDCP is enabled on Gen12+ platform, we are populating the detail in hdcp_port_data. v2: _MMIO_TRANS is used [Lucas and Daniel] platform check is moved into the caller [Lucas] v3: platform check is moved into a macro [Shashank] v4: Few optimizations in the coding [Shashank] v5: Fixed alignment in macro definition in i915_reg.h [Shashank] unused variables "reg" is removed. v6: Configuring the transcoder at compute_config. transcoder is used instead of pipe in macros. Rebased. v7: transcoder is cached at intel_hdcp hdcp_port_data is configured with transcoder index asper ME FW. v8: s/trans/cpu_transcoder s/tc/cpu_transcoder v9: rep_ctl is prepared for TCD too. return moved into deault of rep_ctl prepare function [Shashank] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190828164216.405-7-ramalingam.c@intel.com
-
Ramalingam C authored
On gen12+ platforms, HDCP HW is associated to the transcoder. Hence on every modeset update associated transcoder into the intel_hdcp of the port. v2: s/trans/cpu_transcoder [Jani] v3: comment is added for fw_ddi init for gen12+ [Shashank] only hdcp capable transcoder is translated into fw_tc [Shashank] v4: fw_tc initialization is kept for modeset. [Tomas] few extra doc is added at port_data init [Tomas] v5: Few comments are improvised [Tomas] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190828164216.405-6-ramalingam.c@intel.com
-
Ramalingam C authored
For gen12+ platform we need to pass the transcoder info as part of the port info into ME FW. This change fills the payload for ME FW from hdcp_port_data. v2: Doc is enhanced for physical_port and attached_transcoder [Tomas] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Acked-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190828164216.405-5-ramalingam.c@intel.com
-
Ramalingam C authored
I915 needs to send the index of the transcoder as per ME FW. To support this, define enum mei_fw_tc and add as a member into the struct hdcp_port_data. v2: Typo in commit msg is fixed [Shashank] v3: kdoc is added for mei_fw_tc [Tomas] s/MEI_TC_x/MEI_TRANSCODER_x Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tomas Winkler <tomas.winkler@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190828164216.405-4-ramalingam.c@intel.com
-
Ramalingam C authored
We dont need the definition of the enum port outside I915, anymore. Hence move enum port definition into I915 driver itself. v2: intel_display.h is included in intel_hdcp.h v3: enum port is declared in headers. v4: commit msg is rephrased. v5: copyright year is updated [Tomas] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190828164216.405-3-ramalingam.c@intel.com
-
Ramalingam C authored
I915 converts it's port value into ddi index defiend by ME FW and pass it as a member of hdcp_port_data structure. Hence expose the enum mei_fw_ddi to I915 through i915_mei_interface.h. v2: Copyright years are bumped [Tomas] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Acked-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190828164216.405-2-ramalingam.c@intel.com
-
- 29 Aug, 2019 8 commits
-
-
Chris Wilson authored
The addition of the DC_FLUSH failed to ensure sanctity of the post-sync write as CI immediately got a completion CS-event before the breadcrumb was coherent. So let's try the other idea of moving the post-sync write into the CS_STALL. References: https://bugs.freedesktop.org/show_bug.cgi?id=111514 References: e8f6b495 ("drm/i915/execlists: Flush the post-sync breadcrumb write harder") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829081150.10271-2-chris@chris-wilson.co.uk
-
Manasi Navare authored
Create a new function intel_commit_modeset_disables() consistent with the naming in drm atomic helpers and similar to the enable function. This helps better organize the disable sequence in atomic_commit_tail() No functional change v4: * Do not create a function pointer, just a function (Maarten) v3: * Rebase (Manasi) v2: * Create a helper for old_crtc_state disables (Lucas) Suggested-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190828224701.422-1-manasi.d.navare@intel.com
-
Manasi Navare authored
This patch has no functional changes. This just renames the update_crtcs() hooks to commit_modeset_enables() to match the drm_atomic helper naming conventions. v2: * Rebase on drm-tip Suggested-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190827221735.29351-2-manasi.d.navare@intel.com
-
Matthew Auld authored
The sg_table for our backing store might contain addresses from stolen-memory or in the future local-memory, at which point this is no longer a dma-iterator. As a consequence we should now break on NULL iter.sgp, instead of dmap == 0 which is considered an invalid dma address. As a bonus, gcc much prefers this construct, Function old new delta gen8_ggtt_insert_entries 211 192 -19 gen6_ggtt_insert_entries 292 262 -30 i915_error_object_create 996 954 -42 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190829201919.21493-1-matthew.auld@intel.com
-
Fernando Pacheco authored
During normal driver unload we attempt to disable GuC communication while it is currently stopped. This results in a nop'd call to intel_guc_ct_disable within guc_disable_communication because stop/disable rely on the same flag to prevent further comms with CT. We can avoid the call to disable and still leave communication in a satisfactory state by extracting a set of shared steps from stop/disable. This set can include guc_disable_interrupts as we do not require the single caller of guc_stop_communication to be atomic: "drm/i915/selftests: Fixup atomic reset checking". This situation (stop -> disable) only occurs during intel_uc_fini_hw, so during fini, call guc_disable_communication only if currently enabled. The symmetric calls to enable/disable remain unmodified for all other scenarios. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110943Signed-off-by: Fernando Pacheco <fernando.pacheco@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190829174154.14675-1-fernando.pacheco@intel.com
-
Chris Wilson authored
Let the scheduler have a breather in between passes of the longer buddy tests. Important if we are running under kasan etc and this takes far longer than usual! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829170848.969-1-chris@chris-wilson.co.uk
-
José Roberto de Souza authored
According to BSpc if link standby is set on TGL+, PSR will not be enabled. Vendors should not use panels that requires link standby and even if they do, panel should assert a PSR error that will cause PSR to be disabled. BSpec: 50434 Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823082055.5992-8-lucas.demarchi@intel.com
-
Dhinakaran Pandiyan authored
Yf tiling was removed in gen-12, so do not expose Yf modifiers to user space. Gen-12 display also is incompatible with pre-gen12 Y-tiled CCS, so do not expose I915_FORMAT_MOD_Y_TILED_CCS. v2: Rebase to carry forward recently added gen11 formats. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190827084516.6748-1-dhinakaran.pandiyan@intel.com
-
- 28 Aug, 2019 8 commits
-
-
Madhumitha Tolakanahalli Pradeep authored
DSC was not supported on Pipe A for previous platforms. Tigerlake onwards, all the pipes support DSC. Hence, the DSC and FEC restriction on Pipe A needs to be removed. v2: Changes in the logic around removing the restriction around Pipe A (Manasi, Lucas) Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823004655.28905-1-madhumitha.tolakanahalli.pradeep@intel.com
-
Chris Wilson authored
Trust our own workers to not cause unnecessary delays and disable the automatic timeout on their asynchronous fence waits. (Along the same lines that we trust our own requests to complete eventually, if necessary by force.) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190826072149.9447-6-chris@chris-wilson.co.uk
-
Imre Deak authored
There is a difference in BSpec's and the driver's designation of DDI ports. BSpec uses the following names: - before GEN11: BSpec/driver: port A/B/C/D etc - GEN11: BSpec/driver: port A-F - GEN12: BSpec: port A/B/C for combo PHY ports port TC1-6 for Type C PHY ports driver: port A-I. The driver's port D name matches BSpec's TC1 port name. So far power domains were named according to the BSpec designation, to make it easier to match the code against the specification. That however can be confusing when a power domain needs to be matched to a port on GEN12+. To resolve that use the driver's port A-I designation for power domain names too and rename the corresponding power wells so that they reflect the mapping from the driver's to BSpec's port name. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823100711.27833-1-imre.deak@intel.com
-
Chris Wilson authored
We've been ignoring similar coherency issues in IGT for Broadwater, and specifically Broadwater (original gen4) and not, for example, Crestline (same generation as Broadwater, but the mobile variant). Without any means to reproduce locally (I have a 965GM but alas no 965G), fixing will be slow, so tell CI to ignore any failure until we are ready with a fix. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190826133837.6784-1-chris@chris-wilson.co.uk
-
Mika Kuoppala authored
Our current avoidance of non readable mcr range was not inclusive enough. Extend the start and end. References: HSDES#1405586840 Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190809145653.2279-1-mika.kuoppala@linux.intel.com
-
Chris Wilson authored
Quite rarely we see that the CS completion event fires before the breadcrumb is coherent, which presumably is a result of the CS_STALL not waiting for the post-sync operation. Try throwing in a DC_FLUSH into the following pipecontrol to see if that makes any difference. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190827120615.31390-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
igt_ctx_exec allocates a new context for each iteration, keeping them all allocated until the end. Instead, release the local ctx reference at the end of each iteration, allowing ourselves to reap those if under mempressure. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190827161726.3640-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Upon object creation for live_gem_contexts, we fill the object with known scratch and flush it out of the CPU cache. Before performing the GPU fill, we don't need to flush it again and so avoid serialising with previous fills. However, we do need some throttling on the internal interfaces if we do not want to run out of memory! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190827161726.3640-1-chris@chris-wilson.co.uk
-
- 27 Aug, 2019 3 commits
-
-
Daniele Ceraolo Spurio authored
The CS pre-parser can pre-fetch commands across memory sync points and starting from gen12 it is able to pre-fetch across BB_START and BB_END boundaries as well, so when we emit gpu relocs the pre-parser might fetch the target location of the reloc before the memory write lands. The parser can't pre-fetch across the ctx switch, so we use a separate context to guarantee that the memory is synchronized before the parser can get to it. Note that there is no risk of the CS doing a lite restore from the reloc context to the user context, even if the two have the same hw_id, because since gen11 the CS also checks the LRCA when deciding if it can lite-restore. v2: limit new context to gen12+, release in eb_destroy, add a comment in emit_fini_breadcrumb (Chris). Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190827185805.21799-1-daniele.ceraolospurio@intel.com
-
Michel Thierry authored
Compared to Icelake, Tigerlake's MAX_CONTEXT_HW_ID is smaller by one, but since we just use the upper 32 bits of the lrc_desc, it's guaranteed OA will use the correct one. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823082055.5992-19-lucas.demarchi@intel.com
-
Michel Thierry authored
Workaround no longer needed (plus L3_LRA_1_GPGPU doesn't exist). Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823082055.5992-17-lucas.demarchi@intel.com
-