- 10 Mar, 2016 6 commits
-
-
Maarten Lankhorst authored
When intel_update_watermarks is called on skylake from the hw state readout disable function it calls intel_update_watermarks. intel_update_watermarks inspects crtc->state, which should be set to disabled. This wasn't the case, and this resulted in a divide-by-zero in skl_update_wm when intel_update_watermarks got called. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 295 at drivers/gpu/drm/i915/intel_pm.c:2834 skl_update_pipe_wm+0x102/0x8c0 [i915]() WARN_ON(!config->num_pipes_active) Modules linked in: coretemp i915(+) xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx CPU: 1 PID: 295 Comm: systemd-udevd Tainted: G U W 4.5.0-rc4 -xxxxxx #25 Hardware name: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0000000000000000 ffff88003777f5a8 ffffffff813485c2 ffff88003777f5f0 ffffffffa0236240 ffff88003777f5e0 ffffffff81050fce ffff8800aa420000 ffff8800aba18000 ffff8800aba18000 ffff880037304c00 ffff8800aa420000 Call Trace: [<ffffffff813485c2>] dump_stack+0x67/0x95 [<ffffffff81050fce>] warn_slowpath_common+0x9e/0xc0 [<ffffffff8105103c>] warn_slowpath_fmt+0x4c/0x50 [<ffffffff8106945e>] ? flush_work+0x8e/0x280 [<ffffffff810693d5>] ? flush_work+0x5/0x280 [<ffffffffa016add2>] skl_update_pipe_wm+0x102/0x8c0 [i915] [<ffffffffa016b96f>] skl_update_wm+0xff/0x5f0 [i915] [<ffffffff810928ee>] ? trace_hardirqs_on_caller+0x15e/0x1d0 [<ffffffff8109296d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffffa016ce6e>] intel_update_watermarks+0x1e/0x30 [i915] [<ffffffffa01d3ee2>] intel_crtc_disable_noatomic+0xd2/0x150 [i915] [<ffffffffa01dd3d2>] intel_modeset_setup_hw_state+0xdd2/0xde0 [i915] [<ffffffffa01dfd83>] intel_modeset_init+0x15a3/0x1950 [i915] [<ffffffffa02160b6>] i915_driver_load+0x13c6/0x1720 [i915] [<ffffffff81522160>] ? add_sysfs_fw_map_entry+0x9b/0x9b [<ffffffffa00b15ef>] drm_dev_register+0x6f/0xb0 [drm] [<ffffffffa00b3b3a>] drm_get_pci_dev+0x10a/0x1d0 [drm] [<ffffffffa01582d9>] i915_pci_probe+0x49/0x50 [i915] [<ffffffff8138ae30>] pci_device_probe+0x80/0xf0 [<ffffffff8143e2ac>] driver_probe_device+0x1bc/0x3d0 [<ffffffff8143e526>] __driver_attach+0x66/0x90 [<ffffffff8143e4c0>] ? driver_probe_device+0x3d0/0x3d0 [<ffffffff8143be3b>] bus_for_each_dev+0x5b/0xa0 [<ffffffff8143db3e>] driver_attach+0x1e/0x20 [<ffffffff8143d461>] bus_add_driver+0x151/0x270 [<ffffffff8143eabc>] driver_register+0x8c/0xd0 [<ffffffff8138a2ed>] __pci_register_driver+0x5d/0x60 [<ffffffffa00b3c58>] drm_pci_init+0x58/0xf0 [drm] [<ffffffff8109296d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffffa02aa000>] ? 0xffffffffa02aa000 [<ffffffffa02aa094>] i915_init+0x94/0x9b [i915] [<ffffffff81000423>] do_one_initcall+0x113/0x1f0 [<ffffffff810a4b21>] ? rcu_read_lock_sched_held+0x61/0x90 [<ffffffff811601dc>] ? kmem_cache_alloc_trace+0x1cc/0x280 [<ffffffff8111110a>] do_init_module+0x60/0x1c8 [<ffffffff810c731b>] load_module+0x1ceb/0x2410 [<ffffffff810c3a60>] ? store_uevent+0x40/0x40 [<ffffffff811763d1>] ? kernel_read+0x41/0x60 [<ffffffff810c7c1d>] SYSC_finit_module+0x8d/0xa0 [<ffffffff810c7c4e>] SyS_finit_module+0xe/0x10 [<ffffffff815f1e97>] entry_SYSCALL_64_fastpath+0x12/0x6f ---[ end trace 1149e9ab3695a423 ]--- ------------[ cut here ]------------ Changes since v1: - Clear state before calling any function after .crtc_disable. Reported-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/56D6FD21.7020907@linux.intel.comTested-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com>
-
Ville Syrjälä authored
Avoid some head spinning by renaming the crtc_state variable to old_crtc_state. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457543247-13987-6-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
We must wait for the hardware to exit cxsr before doing the plane update, so add the missing vblank wait to pre_plane_update after disabling cxsr. We have the wait for vblank in the pre_disable_primary hook, but not in the pre_plane_update hook. Just move the code from (and comment) from pre_disable_primary into pre_plane_update. Well, we still have to keep it in pre_disable_primary for these strange _noatomic codepaths, so let's do another version of pre_disable_primary for those. Also toss in some FIXMEs in the hope that someone will eventually clean up this pre_disable_primary mess. Signed-off-by:
-
Ville Syrjälä authored
commit 92826fcd ("drm/i915: Calculate watermark related members in the crtc_state, v4.") broke thigns by removing the pre vs. post wm update distinction. We also lost the pre plane wm update entirely for VLV/CHV from the crtc enable path. This caused underruns on modeset and plane enable/disable on CHV, and often those can lead to a dead pipe. So let's bring back the pre vs. post thing, and let's toss in an explicit wm update to valleyview_crtc_enable() to avoid having to put it into the common code. This is more or less a partial revert of the offending commit. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 92826fcd ("drm/i915: Calculate watermark related members in the crtc_state, v4.") Signed-off-by:
-
Ville Syrjälä authored
Pass the current crtc state, not the old crtc state, to the .update_plane() hook. Noticed on BSW when PRIMSIZE was getting programmed to a stale value which produced utter garbage on screen eg. wwhen going from 1920x1080 to 1024x768. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: a758e684 ("drm/i915: Do not use commit_plane for sprite planes.") Signed-off-by:
-
Ville Syrjälä authored
This reverts commit a38c274f. PSR causes all sorts of vblank wait timeouts and whanot on CHV. Disable it again. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Fixes: a38c274f ("drm/i915: Enable PSR by default on Valleyview and Cherryview.") Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
- 09 Mar, 2016 16 commits
-
-
Ville Syrjälä authored
After the GMBUS transfer times out, we set force_bit=1 and return -EAGAIN expecting the i2c core to call the .master_xfer hook again so that we will retry the same transfer via bit-banging. This is in case the gmbus hardware is somehow faulty. Unfortunately we left adapter->retries to 0, meaning the i2c core didn't actually do the retry. Let's tell the core we want one retry when we return -EAGAIN. Note that i2c-algo-bit also uses this retry count for some internal retries, so we'll end up increasing those a bit as well. Cc: Jani Nikula <jani.nikula@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: bffce907 ("drm/i915: abstract i2c bit banging fallback in gmbus xfer") Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Ander Conselvan de Oliveira authored
Include DPLL0 in the managed dplls for SKL/KBL. While it has to be kept enabled because of it driving CDCLK, it is better to special case that inside the DPLL code than in the higher level. v2: Use INTEL_DPLL_ALWAYS_ON flag. (Ander) v3: Remove extremely paranoid WARN_ONs. (Maarten) Handle DPLL0 in skylake_get_ddi_pll() properly. (Ander) Signed-off-by:Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
-
Ander Conselvan de Oliveira authored
Manage the LCPLLs used with DisplayPort, so that all the HSW/BDW DPLLs are managed by the shared dpll code. v2: Introduce INTEL_DPLL_ALWAYS_ON flag to please state checker. (Ander) v3: Initialize pll->flags in intel_shared_dpll_init(). (Ander) Signed-off-by:
-
Ander Conselvan de Oliveira authored
Move the code for configurating BXT plls into the shared dpll code, so that the platform specific details are hidden behind that interface. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Move the code for selecting plls for SKL/KLB into the shared dpll code, so that the platform specific details are hidden behind that interface. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Move the code for selecting and configuring HSW/BDW DDI PLLs into the shared dpll infrastructure. With this most of the PLL selection logic for those platforms is in one place. DisplayPort is handled separately, but that should be fixed on a follow up patch. It also allows a small clean up of the SPLL logic. v2: Rebase. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The function intel_get_shared_dpll() had a more or less generic implementation with some platform specific checks to handle smaller differences between platforms. However, the minimalist approach forces bigger differences between platforms to be implemented outside of the shared dpll code (see the *_ddi_pll_select() functions in intel_ddi.c, for instance). This patch changes the implementation of intel_get_share_dpll() so that a completely platform specific version can be used, providing helpers to reduce code duplication. This should allow the code from the ddi pll select functions to be moved, and also make room for making more dplls managed by the shared dpll infrastructure. v2: WARN_ON(!dpll_mgr) in intel_get_shared_dpll(). (Maarten) Signed-off-by:
-
Ander Conselvan de Oliveira authored
Use a table to store the per-platform shared dpll information in one place. This way, there is no need for platform specific init funtions. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Move shared dpll function prototype together with other shared dpll definitions. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Move the declarations related to shared dplls from i915_drv.h to their own header file. The code that became the shared dpll infrastructre was first introcude in commit ee7b9f93 ("drm/i915: manage PCH PLLs separately from pipes"), hence the 2012-2016 copyright years in the new header file. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Change the type of intel_crtc_state->shared_dpll to be a pointer to a shared dpll. With this there is no need to first convert the id stored in the crtc state to a pointer in order to use it. It does introduce a bit of hassle on doing the opposite. The long term objective is to hide details about dpll ids behind the shared dpll interface. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Make the code neater by splitting the code for platforms with fixed PLL to their own functions and splitting the logic for finding a shareable or unused pll from the logic for setting it up. Signed-off-by:
-
Ander Conselvan de Oliveira authored
No functional changes. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Create the new file intel_dpll_mgr.c and move the shared dpll code to it. Follow up patches that reorganize pll handling will move more code there and tweak the interface. No functional changes. Signed-off-by:
-
Maarten Lankhorst authored
The raw watermark values are needed when planes are not part of the state, but this introduced a regression and possibly an overflow when merging the watermarks because invalid values may end up used. Solve this by calculating raw watermarks for all levels, and only setting non-zero values when the level is valid. Fixes the SNB warning: WARNING: CPU: 1 PID: 25405 at drivers/gpu/drm/i915/intel_pm.c:2580 ilk_program_watermarks+0x7b2/0x9d0 [i915]() WARN_ON(wm_lp != 1) Modules linked in: i915 drm_kms_helper drm bluetooth fuse iTCO_wdt iTCO_vendor_support syscopyarea sysfillrect sysimgblt fb_sys_fops tpm_tis mei_me e1000e snd_hda_codec_hdmi pcspkr tpm mei i2c_i801 lpc_ich snd_hda_codec snd_hda_core CPU: 1 PID: 25405 Comm: kms_universal_p Tainted: G U W 4.5.0-rc6apollolake+ #462 Hardware name: /DH67GD, BIOS BLH6710H.86A.0160.2012.1204.1156 12/04/2012 0000000000000000 ffff88009d42b918 ffffffff8143cfab ffff88009d42b960 ffffffffa0363580 ffff88009d42b950 ffffffff81082746 ffff8800b9a24928 ffff88009d42ba00 ffff88009d4a0000 0000000000000000 ffff88009d42ba6c Call Trace: [<ffffffff8143cfab>] dump_stack+0x4d/0x72 [<ffffffff81082746>] warn_slowpath_common+0x86/0xc0 [<ffffffff810827cc>] warn_slowpath_fmt+0x4c/0x50 [<ffffffffa0292862>] ilk_program_watermarks+0x7b2/0x9d0 [i915] [<ffffffffa0292cb7>] ilk_initial_watermarks+0x107/0x120 [i915] [<ffffffffa02feffa>] intel_pre_plane_update+0x12a/0x190 [i915] [<ffffffffa02ffb36>] intel_atomic_commit+0x546/0xd50 [i915] [<ffffffffa012c9e7>] drm_atomic_commit+0x37/0x60 [drm] [<ffffffffa0217361>] drm_atomic_helper_disable_plane+0xb1/0xf0 [drm_kms_helper] [<ffffffffa011cdb4>] __setplane_internal+0x184/0x280 [drm] [<ffffffffa012b57a>] ? drm_modeset_lock_all_ctx+0x9a/0xb0 [drm] [<ffffffffa012010f>] drm_mode_setplane+0x13f/0x1c0 [drm] [<ffffffffa0111b52>] drm_ioctl+0x142/0x590 [drm] [<ffffffffa011ffd0>] ? drm_plane_check_pixel_format+0x50/0x50 [drm] [<ffffffff811f2744>] ? mntput+0x24/0x40 [<ffffffff811d28d4>] ? __fput+0x194/0x200 [<ffffffffa012dec3>] drm_compat_ioctl+0x33/0x40 [drm] [<ffffffffa029e1c2>] i915_compat_ioctl+0x32/0x40 [i915] [<ffffffff81228d72>] compat_SyS_ioctl+0xc2/0x330 [<ffffffff810021d5>] ? exit_to_usermode_loop+0x95/0xb0 [<ffffffff81002d2e>] do_fast_syscall_32+0x9e/0x210 [<ffffffff8197faf2>] entry_SYSENTER_compat+0x52/0x70 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Testcase: kms_universal_plane Fixes: d81f04c5 ("drm/i915: Allow preservation of watermarks, v2.") Signed-off-by: -
Jani Nikula authored
The DSI power domain was missing from BXT power well 1 definitions, failing to get the power well for DSI transcoders. As pipe A is in the same power well as DSI transcoders, the problem should only occur with pipes B and C. According to Ville, this is basically a nop since pw1 is under dmc control. But given that we still have this stuff defined here, it's clearly correct to include DSI here. Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Deepak M <m.deepak@intel.com> Reviewed-by:
-
- 07 Mar, 2016 2 commits
-
-
Takashi Iwai authored
The recent commit [0bdf5a05: drm/i915: Add reverse mapping between port and intel_encoder] introduced a reverse mapping to retrieve intel_dig_port object from the port number. The code assumed that the port vs intel_dig_port are 1:1 mapping. But in reality, this was a too naive assumption. As Martin reported about the missing HDMI audio on his SNB machine, pre-HSW chips may have multiple intel_dig_port objects corresponding to the same port. Since we assign the mapping statically at the init time and the multiple objects override the map, it may not match with the actually enabled output. This patch tries to address the regression above. The reverse mapping is provided basically only for the audio callbacks, so now we set / clear the mapping dynamically at enabling and disabling HDMI/DP audio, so that we can always track the latest and correct object corresponding to the given port. Fixes: 0bdf5a05 ('drm/i915: Add reverse mapping between port and intel_encoder') Reported-and-tested-by:
Martin Kepplinger <martink@posteo.de> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Imre Deak authored
In commit 1e657ad7 we moved the last step of firmware initialization to skl_display_core_init(), where it will be run only during system resume, but not during driver loading. Since this init step needs to be done whenever we program the firmware fix this by moving the initialization to the end of intel_csr_load_program(). While at it simplify a bit csr_load_work_fn(). This issue prevented DC5/6 transitions, this change will re-enable those. v2: - remove debugging left-over and redundant comment in csr_load_work_fn() Fixes: 1e657ad7 ("drm/i915/gen9: Write dc state debugmask bits only once") CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457121461-16729-1-git-send-email-imre.deak@intel.com
-
- 04 Mar, 2016 8 commits
-
-
Mika Kuoppala authored
With full-ppgtt, it takes the GPU an eon to traverse the entire 256PiB address space, causing a loop to be detected. Under the current scheme, if ACTHD walks off the end of a batch buffer and into an empty address space, we "never" detect the hang. If we always increment the score as the ACTHD is progressing then we will eventually timeout (after ~46.5s (31 * 1.5s) without advancing onto a new batch). To counter act this, increase the amount we reduce the score for good batches, so that only a series of almost-bad batches trigger a full reset. DoS detection suffers slightly but series of long running shader tests will benefit. Based on a patch from Chris Wilson. Testcase: igt/drv_hangman/hangcheck-unterminated Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1456930109-21532-1-git-send-email-mika.kuoppala@intel.com
-
Tomas Elf authored
GPU engine reset handshaking is something that is applicable to both full GPU reset and engine reset, which is something that is part of the upcoming TDR per-engine hang recovery patches. Break out the common engine reset request/unrequest code (originally written by Mika Kuoppala) for reuse later in the TDR enablement patch series. v2: correct indentation and drop unused returned value (Mika) v3: We have forcewake during reset so use *_FW reg access (Mika) Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
Tomas Elf <tomas.elf@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
Arun Siluvery <arun.siluvery@linux.intel.com> [Mika: Fixed format warning] Signed-off-by:
-
Ville Syrjälä authored
Supposedly we would want to get the PWM output as close as possible to the target, so let's round to closest. Cc: Jani Nikula <jani.nikula@linux.intel.com> Suggested-by:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Now that the mess with AUX clock divder rounding is sorted out and we have both cdclk and rawclk cached in dev_priv, we can clean up the .get_aux_clock_divider() functions a bit. The main thing here is just calling ilk_get_aux_clock_divider() from hsw_get_aux_clock_divider() except for the LPT:H special case. We could go further and call g4x_get_aux_clock_divider() from ilk_get_aux_clock_divider() for the PCH ports, but I'm sure Jani would object, so leave that be. While at it repeat the comment where the AUX clock comes from in ilk_get_aux_clock_divider(). Signed-off-by:
-
Ville Syrjälä authored
Currently we assume that hrawclk is 200MHz on VLV/CHV. That should be true always, but just to avoid such asumptions we can read out the actual frequency from CCK. Signed-off-by:
-
Ville Syrjälä authored
With the hrawclk frequency cached in dev_priv, we can simply use g4x_get_aux_clock_divider() for VLV/CHV. v2: Rebase due to IS_VALLYVIEW vs. IS_CHERRYVIEW split Signed-off-by:
-
Ville Syrjälä authored
g4x is the first platform with DP support, so let's name the relevant functions as g4x_ instead i9xx_ to avoid confusion. Signed-off-by:
-
Ville Syrjälä authored
Generalize rawclk handling by storing it in dev_priv. Presumably our hrawclk readout works at least for CTG and ELK since we've been using it for DP AUX on those platforms. There are no real docs anymore after configdb vanished, so the only reference is the public CTG GMCH spec. What bits are listed in that doc match our code. The ELK GMCH spec have no relevant details unfortunately. The PNV situation is less clear. Starting from commit aa17cdb4 ("drm/i915: initialize backlight max from VBT") we assume that the CTG/ELK hrawclk readout works for PNV as well. At least the results *seem* reasonable for one PNV machine (Lenovo Ideapad S10-3t). Sadly the PNV GMCH spec doesn't have the goods on the relevant register either. So let's keep assuming it works for PNV,ELK,CTG and read it out on those platforms. G33 also has hrawclk according to some notes in BSpec, but we don't actually need it for anything, so let's not even try to read it out there. v2: Rebase due to IS_VALLYVIEW vs. IS_CHERRYVIEW split Use KHz() all over, and kill off a few useless temp variables Signed-off-by:
-
- 03 Mar, 2016 8 commits
-
-
Tvrtko Ursulin authored
Looks like this code does not need to wait atomically since it otherwise takes the mutex. Signed-off-by:
-
Tvrtko Ursulin authored
Currently the wait_for_atomic_us only allows for a jiffie timeout granularity which is not nice towards callers requesting small micro-second timeouts. Re-implement it so micro-second timeout granularity is really supported and not just in the name of the macro. This has another beneficial side effect that it improves "gem_latency -n 100" results by approximately 2.5% (throughput and latencies) and 3% (CPU usage). (Note this improvement is relative to not yet merged execlist lock uncontention patch which moves the CSB MMIO outside this lock.) It also shrinks some hot functions like fw_domains_get by a tiny 3%. v2: * Warn when used from non-atomic context (if possible). * Warn on too long atomic waits. v3: * Added comment explaining CONFIG_PREEMPT_COUNT. * Fixed pre-processor indentation. (Chris Wilson) v4: * Commit msg update (gem_latency) and rebase. v5: * Commit message re-wording. * Added comment about no need for double cond check. (Chris Wilson) Signed-off-by:
-
Tvrtko Ursulin authored
v2: Added a submenu based on an idea by Chris Wilson. Signed-off-by:
-
Tvrtko Ursulin authored
I do not see that this needs to be done atomically and up to one second is quite a long time to busy loop. Signed-off-by:
-
Tvrtko Ursulin authored
This is for callers who want micro-second precision but are not waiting from the atomic context. v2: * Fix atomic waits. (Dave Gordon) * Use USEC_PER_SEC and USEC_PER_MSEC. (Chris Wilson) Signed-off-by:
-
Deepak M authored
The MIPI clock calculations for the addtional clock are revised from B0 stepping onwards, the bit definitions have changed compared to old stepping. v2: Fixing compilation warning. v3: Retained the old Macros (Jani) Signed-off-by:
Deepak M <m.deepak@intel.com> Tested-by: Ramalingam C <ramalingam.c@intel.com> # BXT-T with Tianma panel Signed-off-by:
-
Maarten Lankhorst authored
Only planes that are part of the state should be used for recalculating watermarks. For planes not part of the state the previous patch allows us to re-use the old values since they're calculated even for levels that are not actively used. Changes since v1: - Remove big if from intel_crtc_atomic_check. - Remove extra newline. - Remove memset in ilk_compute_pipe_wm. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com>
-
Maarten Lankhorst authored
As Paulo has noted we can help bisectability by separating computing watermarks on a noop in 2 separate commits. This patch no longer clears the crtc watermark state, but recalculates it completely. Regardless whether a level is used the full values for each level are calculated. If a level is invalid wm[level].enable is unset. Changes since v1: - Only call ilk_validate_wm_level when level <= usable_level. (Ville) Signed-off-by:
-
