- 28 Oct, 2019 1 commit
-
-
Ville Syrjälä authored
Make CHICKEN_TRANS() a bit less special looking by using _PICK(). Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191024122138.25065-1-ville.syrjala@linux.intel.comReviewed-by:
José Roberto de Souza <jose.souza@intel.com>
-
- 27 Oct, 2019 2 commits
-
-
Chris Wilson authored
ips uses clock delays as opposed to rps frequency bins. To fit the delays into the same rps calculations, we need to invert the ips delays. Fixes: 3e7abf81 ("drm/i915: Extract GT render power state management") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191026200917.1780-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
We would like some freedom to break the user API/ABI for future HW but yet still expose the driver for upstream development on that HW. Currently, we have the i915.force_probe module parameter to avoid binding to HW while the driver is under development, but that is still a little too soft with respect to the stringent no-regression rules if we also plan to be redesigning the uAPI to go along with the new HW. To allow the uAPI to be changed during development, only expose that API and in development HW under STAGING (and BROKEN). Hopefully, making it explicit that such interfaces to that HW are under development and not to be blindly enabled by distributions. Signed-off-by:
Dave Airlie <airlied@redhat.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191027154314.11139-1-chris@chris-wilson.co.uk
-
- 26 Oct, 2019 5 commits
-
-
Chris Wilson authored
Pull the memory region bookkeeping into its file. Let's start clean and see how long it lasts! Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191026202032.4371-1-chris@chris-wilson.co.uk
-
Andi Shyti authored
Pull the GuC interrupt handlers out of i915_irq.c. They now use the GT interrupt facilities rather than the central dispatch. Based on a patch by Chris Wilson. Signed-off-by:
-
Andi Shyti authored
i915_irq.c is large. One reason for this is that has a large chunk of the GT render power management stashed away in it. Extract that logic out of i915_irq.c and intel_pm.c and put it under one roof. Based on a patch by Chris Wilson. Signed-off-by:
-
Chris Wilson authored
The location of RING_MI_MODE (used to stop the ring across resets) moved for Tigerlake. Fixup the new location and include a selftest to verify the location in the default context image. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191026082220.32632-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Avoid angering clang and smatch by using a constant value in a '&&' test, by forcing that constant value into a boolean. E.g., drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c:159:13: warning: use of logical '&&' with constant operand [-Wconstant-logical-operand] if (!delay && CONFIG_DRM_I915_PREEMPT_TIMEOUT) { ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reported-by:kbuild test robot <lkp@intel.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191025135943.12524-1-chris@chris-wilson.co.uk
-
- 25 Oct, 2019 23 commits
-
-
José Roberto de Souza authored
This sequence was recently added to fix internal HW sequences to reset TC ports. HSDES: 1507287614 HSDES: 14010071447 BSpec: 49292 Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Chris Wilson authored
As the GT may be running in parallel with the module initialisation code, we may enter i915_pmu_gt_parked() as we are executing i915_pmu_register(). We have to init the spinlock before we mark pmu.event_init so that it is available for use by i915_pmu_gt_parked() (which may run as soon as event_init is set). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112127Signed-off-by:
-
Matthew Auld authored
We can be more aggressive in our testing by launching a number of kthreads, where each is submitting its own copy or fill batches on a set of random sized objects. Also since the underlying fill and copy batches can be pre-empted mid-batch(for particularly large objects), throw in a random mixture of ctx priorities per thread to make pre-emption a possibility. Signed-off-by:
-
Matthew Auld authored
Now that for all the relevant backends we do randomised testing, we need to make sure we still sanity check the obvious cases that might blow up, such that introducing a temporary regression is less likely. Also rather than do this for every backend, just limit to our two memory types: system and local. Suggested-by:
-
Matthew Auld authored
Ditch the dubious static list of sizes to enumerate, in favour of choosing a random size within the limits of each backing store. With repeated CI runs this should give us a wider range of object sizes, and in turn more page-size combinations, while using less machine time. Signed-off-by:
-
Matthew Auld authored
Add LMEM objects to list of backends we test for huge-GTT-pages. Signed-off-by:
-
Matthew Auld authored
Simple test writing to dwords across an object, using various engines in a randomized order, checking that our writes land from the cpu. Signed-off-by:
-
Abdiel Janulgue authored
We can create LMEM objects, but we also need to support mapping them into kernel space for internal use. Signed-off-by:
Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by:
Steve Hampson <steven.t.hampson@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
-
Abdiel Janulgue authored
Create an io-mapping to describe the CPU aperture for lmem. Signed-off-by:
-
Matthew Auld authored
We currently define LMEM, or local memory, as just another memory region, like system memory or stolen, which we can expose to userspace and can be mapped to the CPU via some BAR. Signed-off-by:
-
Lucas De Marchi authored
Split gen11_irq_handler() to receive as parameter the function pointers. This allows to share the interrupt handler even if the enable/disable functions are different. Make sure it's always inlined to avoid the extra indirect call on the hot path. Checking with gcc 9 this produce the exact same code as of now: $ size drivers/gpu/drm/i915/i915_irq*.o text data bss dec hex filename 47511 560 0 48071 bbc7 drivers/gpu/drm/i915/i915_irq.o 47511 560 0 48071 bbc7 drivers/gpu/drm/i915/i915_irq_new.o $ gdb -batch -ex 'file drivers/gpu/drm/i915/i915_irq.o' -ex 'disassemble gen11_irq_handler' > /tmp/old.s $ gdb -batch -ex 'file drivers/gpu/drm/i915/i915_irq_new.o' -ex 'disassemble gen11_irq_handler' > /tmp/new.s $ git diff --no-index /tmp/{old,new}.s $ So, no change in behavior, just a simple refactor. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: -
Lucas De Marchi authored
On dgfx there's no LLC and eDRAM control table. Since now this also means the device has global MOCS, just return early on the initialization function. L3 settings still apply and still need to be tweaked. Bspec: 45101 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191024195122.22877-3-lucas.demarchi@intel.com
-
Stuart Summers authored
Add a new macro for GEN12 platforms to be grouped under dgfx feature set. Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Signed-off-by:
-
José Roberto de Souza authored
This will be helpful to diferentiate a set of GPUs with the same GEN version. Signed-off-by:
-
Lionel Landwerlin authored
TGL introduced a feature in which we map the main surface to the auxiliary surface. If we screw up the page tables, the HW has a register to tell us which engine encounters a fault in the page table walk. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Acked-by:
-
Ville Syrjälä authored
The change to skip the PCH reference initialization during fastboot did end up breaking FDI. To fix that let's try to do the PCH reference init whenever we're disabling a DPLL that was using said reference previously. Cc: stable@vger.kernel.org Tested-by:
Andrija <akijo97@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112084 Fixes: b16c7ed9 ("drm/i915: Do not touch the PCH SSC reference if a PLL is using it") Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Chris Wilson authored
The parallel switch test has an underlying assumption that its requests are executed in order of submission, which is only true if the backend manages to keep up. Ensure the order of execution matches the submission order by explicit dependencies and so when we wait on the last request, we know we wait on completion of the entire queue. Signed-off-by:
-
Tvrtko Ursulin authored
Intel_lrc.c is the only caller and so to avoid some header file ordering issues in future patches move these two over there. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Anna Karas authored
Replace PLLs names used in documentation to that used in the code. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Fixes: 68ff39c3 ("drm/i915/tgl: Add new pll ids") Signed-off-by:
Anna Karas <anna.karas@intel.com> Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
-
Anna Karas authored
Add description of wakeref member of intel_shared_dpll structure to documentation. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
-
Anna Karas authored
Update header files containing i915_perf_stream, i915_perf_stream_ops and i915_oa_ops definitions since they have been moved from i915_drv.h to i915_perf_types.h. Cc: Robert Bragg <robert@sixbynine.org> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
-
Chris Wilson authored
BAT is growing a little fat and CI is under pressure and needs to trim off some redundant runtime. An easy option is to reduce the selftest runtimes, so try halving our default subtest timeout. While this reduces the number of iterations used, for the majority of tests that are passing, repeat runs (with different CI_DRM) will make up the difference -- a negative consequence though is that we may reduce the frequency of sporadic failures. Hopefully, we have no tests that were crucially dependent on the previous 1s timeout... Suggested-by:
Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191025092749.13468-1-chris@chris-wilson.co.uk
-
José Roberto de Souza authored
Right now if sink reported any PSR error or if it fails to acknowledge the PSR wakeup it sets a flag and do not attempt to enable PSR anymore. That is the safest approach to avoid repetitive glitches and allowed us to have PSR enabled by default. But from time to time even good PSR panels have a PSR error, causing tests to fail. And for now we are not yet to the point were we could try to recover from PSR errors, so lets add this information to the debugfs so IGT can check if PSR is disabled because of sink errors or not and eliminate this noise from CI runs. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ap Kamal <kamal.ap@intel.com> Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191023214932.94679-1-jose.souza@intel.com
-
- 24 Oct, 2019 9 commits
-
-
Matt Roper authored
Gen11+ has more hardware planes than gen9 so we need to test additional pipe interrupt register bits to recognize any GTT faults that happen on these extra planes. Bspec: 50335 Signed-off-by:
-
Tapani Pälli authored
As with commit 3fe0107e, this change fixes multiple tests that are using the invocation counts. Documentation doesn't list the workaround for TGL but applying it fixes the tests. Signed-off-by:
Tapani Pälli <tapani.palli@intel.com> Acked-by:
-
Mika Kuoppala authored
On testing the whitelists, using any of the nonpriv flags when trying to access the register offset will lead to failure. Define address mask to get the mmio offset in order to guard against any current and future flag usage. v2: apply also on scrub_whitelisted_registers (Lionel) Cc: Tapani Pälli <tapani.palli@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
-
Ap Kamal authored
'Link CRC error' will now have same error level as other PSR2 errors like 'RFB storage error' and 'VSC SDP uncorrectable error'. Signed-off-by:
Ap Kamal <kamal.ap@intel.com> Reviewed-by:
-
Ville Syrjälä authored
snb supports fp16 pixel formats on the sprite planes. Expose that capability. Nothing special needs to be done, it just works. v2: Rebase on top of icl fp16 Split snb+ sprite bits into a separate patch Reviewed-by:Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
ivb+ supports fp16 pixel formats on the sprite planes planes. Expose that capability. On ivb/hsw fp16 scanout is slightly busted. The output from the plane will have 1/4 the expected value. For the sprite plane we can fix that up with the plane gamma unit. This was fixed on bdw. v2: Rebase on top of icl fp16 Split the ivb+ sprite birs into a separate patch v3: Move ivb_need_sprite_gamma() check one level up so that we don't waste time programming garbage into he gamma registers Reviewed-by: -
Ville Syrjälä authored
gen4+ supports fp16 pixel formats on the primary planes. Add the relevant code. On ivb fp16 scanout is slightly busted. The output from the plane will have 1/4 the expected value. For the primary plane we would have to use the pipe gamma or pipe csc to correct that which would affect all the other planes as well, hence we simply choose not to expose fp16 on the ivb primary plane. On hsw the primary plane got fixed. On gmch platforms I observed that the plane width must be below 2k pixels with fp16 or else we get a corrupted image. This limitation does not seem to be documented in bspec. I verified the exact limit using the chv pipe B primary plane since it has windowing capability. The stride limits are unaffected by fp16. v2: Rebase on top of icl fp16 Split thea gen4+ primary plane bits into a separate patch Deal with HAS_GMCH() Reviewed-by: -
Ville Syrjälä authored
skl+ supports fp16 pixel formats on all universal planes. Add the necessary bits to expose that capability. The main different to icl is that we can't scale fp16, so need to add the relevant checks. v2: Rebase on top of icl fp16 Split skl+ bits into a separate patch Reviewed-by: -
Ville Syrjälä authored
Now that the planes declare their minimum cdclk requirements properly we don't need to check the cdclk in skl_max_scale() anymore. Just check against the maximum downscale ratio, and move the code next to it's only caller. v2: Add a comment explaining the HQ vs. not thing Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
