- 10 Sep, 2019 9 commits
-
-
Chris Wilson authored
Currently, if there is time remaining before the start of the loop, we do one full iteration over many possible different chunks within the object. A full loop may take 50+s (depending on speed of indirect GTT mmapings) and we try separately with LINEAR, X and Y -- at which point igt times out. If we check more frequently, we will interrupt the loop upon our timeout -- it is hard to argue for as this significantly reduces the test coverage as we dramatically reduce the runtime. In practical terms, the coverage we should prioritise is in using different fence setups, forcing verification of the tile row computations over the current preference of checking extracting chunks. Though the exhaustive search is great given an infinite timeout, to improve our current coverage, we also add a randomised smoketest of partial mmaps. So let's do both, add a randomised smoketest of partial tiling chunks and the exhaustive (though time limited) search for failures. Even in adding another subtest, we should shave 100s off BAT! (With, hopefully, no loss in coverage, at least over multiple runs.) 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/20190910121009.13431-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Being a "low-level" test, we opt to bypass the normal bind/unbind hooks for the lower level insert_entries/clear_range. For ggtt, the bind/unbind hooks provide the runtime wakeref and so we must also handle this in exercising the low level hooks. <4> [538.151672] RPM raw-wakeref not held <4> [538.151825] WARNING: CPU: 0 PID: 11 at ./drivers/gpu/drm/i915/intel_runtime_pm.h:107 fwtable_read32+0x1be/0x300 [i915] <4> [538.151830] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp btusb btrtl btbcm x86_pkg_temp_thermal coretemp btintel crct10dif_pclmul bluetooth crc32_pclmul snd_intel_nhlt snd_hda_codec ecdh_generic ghash_clmulni_intel ecc snd_hwdep snd_hda_core lpc_ich r8169 realtek snd_pcm mei_me mei prime_numbers pinctrl_broxton pinctrl_intel [last unloaded: i915] <4> [538.151861] CPU: 0 PID: 11 Comm: migration/0 Tainted: G U 5.3.0-rc7-CI-Trybot_4938+ #1 <4> [538.151864] Hardware name: Intel corporation NUC6CAYS/NUC6CAYB, BIOS AYAPLCEL.86A.0056.2018.0926.1100 09/26/2018 <4> [538.151960] RIP: 0010:fwtable_read32+0x1be/0x300 [i915] <4> [538.151965] Code: e8 e7 f9 5f e0 e9 0b ff ff ff 80 3d d5 8d 26 00 00 0f 85 81 fe ff ff 48 c7 c7 ef 01 bd a0 c6 05 c1 8d 26 00 01 e8 b2 e4 6a e0 <0f> 0b e9 67 fe ff ff 80 3d ad 8d 26 00 00 0f 85 65 fe ff ff 48 c7 <4> [538.151969] RSP: 0018:ffffc9000007be10 EFLAGS: 00010086 <4> [538.151972] RAX: 0000000000000000 RBX: ffff88826be10d50 RCX: 0000000000000002 <4> [538.151975] RDX: 0000000080000002 RSI: 0000000000000000 RDI: 00000000ffffffff <4> [538.151978] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 <4> [538.151981] R10: 0000000000000000 R11: ffffc9000007bcb0 R12: 0000000000101008 <4> [538.151984] R13: 0000000000000000 R14: ffffc9000036f638 R15: 0000000000000002 <4> [538.151987] FS: 0000000000000000(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 <4> [538.151990] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [538.151993] CR2: 00007fd48e7052f8 CR3: 0000000005210000 CR4: 00000000003406f0 <4> [538.151995] Call Trace: <4> [538.152106] bxt_vtd_ggtt_clear_range__cb+0x38/0x40 [i915] Signed-off-by:
-
Chris Wilson authored
As soon as we re-enable the various functions within the HW, they may go off and read data via a GGTT offset. Hence, if we have not yet restored the GGTT PTE before then, they may read and even *write* random locations in memory. Detected by DMAR faults during resume. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190909110011.8958-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
Be paranoid and make sure we flush any and all writes out of the WCB before performing the UC mmio to update the RING_TAIL. (An UC write should itself be enough to do the flush, hence the paranoia here.) Quite infrequently, we see problems where the GPU seems to overshoot the RING_TAIL and so executes garbage, hence the speculation. References: https://bugs.freedesktop.org/show_bug.cgi?id=111598 References: https://bugs.freedesktop.org/show_bug.cgi?id=111417 References: https://bugs.freedesktop.org/show_bug.cgi?id=111034Signed-off-by:
-
Chris Wilson authored
Icelake hit an issue where it missed reporting a completion event and instead jumped straight to a idle->active event (skipping over the active->idle and not even hitting the lite-restore preemption). 661497511us : process_csb: rcs0 cs-irq head=11, tail=0 661497512us : process_csb: rcs0 csb[0]: status=0x10008002:0x00000020 [lite-restore] 661497512us : trace_ports: rcs0: preempted { 28cc8:11052, 0:0 } 661497513us : trace_ports: rcs0: promote { 28cc8:11054, 0:0 } 661497514us : __i915_request_submit: rcs0 fence 28cc8:11056, current 11052 661497514us : __execlists_submission_tasklet: rcs0: queue_priority_hint:-2147483648, submit:yes 661497515us : trace_ports: rcs0: submit { 28cc8:11056, 0:0 } 661497530us : process_csb: rcs0 cs-irq head=0, tail=1 661497530us : process_csb: rcs0 csb[1]: status=0x10008002:0x00000020 [lite-restore] 661497531us : trace_ports: rcs0: preempted { 28cc8:11054!, 0:0 } 661497535us : trace_ports: rcs0: promote { 28cc8:11056, 0:0 } 661497540us : __i915_request_submit: rcs0 fence 28cc8:11058, current 11054 661497544us : __execlists_submission_tasklet: rcs0: queue_priority_hint:-2147483648, submit:yes 661497545us : trace_ports: rcs0: submit { 28cc8:11058, 0:0 } 661497553us : process_csb: rcs0 cs-irq head=1, tail=2 661497553us : process_csb: rcs0 csb[2]: status=0x10000001:0x00000000 [idle->active] 661497574us : process_csb: process_csb:1538 GEM_BUG_ON(*execlists->active) Signed-off-by: -
Swati Sharma authored
For cherryview, add hw read out to create hw blob of gamma lut values. Review comments from previous series: https://patchwork.freedesktop.org/patch/328252 v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally within the function [Ville] -Renamed function cherryview_get_color_config() to chv_read_luts() -Renamed cherryview_get_gamma_config() to chv_read_cgm_gamma_lut() [Ville] v9: -80 character limit [Uma] -Made read func para as const [Ville, Uma] -Renamed chv_read_cgm_gamma_lut() to chv_read_cgm_gamma_lut() [Ville, Uma] Signed-off-by:
Swati Sharma <swati2.sharma@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Swati Sharma authored
For i965, add hw read out to create hw blob of gamma lut values. Review comments from old series: https://patchwork.freedesktop.org/series/58039/ v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally within the function [Ville] -Renamed i965_get_color_config() to i965_read_lut() [Ville] -Renamed i965_get_gamma_config_10p6() to i965_read_gamma_lut_10p6() [Ville] v9: -Typo and 80 character limit [Uma] -Made read func para as const [Ville, Uma] -Renamed i965_read_gamma_lut_10p6() to i965_read_lut_10p6() [Ville, Uma] v10: -Swapped ldw and udw while creating hw blob [Jani] -Added last index rgb lut value from PIPEGCMAX to h/w blob [Jani] Signed-off-by:
-
Swati Sharma authored
intel_color_get_gamma_bit_precision() is extended for cherryview by adding chv_gamma_precision(), i965 will use existing i9xx_gamma_precision() func only. Signed-off-by:
-
Chris Wilson authored
During reset, we try to ensure no forward progress of the CS prior to the reset by setting the STOP_RING bit in RING_MI_MODE. Since gen9, this register is context saved and do we end up in the odd situation where we save the STOP_RING bit and so try to stop the engine again immediately upon resume. This is quite unexpected and causes us to complain about an early CS completion event! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111514Signed-off-by:
-
- 09 Sep, 2019 6 commits
-
-
Matthew Auld authored
It might prove useful in the future to know if the vma is utilising huge-GTT-pages. Related to this is the GTT cache, where there is some HW "quirkiness" where it must be disabled if using 2M pages, so include that for good measure. Suggested-by:
-
Matthew Auld authored
Try to tidy up the cache-coloring such that we rid the code of any mm.color_adjust assumptions, this should hopefully make it more obvious in the code when we need to actually use the cache-level as the color, and as a bonus should make adding a different color-scheme simpler. Signed-off-by:
-
Matthew Auld authored
Make it clear that the color adjust callback applies to the ggtt. Signed-off-by:
-
Matthew Auld authored
Export color_differs so that we can use it elsewhere. Signed-off-by:
-
Chris Wilson authored
As we may unwind incomplete requests (for preemption) prior to processing the CSB and the schedule-out events, we may update rq->engine (resetting it to point back to the parent virtual engine) prior to calling execlists_schedule_out(), invalidating the assertion that the request still points to the inflight engine. (The likelihood of this is increased if the CSB interrupt processing is pushed to the ksoftirqd for being too slow and direct submission overtakes it.) Tvrtko summarised it as: "So unwind from direct submission resets rq->engine and races with process_csb from the tasklet which notices request has actually completed." Reported-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Fixes: df403069 ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190907105046.19934-1-chris@chris-wilson.co.uk
-
Matthew Auld authored
We are meant to register the kmem cache at init, such the supplied exit and shrink hooks can be called. Signed-off-by:
-
- 06 Sep, 2019 6 commits
-
-
Andi Shyti authored
Refactor the GT power management interface to work through the GT now that it is under the control of gt/ Based on a patch by Chris Wilson. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Michel Thierry authored
Gen12 has subtle changes in the reg state context offsets (some fields are gone, some are in a different location), compared to previous Gens. The simplest approach seems to be keeping Gen12 (and future platform) changes apart from the previous gens, while keeping the registers that are contiguous in functions we can reuse. v2: alias, virtual engine, rpcs, prune unused regs v3: use engine base (Daniele), take ctx_bb for all Bspec: 46255 Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Tested-by:
-
Mika Kuoppala authored
Daniele pointed out that relative mmio works differently in on context restore. Instead of adding the engine mmio base to offset, it masks out the base and adds bits [12:2] to current engine base. This should allow us to construct context register state to be applicable to all instances, including virtual. And avoid the trouble of updating the registers on virtual instances when submitting work. v2: only enable for gen12 for now (Mika) v3: make enabling readable (Chris) Bspec: 20206 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Suggested-by:
-
Matt Roper authored
Unlike gen11, which always ran at 50MHz when the cdclk PLL was disabled, TGL runs at refclk/2. The 50MHz croclk/2 is only used by hardware during some power state transitions. Bspec: 49201 Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190905181337.23727-1-matthew.d.roper@intel.comReviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Ville Syrjälä authored
This adds basic immutable support for the zpos property. The zpos increases from bottom to top: primary, sprites, cursor. Signed-off-by:
Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/YSH9PasoADJJdNJCSdI4m55ankIBsCaoSgkw-NQ5dlruCAxc8J-SQwVl5n3ddSAMDLTdbdyQvkONmtbjkUU-TQk5VIu1p-aZRO1OjjuSxjY=@emersion.frReviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Chris Wilson authored
If we make sure we grab a strong reference to each object as we dump it, we can reduce the locks outside of our iterators to an rcu_read_lock. This should prevent errors like: [ 2138.371911] BUG: KASAN: use-after-free in per_file_stats+0x43/0x380 [i915] [ 2138.371924] Read of size 8 at addr ffff888223651000 by task cat/8293 [ 2138.371947] CPU: 0 PID: 8293 Comm: cat Not tainted 5.3.0-rc6-CI-Custom_4352+ #1 [ 2138.371953] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J4205-ITX, BIOS P1.40 07/14/2017 [ 2138.371959] Call Trace: [ 2138.371974] dump_stack+0x7c/0xbb [ 2138.372099] ? per_file_stats+0x43/0x380 [i915] [ 2138.372108] print_address_description+0x73/0x3a0 [ 2138.372231] ? per_file_stats+0x43/0x380 [i915] [ 2138.372352] ? per_file_stats+0x43/0x380 [i915] [ 2138.372362] __kasan_report+0x14e/0x192 [ 2138.372489] ? per_file_stats+0x43/0x380 [i915] [ 2138.372502] kasan_report+0xe/0x20 [ 2138.372625] per_file_stats+0x43/0x380 [i915] [ 2138.372751] ? i915_panel_show+0x110/0x110 [i915] [ 2138.372761] idr_for_each+0xa7/0x160 [ 2138.372773] ? idr_get_next_ul+0x110/0x110 [ 2138.372782] ? do_raw_spin_lock+0x10a/0x1d0 [ 2138.372923] print_context_stats+0x264/0x510 [i915] Signed-off-by:
David Weinehall <david.weinehall@linux.intel.com> Reviewed-by:
-
- 05 Sep, 2019 8 commits
-
-
José Roberto de Souza authored
Tiger Lake has up to 4 pipes so the mask would need to be 0xf instead of 0x7. Do not hardcode the mask so it allows the fake MST encoders to connect to all pipes no matter how many the platform has. Iterating over all pipes to keep consistent with intel_ddi_init(). Initialy this patch was replaced by commit 4eaceea3 ("drm/i915: Fix DP-MST crtc_mask") but userspace it not correctly using encoder.possible_crtcs and it was reverted by commit e838bfa8 ("Revert "drm/i915: Fix DP-MST crtc_mask"") Userspace should be fixed but it might take a while, so bringing this patch back for now. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
José Roberto de Souza authored
WA 1409120013 is also valid for TGL, so lets check for ">= 11". BSpec: 52890 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Add case for gen == 12 and add MISSING_CASE() for future gens. We were already handling gen12 as the default, so this doesn't change the current behavior. BSpec: 19481 and 44980 Cc: CQ Tang <cq.tang@intel.com> Signed-off-by:
-
Lucas De Marchi authored
SAGV is not currently working for Tiger Lake. We better disable it until the implementation is stabilized and we can enable it. HSDES: 1409542895 2208191909 Signed-off-by:
-
Lucas De Marchi authored
Gen 12 onwards moves the DP_TP_* registers to be transcoder-based rather than port-based. This adds the new register addresses and changes all the callers to use the register saved in intel_dp->regs.*. This is filled out when preparing to enable the port so we take into account if we should use the transcoder or the port. v2: reimplement by stashing the registers we want to access under intel_dp->reg. Now they are initialized when enabling the port. Ville suggested to store the transcoder to be used exclusively by TGL+. After implementing I thought just storing the register directly made it cleaner. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Lucas De Marchi authored
DP_TP_{CTL,STATUS} should only be programmed when the encoder is intel_dp. Checking its current usages intel_disable_ddi_buf() is the only offender, with other places being protected by checks like pipe_config->fec_enable that is only set by intel_dp. v3 (José): - Using intel_crtc_has_dp_encoder() instead of intel_encoder_is_dp() (Ville) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: -
José Roberto de Souza authored
For older gens PSR IIR and IMR have fixed addresses. From TGL onwards those registers moved to each transcoder offset. The bits for the registers are defined without an offset per transcoder as right now we have one register per transcoder. So add a fake "trans_shift" when calculating the bits offsets: it will be 0 for gen12+ and psr.transcoder otherwise. v2 (Lucas): change the implementation to use trans_shift instead of getting each bit value with a different macro Cc: Imre Deak <imre.deak@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
José Roberto de Souza authored
It was enabling and checking PSR interruptions in every transcoder while it should keep the interruptions on the non-used transcoders masked. While doing this it gives us trouble on Tiger Lake if we are reading/writing to registers of disabled transcoders since from gen12 onwards the registers are relative to the transcoder. Instead of forcing them ON to access those registers, just avoid the accesses as they are not needed. v2 (Lucas): - Explain why we can't keep accessing all transcoders - Remove TODO about extending the irq handling to multiple instances: when/if implementing multiple instances it's pretty clear by the singleton psr that it needs to be extended - Fix intel_psr_debug_set() calling psr_irq_control() with psr.transcoder not set yet (from Imre). Now we only set the debug register right away if psr is already enabled. Otherwise we just record the value to be set when enabling the source. - Do not depend on the value of TRANSCODER_A. Just be relative to it (from Imre) - handle psr error last so we don't schedule the work before handling the other flags v3: - Adding a warning about setting reserverd bits on EDP_PSR_IMR Cc: Imre Deak <imre.deak@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
- 04 Sep, 2019 10 commits
-
-
Daniel Vetter authored
The cpu (de)tiler hw is gone, this stopped being useful. Plus it never supported any of the fancy new tiling formats, which means userspace also stopped using the magic side-channel this provides. This would totally break a lot of the igts, but they're already broken for the same reasons as userspace on gen12 would be. v2: Look at ggtt->num_fences instead, that also avoids the need for a comment (Chris). This also means that gen12 support really needs to make sure num_fences is set to 0. There is a patch for that, but it checks for HAS_MAPPABLE_APERTURE, which I'm not sure is the right thing really. Adding relevant people. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
This reverts commit 4eaceea3. Several userspace clients (modesetting ddx and mutter+wayland at least) handle encoder.possible_crtcs incorrectly. What they essentially do is the following: possible_crtcs = ~0; for_each_possible_encoder(connector) possible_crtcs &= encoder->possible_crtcs; Ie. they calculate the intersection of the possible_crtcs for the connector when they really should be calculating the union instead. In our case each MST encoder now has just one unique bit set, and so the intersection is always zero. The end result is that MST connectors can't be lit up because no crtc can be found to drive them. I've submitted a fix for the modesetting ddx [1], and complained on #wayland about mutter, so hopefully the situation will improve in the future. In the meantime we have regression, and so must go back to the old way of misconfiguring possible_crtcs in the kernel. [1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277 Cc: Jonas Ådahl <jadahl@gmail.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111507Signed-off-by:
-
Chris Wilson authored
This bit was fliped on for "syncing dependencies between camera and graphics". BSpec has no recollection why, and it is causing unrecoverable GPU hangs with Vulkan compute workloads. From BSpec, setting bit5 to 0 enables relaxed padding requirements for buffers, 1D and 2D non-array, non-MSAA, non-mip-mapped linear surfaces; and *must* be set to 0h on skl+ to ensure "Out of Bounds" case is suppressed. Reported-by:
Jason Ekstrand <jason@jlekstrand.net> Suggested-by:
-
Swati Sharma authored
For glk, add hw read out to create hw blob of gamma lut values. v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally within the function [Ville] -Renamed glk_get_color_config() to glk_read_luts() [Ville] -Added degamma validation [Ville] v9: -80 character limit [Uma] -Made read func para as const [Ville, Uma] Signed-off-by: -
Swati Sharma authored
For ilk, add hw read out to create hw blob of gamma lut values. v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally within the function [Ville] -Renamed ilk_get_color_config() to ilk_read_luts() [Ville] v9: -80 character limit [Uma] -Made read func para as const [Ville, Uma] -Renamed ilk_read_gamma_lut() to ilk_read_lut_10() [Uma, Ville] v10: -Made ilk_read_luts() static [Jani] -ilk_load_lut_10 has lut_size, not (lut_size - 1) [Jani] Signed-off-by: -
Swati Sharma authored
For the legacy(gen < 4) gamma, add hw read out to create hw blob of gamma lut values. Also, add function intel_color_lut_pack to convert hw value with given bit precision to lut property val. v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally within the function [Ville] -Renamed function i9xx_get_color_config() to i9xx_read_luts() -Renamed i9xx_get_config_internal() to i9xx_read_lut_8() [Ville] v9: -Change in commit message [Jani, Uma] -Wrap commit within 75 characters [Uma] -Use macro for 256 [Uma] -Made read func para as const [Ville, Uma] v10: -Made i9xx_read_luts() static [Jani] Signed-off-by: -
Swati Sharma authored
Add macro to compare hw/sw gamma lut values. First need to check whether hw/sw gamma mode matches or not. If not no need to compare lut values, if matches then only compare lut entries. v5: -Called PIPE_CONF_CHECK_COLOR_LUT inside if (!adjust) [Jani] -Added #undef PIPE_CONF_CHECK_COLOR_LUT [Jani] v8: -Added check for gamma mode before gamma lut entry comparison [Jani] -Split patch 3 into 4 patches Signed-off-by:Uma Shankar <uma.shankar@intel.com> Reviewed-by:
-
Swati Sharma authored
Add func intel_color_lut_equal() to compare hw/sw gamma lut values. Since hw/sw gamma lut sizes and lut entries comparison will be different for different gamma modes, add gamma mode dependent checks. v3: -Rebase v4: -Renamed intel_compare_color_lut() to intel_color_lut_equal() [Jani] -Added the default label above the correct label [Jani] -Corrected smatch warn "variable dereferenced before check" [Dan Carpenter] v5: -Added condition (!blob1 && !blob2) return true [Jani] v6: -Made patch11 as patch3 [Jani] v8: -Split patch 3 into 4 patches -Optimized blob check condition [Ville] v9: -Exclude spilt gamma mode (bdw and ivb platforms) as there is exception in way gamma values are written in hardware [Ville] -Added exception made in commit [Uma] -Dropped else, character limit and indentation [Uma] -Added multi segmented gama mode for icl+ platforms [Uma] v10: -Dropped multi segmented mode for icl+ platforms [Jani] -Removed references of sw and hw state in compare code [Jani] -Dropped inline from func [Jani] Signed-off-by: -
Swati Sharma authored
Each platform supports different gamma modes and each gamma mode has different bit precision. Here bit precision corresponds to number of bits the hw LUT supports. Add func per platform to return bit precision corresponding to gamma mode which will be later used as a parameter in lut comparison function intel_color_lut_equal(). This is done for legacy, ilk, glk and their variant platforms. v6: -Added func intel_color_get_bit_precision() to get bit precision for gamma and degamma lut readout depending upon platform and corresponding to load_luts() [Ankit] -Made patch11 as patch3 [Jani] v7: -Renamed func intel_color_get_bit_precision() to intel_color_get_gamma_bit_precision() -Added separate function/platform for gamma bit precision [Ville] -Corrected checkpatch warnings v8: -Split patch 3 into 4 separate patches v9: -Changed commit message, gave more info [Uma] -Added precision func for icl+ platform v10: -Removed precision func for chv and icl+ platforms [Jani] -Added gamma_enable check once [Jani] Signed-off-by: -
Swati Sharma authored
Add debug log for color related parameters like gamma_mode, gamma_enable, csc_enable, etc inside intel_dump_pipe_config(). v6: -Added debug log for color para in intel_dump_pipe_config [Jani] v7: -Split patch 3 into 4 patches v8: -Corrected alignment [Uma] Signed-off-by:
-
- 03 Sep, 2019 1 commit
-
-
Chris Wilson authored
It's been a long time since we accidentally reported -EIO upon wedging, it can now only be generated by failure to swap in a page. Signed-off-by:
Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190902040303.14195-4-chris@chris-wilson.co.uk
-
