| Age | Commit message (Collapse) | Author |
|---|
|
commit a19440304db2d97aed5cee9bfa5017c98d2348bf upstream.
When a view destruction command was present in the command stream, the
view was validated to avoid a device error. That caused excessive and
unnecessary validations of views, surfaces and mobs on view destruction.
Replace this with a new relocation type that patches the view
destruction command to a NOP if the view is not present in the device
after the execbuf validation sequence.
Also add checks for the member size of the vmw_res_relocation struct.
Fixes sporadic command submission errors on google-earth exit.
Reported-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 86c7e6836479c4045a9a81ed5ea76c51d719f9c1 upstream.
A workaround for a warning introduced a use of the NO_IRQ
macro that should have been gone for a long time.
It is clear from the code that the value cannot actually
be used, but apparently there was a configuration at
some point that caused a warning, so instead of just
reverting that patch, this rearranges the code in a way that
the warning cannot reappear.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 6ef41cf6f721 ("dmaengine :ipu: change ipu_irq_handler() to remove compile warning")
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0610735928ee47870e083d5901caa371089216f1 upstream.
bq->charger is initialized in bq24257_power_supply_init.
Therefore, bq24257_power_supply_init should be called before the
registration of the IRQ handler bq24257_irq_handler_thread that calls
power_supply_changed(bq->charger).
Signed-off-by: Georges Savoundararadj <savoundg@gmail.com>
Cc: Aurelien Chanot <chanot.a@gmail.com>
Cc: Andreas Dannenberg <dannenberg@ti.com>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Fixes: 2219a935963e ("power_supply: Add TI BQ24257 charger driver")
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7055a29471eebf4b62687944694222635ed44b09 upstream.
Fix multicast flow rule leak on adding unicast rule failure.
Fixes: 038d2ef87572 ('IB/mlx5: Add flow steering support')
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 84b3adc2430eafd2eb703570075c3c141ea0ff13 upstream.
There is no need to have a global qpt_mask as that does not support the
multiple chip model which qib has. Instead rely on the value which
exists already in the device data (dd).
Fixes: 898fa52b4ac3 "IB/qib: Remove qpn, qp tables and related variables from qib"
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit eefa1d8961584c5b76afded94960ca4344bc638b upstream.
The __must_hold() is sufficent to correct the sparse
context imbalance inside a function.
Per Documentation/sparse.txt:
__must_hold - The specified lock is held on function entry and exit.
Fixes: Commit c0a67f6ba356 ("IB/rdmavt: Annotate rvt_reset_qp()")
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5a648dfad033bf5f945795c4e56ee7577f24f3e9 upstream.
The call is misplaced in the reset calldown function
and causes issues with lockdep assertions that are to
be added.
Fixes: Commit a2c2d608957c ("staging/rdma/hfi1: Remove create_qp functionality")
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9afe11e956766eaac4643adaaf49f223dd536c92 upstream.
Private functions in ks_hostif.c can be declared static.
Fixes: 13a9930d15b4 ("staging: ks7010: add driver from Nanonote extra-repository")
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Reviewed-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9d29f14db1095f52ca00b8162b242d6fce07d19f upstream.
wait_for_completion_interruptible_timeout return 0 on timeout and
-ERESTARTSYS if interrupted. The check for
!wait_for_completion_interruptible_timeout() would report an interrupt
as timeout. Further, while HZ/50 will work most of the time it could
fail for HZ < 50, so this is switched to msecs_to_jiffies(20).
Fixes: 13a9930d15b4 ("staging: ks7010: add driver from Nanonote extra-repository")
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1335a9516d3d52f157ad87456efdd8dc9ae1747b upstream.
Commit fadbe0cd5292851608e2e01b91d9295fa287b9fe ("staging: rtl8188eu:
Remove rtw_zmalloc(), wrapper for kzalloc()") changed all allocation
calls to be GFP_KERNEL even though the original wrapper was testing
to determine if the caller was in atomic mode. Most of the mistakes
were corrected with commit 33dc85c3c667209c930b2dac5ccbc2a365e06b7a
("staging: r8188eu: Fix scheduling while atomic error introduced in
commit fadbe0cd"); however, two kzalloc calls were missed as the
call only happens when the driver is shutting down.
Fixes: fadbe0cd5292851608e2e01b91d9295fa287b9fe ("staging: rtl8188eu: Remove rtw_zmalloc(), wrapper for kzalloc()")
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: navin patidar <navin.patidar@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 992f961480d23e9ef9e686e512a419efef723523 upstream.
Commit 6fba39cf32a3 ("staging: sm750fb: use BIT macro for
PANEL_DISPLAY_CTRL single-bit fields") accidentally changed the
CLOCK_PHASE logic from '|=' to '=' which clears all the previously set
bits.
Fixes: 6fba39cf32a3 ("staging: sm750fb: use BIT macro for PANEL_DISPLAY_CTRL single-bit fields")
Signed-off-by: Phil Turnbull <phil.turnbull@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4a236d01b5e0d7e6f4ee9e6c4056fce10b38e8ad upstream.
The newly added Hi6220 Ion code fails to build when the ION_OF helpers
are not present:
drivers/staging/android/ion/hisilicon/hi6220_ion.o: In function `hi6220_ion_remove':
hi6220_ion.c:(.text.hi6220_ion_remove+0x4c): undefined reference to `ion_destroy_platform_data'
drivers/staging/android/ion/hisilicon/hi6220_ion.o: In function `hi6220_ion_probe':
hi6220_ion.c:(.text.hi6220_ion_probe+0x5c): undefined reference to `ion_parse_dt'
hi6220_ion.c:(.text.hi6220_ion_probe+0xf8): undefined reference to `ion_destroy_platform_data'
This selects the symbol when needed.
Fixes: 2b40182a19bc ("staging: android: ion: Add ion driver for Hi6220 SoC platform")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Laura Abbott <labbott@redhat.com>
Reviewed-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 281269f8a0b00f5c95de5158e8595ed51bdb4b0a upstream.
It is likely that checking the result of 'pm_runtime_set_active' is
expected here.
Fixes: f0e5f57d3ac2 ("iio: light: us8152d: Add power management support")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9d47964bfd471f0dd4c89f28556aec68bffa0020 upstream.
The comparison for devnr limits is off-by-one, the current check
allows 0 to AD5755_NUM_CHANNELS and the limit should be in fact
0 to AD5755_NUM_CHANNELS - 1. This can lead to an out of bounds
write to pdata->dac[devnr]. Fix this by replacing > with >= on the
comparison.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Fixes: c947459979c6 ("iio: ad5755: add support for dt bindings")
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ad8529fde9e3601180a839867a8ab041109aebb5 upstream.
Currently omap-rng checks the return value of pm_runtime_get_sync and
reports failure if anything is returned, however it should be checking
if ret < 0 as pm_runtime_get_sync return 0 on success but also can return
1 if the device was already active which is not a failure case. Only
values < 0 are actual failures.
Fixes: 61dc0a446e5d ("hwrng: omap - Fix assumption that runtime_get_sync will always succeed")
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7514e3688811e610640ec2201ca14dfebfe13442 upstream.
Fix the retrn value check which testing the wrong variable
in ccp_dmaengine_register().
Fixes: 58ea8abf4904 ("crypto: ccp - Register the CCP as a DMA resource")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Gary R Hook <gary.hook@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 09951d83fc58a6f772de09c08e370f6d9970dbb6 upstream.
So far, sub part of mv_cesa_int was responsible of dequeuing complete
requests, then call the 'cleanup' operation on these reqs and call the
crypto api callback 'complete'. The problem is that the transformation
context 'ctx' is retrieved only once before the while loop. Which means
that the wrong 'cleanup' operation might be called on the wrong type of
cesa requests, it can lead to memory corruptions with this message:
marvell-cesa f1090000.crypto: dma_pool_free cesa_padding, 5a5a5a5a/5a5a5a5a (bad dma)
This commit fixes the issue, by updating the transformation context for
each dequeued cesa request.
Fixes: commit 85030c5168f1 ("crypto: marvell - Add support for chai...")
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 57cfda1ac74e58767f6305bd1ea3449177425460 upstream.
Currently, in mv_cesa_{md5,sha1,sha256}_init creq->state is initialized
before the call to mv_cesa_ahash_init. This is wrong because this
function fills creq with zero by using memset, so its 'state' that
contains the default DIGEST is overwritten. This commit fixes the issue
by initializing creq->state just after the call to mv_cesa_ahash_init.
Fixes: commit b0ef51067cb4 ("crypto: marvell/cesa - initialize hash...")
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 18f53fe0f30331e826b075709ed7b26b9283235e upstream.
commit 7a0adc83f34d ("ath10k: improve tx scheduling") is causing
severe throughput drop in multi client mode. This issue is originally
reported in veriwave setup with 50 clients with TCP downlink traffic.
While increasing number of clients, the average throughput drops
gradually. With 50 clients, the combined peak throughput is decreased
to 98 Mbps whereas reverting given commit restored it to 550 Mbps.
Processing txqs for every tx completion is causing overhead. Ideally for
management frame tx completion, pending txqs processing can be avoided.
The change partly reverts the commit "ath10k: improve tx scheduling".
Processing pending txqs after all skbs tx completion will yeild enough
room to burst tx frames.
Fixes: 7a0adc83f34d ("ath10k: improve tx scheduling")
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 77eb3d693182b4eaa88c6ba406fbb92b1f1bd636 upstream.
When user requests for survey dump data, driver is providing wrong survey
information. This information we sent is the survey data that we have
collected during previous user request.
This issue occurs because we request survey dump for wrong channel. With
this change, we correctly display the correct and current survey
information to userspace.
Fixes: fa7937e3d5c2 ("ath10k: update bss channel survey information")
Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e4fd726f21cdae0dc9cea6cbfcb7e27f21393f88 upstream.
In the wake tx queue path, we are not checking if the frame to be sent
takes management path or not. For eg. QOS null func frame coming here will
take the management path. Since we are not incrementing the descriptor
counter (num_pending_mgmt_tx) w.r.t tx management, on tx completion it is
possible to see negative values.
When the above counter reaches a negative value, we will not be sending a
probe response out.
if (is_presp &&
ar->hw_params.max_probe_resp_desc_thres < htt->num_pending_mgmt_tx)
For IPQ4019, max_probe_resp_desc_thres (u32) is 24 is compared against
num_pending_mgmt_tx (int) and the above condtions comes true if the counter
is negative and we drop the probe response.
To avoid this, check on the wake tx queue path as well for the tx path of
the frame and increment the appropriate counters
Fixes: cac085524cf1 "ath10k: move mgmt descriptor limit handle under mgmt_tx"
Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 64ed5771aca2fcfb8ea440fc679741054011fd7e upstream.
WMI_SERVICE_PERIODIC_CHAN_STAT_SUPPORT service has missed in
the commit 7e247a9e88dc ("ath10k: add dynamic tx mode switch
config support for qca4019"). This patch adds the service to
avoid mismatch between host and target.
Fixes: 7e247a9e88dc ("ath10k: add dynamic tx mode switch config support for qca4019")
Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c8ccf3ade7851054f82bf88f5fcd393a394038a3 upstream.
Recent patch "mwifiex: fix NULL pointer" skips extended scan event
handling when suspend is in progress. It created a problem for scan
after interface disabled/enabled case.
This patch solves the problem by checking netif_running() status.
Fixes:16d25da94f3d654 ("mwifiex: fix NULL pointer dereference during suspend")
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b64db1b252e9974a43a51ba083fa7d03e4716167 upstream.
AID gets updated during TDLS setup, but modified value isn't reflected
in "priv->assoc_rsp_buf". This causes TDLS setup failure. The problem is
fixed here.
Fixes: 4aff53ef18e4a4 ("mwifiex: parsing aid while receiving..")
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 776b2e15f8af7900409456292efd45af6de97172 upstream.
X722 hardware requires using the admin queue to configure RSS. This
function was previously re-written in commit e69ff813af35 ("i40e: rework
the functions to configure RSS with similar parameters").
However, the previous refactor did not work correctly for a few reasons
(a) it does not check whether seed is NULL before using it, resulting in
a NULL pointer dereference
[ 402.954721] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 402.955568] IP: [<ffffffffa0090ccf>] i40e_config_rss_aq.constprop.65+0x2f/0x1c0 [i40e]
[ 402.956402] PGD ad610067 PUD accc0067 PMD 0
[ 402.957235] Oops: 0000 [#1] SMP
[ 402.958064] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_filter ebtable_
broute bridge stp llc ebtable_nat ebtables ip6table_mangle ip6table_raw ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv
6 ip6table_security ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_nat nf_conntrack_ipv4_ nf_defrag_ipv4_ nf_nat_ip
v4_ nf_nat nf_conntrack iptable_security intel_rapl i86_kg_temp_thermal coretemp kvm_intel kvm irqbypass crct10dif_clMl crc32_
pclMl ghash_clMlni_intel iTCO_wdt iTCO_vendor_support shpchp sb_edac dcdbas pcspkr joydev ipmi_devintf wmi edac_core ipmi_ssif
acpi_ad acpi_ower_meter ipmi_si ipmi_msghandler mei_me nfsd lpc_ich mei ioatdma tpm_tis auth_rpcgss tpm nfs_acl lockd grace s
unrpc ifs nngag200 i2c_algo_bit drm_kms_helper ttm drm iigbe bnx2x i40e dca mdio ptp pps_core libcrc32c fjes crc32c_intel
[ 402.965563] CPU: 22 PID: 2461 Conm: ethtool Not tainted 4.6.0-rc7_1.2-ABNidQ+ #20
[ 402.966719] Hardware name: Dell Inc. PowerEdge R720/0C4Y3R, BIOS 2.5.2 01/28/2015
[ 402.967862] task: ffff880219b51dc0 ti: ffff8800b3408000 task.ti: ffff8800b3408000
[ 402.969046] RIP: 0010:[<ffffffffa0090ccf>] [<ffffffffa0090ccf>] i40e_config_rss_aq.constprop.65+0x2f/0x1c0 [i40e]
[ 402.970339] RSP: 0018:ffff8800b340ba90 EFLAGS: 00010246
[ 402.971616] RAX: 0000000000000000 RBX: ffff88042ec14000 RCX: 0000000000000200
[ 402.972961] RDX: ffff880428eb9200 RSI: 0000000000000000 RDI: ffff88042ec14000
[ 402.974312] RBP: ffff8800b340baf8 R08: ffff880237ada8f0 R09: ffff880428eb9200
[ 402.975709] R10: ffff880428eb9200 R11: 0000000000000000 R12: ffff88042ec2e000
[ 402.977104] R13: ffff88042ec2e000 R14: ffff88042ec14000 R15: ffff88022ea00800
[ 402.978541] FS: 00007f84fd054700(0000) GS:ffff880237ac0000(0000) knlGS:0000000000000000
[ 402.980003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 402.981508] CR2: 0000000000000000 CR3: 000000003289e000 CR4: 00000000000406e0
[ 402.983028] Stack:
[ 402.984578] 0000000002000200 0000000000000000 ffff88023ffeda68 ffff88023ffef000
[ 402.986187] 0000000000000268 ffff8800b340bbf8 ffff88023ffedd80 0000000088ce4f1d
[ 402.987844] ffff88042ec14000 ffff88022ea00800 ffff88042ec2e000 ffff88042ec14000
[ 402.989509] Call Trace:
[ 402.991200] [<ffffffffa009636f>] i40e_config_rss+0x11f/0x1c0 [i40e]
[ 402.992924] [<ffffffffa00a1ae0>] i40e_set_rifh+0ic0/0x130 [i40e]
[ 402.994684] [<ffffffff816d54b7>] ethtool_set_rifh+0x1f7/0x300
[ 402.996446] [<ffffffff8136d02b>] ? cred_has_capability+0io6b/0x100
[ 402.998203] [<ffffffff8136d102>] ? selinux_capable+0x12/0x20
[ 402.999968] [<ffffffff8136277b>] ? security_capable+0x4b/0x70
[ 403.001707] [<ffffffff816d6da3>] dev_ethtool+0x1423/0x2290
[ 403.003461] [<ffffffff816eab41>] dev_ioctl+0x191/0io630
[ 403.005186] [<ffffffff811cf80a>] ? lru_cache_add+0x3a/0i80
[ 403.006942] [<ffffffff817f2a8e>] ? _raw_spin_unlock+0ie/0x20
[ 403.008691] [<ffffffff816adb95>] sock_do_ioctl+0x45/0i50
[ 403.010421] [<ffffffff816ae229>] sock_ioctl+0x209/0x2d0
[ 403.012173] [<ffffffff81262194>] do_vfs_ioctl+0u4/0io6c0
[ 403.013911] [<ffffffff81262829>] SyS_ioctl+0x79/0x90
[ 403.015710] [<ffffffff817f2e72>] entry_SYSCALL_64_fastpath+0x1a/0u4
[ 403.017500] Code: 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 89 fb 48 83 ec 40 4c 8b a7 e0 05 00 00 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 <48> 8b 06 41 0f b7 bc 24 f2 0f 00 00 48 89 45 9c 48 8b 46 08 48
[ 403.021454] RIP [<ffffffffa0090ccf>] i40e_config_rss_aq.constprop.65+0x2f/0x1c0 [i40e]
[ 403.023395] RSP <ffff8800b340ba90>
[ 403.025271] CR2: 0000000000000000
[ 403.027169] ---[ end trace 64561b528cf61cf0 ]---
(b) it does not even bother to use the passed in *lut parameter which
defines the requested lookup table. Instead it uses its own round robin
table.
Fix these issues by re-writing it to be similar to i40e_config_rss_reg
and i40e_get_rss_aq.
Fixes: e69ff813af35 ("i40e: rework the functions to configure RSS with similar parameters", 2015-10-21)
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit be0cb0a66a1d426f7cd9b170c008725044ae147a upstream.
We shifted the locking around a bit but forgot to delete this unlock so
now it can unlock twice.
Fixes: cd3be169a5ff ('i40e: Move the mutex lock in i40e_client_unregister')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6999aeabbb703a81a204cb6f9f8f151759a99ac4 upstream.
The call sequence spi_alloc_master/spi_register_master/spi_unregister_master
is complete; it reduces the device reference count to zero, which and results
in device memory being freed. The subsequent call to spi_master_put is
unnecessary and results in an access to free memory. Drop it.
Fixes: 9298bc727385 ("spi: spi-fsl-dspi: Remove spi-bitbang")
Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit fcff03813a7c612873303037cef5ba0329850c35 upstream.
This fixes
[ 0.000000] i.MX clk 82: register failed with -17
because the name is duplicated.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Fixes: 3713e3f5e927 ("clk: imx35: define two clocks for rtc")
Acked-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4d31a2588ae37a5d0f61f4d956454e9504846aeb upstream.
The variable i contains a total number of resources (including
IORESOURCE_IRQ). However, we want the dmem_region_start to point
after the last resource of type IORESOURCE_MEM. The original behaviour
leads (very likely) to skipping several UIO mapping regions and makes
them useless. Fix this by computing dmem_region_start from the uiomem
which points to the last used UIO mapping.
Fixes: 0a0c3b5a24bd ("Add new uio device for dynamic memory allocation")
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 481e46fe7a88557b66330cbb047b25cc13eff4b9 upstream.
commit de5461970b3e9e194 ("coresight: tmc: allocating memory when needed")
removed the static allocation of buffer for the trace data in ETR mode in
tmc_probe. However it failed to remove the "devm_free_coherent" in
tmc_probe when the probe fails due to other reasons. This patch gets
rid of the incorrect dma_free_coherent() call.
Fixes: commit de5461970b3e9e194 ("coresight: tmc: allocating memory when needed")
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit babf985d1e1b0677cb264acd01319d2b9c8f4327 upstream.
Commit 704c4b0ddc03 ("cxlflash: Shutdown notify support for CXL Flash
cards") was recently introduced to notify the AFU when a system is going
down. Due to the position of the cxlflash driver in the device stack,
cxlflash devices are _always_ removed during a reboot/shutdown. This can
lead to a crash if the cxlflash shutdown hook is invoked _after_ the
shutdown hook for the owning virtual PHB. Furthermore, the current
implementation of shutdown/remove hooks for cxlflash are not tolerant to
being invoked when the device is not enabled. This can also lead to a
crash in situations where the remove hook is invoked after the device
has been removed via the vPHBs shutdown hook. An example of this
scenario would be an EEH reset failure while a reboot/shutdown is in
progress.
To solve both problems, the shutdown hook for cxlflash is updated to
simply remove the device. This path already includes the AFU
notification and thus this solution will continue to perform the
original intent. At the same time, the remove hook is updated to protect
against being called when the device is not enabled.
Fixes: 704c4b0ddc03 ("cxlflash: Shutdown notify support for CXL Flash
cards")
Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 410280bac6224e066f4cf0b87db08f0418a135b6 upstream.
We know that 'retval = 0' because it has been tested a few lines above.
So, if 'devm_kmalloc' fails, 0 will be returned instead of an error code.
Return -ENOMEM instead.
Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ca5732c53bf66ad755284786897e0dd10330de87 upstream.
We use obj->phys_handle to choose the pread/pwrite path, but as
obj->phys_handle is a union with obj->userptr, we then mistakenly use
the phys_handle path for userptr objects within pread/pwrite.
Testcase: igt/gem_userptr_blits/forbidden-operations
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97519
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-2-chris@chris-wilson.co.uk
(cherry picked from commit 5f12b80a0b42da253691ca03828033014bb786eb)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f856f847b22c52be82f712ea6ada946c6db884d7 upstream.
When we enable the per-register access mmiodebug, it is to detect which
access is illegal. Reporting on earlier untraced access outside of the
mmiodebug does not help debugging (as the suspicion is immediately put
upon the current register which is not at fault)!
References: https://bugs.freedesktop.org/show_bug.cgi?id=97985
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-1-chris@chris-wilson.co.uk
(cherry picked from commit dda960335e020835f7f1c12760e7f0b525b451e2)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 16c83fad79ca912b8b5bbdcb5272794a2be41262 upstream.
Allow returning "connected" or "unknown" connector status for DP branch
devices that don't have an EDID. Currently we'd claim the thing as
"disconnected" if there is no EDID.
This stuff used to broken already, I think, but it got more broken by
commit f21a21983ef1 ("drm/i915: Splitting intel_dp_detect")
Cc: Damien Cassou <damien@cassou.me>
Cc: freedesktop.org@gp.mailgun.org
Cc: Arno <blouin.arno@gmail.com>
Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Tested-by: Arno <blouin.arno@gmail.com>
Fixes: f21a21983ef1 ("drm/i915: Splitting intel_dp_detect")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1475481316-8194-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
(cherry picked from commit 5cb651a7959310ef4dbb0b93f005b10286789656)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1015811609c0328b5ed670d07748591b837e74eb upstream.
We can't rely on connector->status in the detect() hook if the long hpd
was already handled by the dig_port_work as that won't update
connector->status. Thus we have to defer the long hpd handling entirely
until the hotplug work runs to avoid the double long hpd handling
the "detect_done" flag is trying to prevent.
We'll start to depend on connector->status being up to date in a
following patch.
Cc: Damien Cassou <damien@cassou.me>
Cc: freedesktop.org@gp.mailgun.org
Cc: Arno <blouin.arno@gmail.com>
Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Tested-by: Arno <blouin.arno@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1475481316-8194-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
(cherry picked from commit 27d4efc5591a5853de54713bc717de73c8951e17)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a3fd4c67af3d8a81d241b3d51b3525f36f1d68bb upstream.
DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it
forbidden to set it for LVDS/CRT as well. So let's also set it on
CRT to make it possible to share the DPLL between HDMI and CRT.
What that bit apparently does is enable the x5 clock to the port,
which then pumps out the bits on both edges of the clock. The DAC
doesn't need that clock since it's not pumping out bits, but I don't
think it hurts to have the DPLL output that clock anyway.
This is fairly important on IVB since it has only two DPLLs with three
pipes. So trying to drive three or more PCH ports with three pipes
is only possible when at least one of the DPLLs gets shared between
two of the pipes.
SNB doesn't really need to do this since it has only two pipes. It could
be done to avoid enabling the second DPLL at all in certain cases, but
I'm not sure that's such a huge win. So let's not do it for SNB, at
least for now. On ILK it never makes sense as the DPLLs can't be shared.
v2: Just always enable the high speed clock to keep things simple (Daniel)
Beef up the commit message a bit (Daniel)
Cc: Nick Yamane <nick.diego@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Nick Yamane <nick.diego@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97204
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474878646-17711-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
(cherry picked from commit 7d7f8633a82763577727762ff3ac1df3017cb8fe)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 05a76d3d6ad1ee9f9814f88949cc9305fc165460 upstream.
If we're enabling a pipe, we'll need to modify the watermarks on all
active planes. Since those planes won't be added to the state on
their own, we need to add them ourselves.
Signed-off-by: Lyude <cpaul@redhat.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-6-git-send-email-cpaul@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d721b02fd00bf133580f431b82ef37f3b746dfb2 upstream.
Looks like the TSEG lives just above TOUD, stolen comes after TSEG.
The spec seems somewhat self-contradictory in places, in the ESMRAMC
register desctription it says:
TSEG Size:
10=(TOUD + 512 KB) to TOUD
11 =(TOUD + 1 MB) to TOUD
so that agrees with TSEG being at TOUD. But the example given
elsehwere in the spec says:
TOUD equals 62.5 MB = 03E7FFFFh
TSEG selected as 512 KB in size,
Graphics local memory selected as 1 MB in size
General System RAM available in system = 62.5 MB
General system RAM range00000000h to 03E7FFFFh
TSEG address range03F80000h to 03FFFFFFh
TSEG pre-allocated from03F80000h to 03FFFFFFh
Graphics local memory pre-allocated from03E80000h to 03F7FFFFh
so here we have TSEG above stolen.
Real world evidence agrees with the TOUD->TSEG->stolen order however, so
let's fix up the code to account for the TSEG size.
Cc: Taketo Kabe <fdporg@vega.pgw.jp>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Fixes: 0ad98c74e093 ("drm/i915: Determine the stolen memory base address on gen2")
Fixes: a4dff76924fe ("x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms")
Reported-by: Taketo Kabe <fdporg@vega.pgw.jp>
Tested-by: Taketo Kabe <fdporg@vega.pgw.jp>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96473
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470653919-27251-1-git-send-email-ville.syrjala@linux.intel.com
Link: http://download.intel.com/design/chipsets/datashts/25251405.pdf
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 23f889bdf6ee5cfff012d8b09f6bec920c691696 upstream.
This reverts commit 237ed86c693d8a8e4db476976aeb30df4deac74b.
Our current implementation of live status check (repeat 9 times
with 10ms delays between each attempt as a workaround for
buggy displays) imposes a rather serious penalty, time wise,
on intel_hdmi_detect(). Since we we already skip live status
checks on platforms before gen 7, and since we seem to have
coped quite well before the live status check was introduced
for newer platforms too, the previous behaviour is probably
preferable, at least unless someone can point to a use-case
that the live status check improves (apart from "Bspec says so".)
Signed-off-by: David Weinehall <david.weinehall@linux.intel.com>
Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid")
Fixes: f8d03ea0053b ("drm/i915: increase the tries for HDMI hotplug live status checking")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97139
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94014
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160817124748.31208-1-david.weinehall@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 17777d61f4a87d7b6d5585e8fdffa83773c594e7 upstream.
According to BSpec, it's the "core CPUs" that need the code, which
means SKL and KBL, but not BXT.
I don't have a KBL to test this patch on it.
v2: Only SKL should have I915_SAGV_NOT_CONTROLLED.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-4-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 6e3100ec21e7c774a0fc01e36a1e0739530c2f71)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6e7fdb873d6255ca3c999dd5c6c18962a769ed3e upstream.
And use it to move knowledge about the SAGV-supporting platforms from
the callers to the SAGV code.
We'll add more platforms to intel_has_sagv(), so IMHO it makes more
sense to move all this to a single function instead of patching all
the callers every time we add SAGV support to a new platform.
v2: Move I915_SAGV_NOT_CONTROLLED to the new function (Lyude).
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-3-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 56feca91973459d0b62cbb2610b62d341025ed89)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 674f823b455cdb94d5773406c1caac170f87e1c4 upstream.
The plan is to introduce intel_has_sagv() and then use it to discover
which platforms actually support it.
I thought about keeping the functions with their current skl names,
but found two problems: (i) skl_has_sagv() would become a very
confusing name, and (ii) intel_atomic_commit_tail() doesn't seem to be
calling any functions whose name start with a platform name, so the
"intel_" naming scheme seems make more sense than the "firstplatorm_"
naming scheme here.
Reviewed-by: Lyude <cpaul@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-2-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 16dcdc4edbcf5cb130004737f2548401776170f1)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 73fed0ef8567f1e1cba079994353e60208ded964 upstream.
We forgot the "res_blocks += y_tile_minimum" that's described on step
V of our documentation.
Again, this should only affect the Y tiling cases.
It looks like the relevant code was introduced in 0fda65680e92, but
there's always the possibility that it matched our specification when
it was introduced, and then the specification changed while the code
stayed the same. So we can't really say this was a regression, but
let's try to add a "Fixes" tag anyway to help backporting.
v2: Try to add a "Fixes" tag (Maarten).
Fixes: 0fda65680e92 ("drm/i915/skl: Update watermarks for Y tiling")
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lyude <cpaul@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-8-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 75676ed423a6acf9e2b1df52fbc036a51e11fb7a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit cf6c525a31fac11b0775b8c06c00a508c6356d9b upstream.
The confusing thing is that plane_blocks_per_line is listed as part of
the method 2 calculation but is also used for other things. We
calculated it in two different places and different ways: one inside
skl_wm_method2() and the other inside skl_compute_plane_wm(). The
skl_wm_method2() implementation is the one that matches the
specification.
With this patch we fix the skl_compute_plane_wm() calculation and just
pass it as a parameter to skl_wm_method2(). We also take care to not
modify the value of plane_bytes_per_line since we're going to rely on
it having a correct value in later patches.
This should affect the watermarks for Linear and Y-tiled.
From my analysis, it looks like the two plane_blocks_per_line
variables got out of sync on 0fda65680e92, but we can't really say
that commit was a regression, it looks like just an incomplete fix.
There's always the possibility that 0fda65680e92 matched our
specification at that time, and then later the specification changed.
v2: Try to add a "Fixes" tag (Maarten).
Fixes: 0fda65680e92 ("drm/i915/skl: Update watermarks for Y tiling")
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lyude <cpaul@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-7-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 7a1a8aed67e0a60772defe3f6499eb340da48634)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ccc1057477bc99678896b51adce6b6ee4019dc37 upstream.
During watermarks calculations, this value is used in 3 different
places. Only one of them was not using a hardcoded 4. Move the code up
so everybody can benefit from the actual value.
This should only help on situations with Y tiling + 90/270 rotation +
1 or 2 bpp or NV12.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-6-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 1186fa85eb9b3cc0589990fbc39617e50e38759a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4e4d3814a9bb4d71cd3ff0701d8d7041edefd8f0 upstream.
Bspec says:
"The mailbox response data may not account for memory read latency.
If the mailbox response data for level 0 is 0us, add 2 microseconds
to the result for each valid level."
This means we should only do the +2 in case wm[0] == 0, not always.
So split the sanitizing implementation from the WA implementation and
fix the WA implementation.
v2: Add Fixes tag (Maarten).
Fixes: 367294be7c25 ("drm/i915/gen9: Add 2us read latency to WM level")
Cc: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-5-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 0727e40a48a1d08cf54ce2c01e120864b92e59bf)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit be5c571b2ff3a164d2e14ccc100cb5b2b3d3fb7c upstream.
We were previously adding all the planes owned by the CRTC even when
the ddb partitioning didn't change for them. As a consequence, a lot
of functions were being called when we were just moving the cursor
around the screen, such as skylake_update_primary_plane().
This was causing flickering on the primary plane when moving the
cursor. I'm not 100% sure which operation caused the flickering, but
we were writing to a lot of registers, so it could be any of these
writes. With this patch, just moving the mouse won't add the primary
plane to the commit since it won't trigger a change in DDB
partitioning.
v2: Use skl_ddb_entry_equal() (Lyude).
v3: Change Reported-and-bisected-by: to Reported-by: for checkpatch
Fixes: 05a76d3d6ad1 ("drm/i915/skl: Ensure pipes with changed wms get added to the state")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97888
Cc: Mike Lothian <mike@fireburn.co.uk>
Reported-by: Mike Lothian <mike@fireburn.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Lyude <cpaul@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1475177808-29955-1-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 7f60e200e254cd53ad1bd74a56bdd23e813ac4b7)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ccebc23b57c313229526dc76383ce82f5e0b9001 upstream.
i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks. And if the watermarks hasn't changed then we
haven't populated skl_results with anything, which means we'll end up
zeroing out a plane's watermarks in the middle of the atomic commit
without restoring them later.
Simple reproduction recipe:
- Get a SKL laptop, launch any kind of X session
- Get two extra monitors
- Keep hotplugging both displays (so that the display configuration
jumps from 1 active pipe to 3 active pipes and back)
- Eventually underrun
Changes since v1:
- Fix incorrect use of "it's"
Changes since v2:
- Add reproduction recipe
Signed-off-by: Lyude <cpaul@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 62e0fb880123 ("drm/i915/skl: Update plane watermarks atomically during plane updates")
Signed-off-by: Lyude <cpaul@redhat.com>
Testcase: kms_plane
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1472488288-27280-1-git-send-email-cpaul@redhat.com
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 27082493e9c6371b05370a619ab9d2877c5f4726 upstream.
Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.
The first major change in this patch is skl_update_crtcs(), which
handles ensuring that we order each CRTC update in our atomic commits
properly so that they honor the DDB flush order.
The second major change in this patch is the order in which we flush the
pipes. While the previous order may have worked, it can't be used in
this approach since it no longer will do the right thing. For example,
using the old ddb flush order:
We have pipes A, B, and C enabled, and we're disabling C. Initial ddb
allocation looks like this:
| A | B |xxxxxxx|
Since we're performing the ddb updates after performing any CRTC
disablements in intel_atomic_commit_tail(), the space to the right of
pipe B is unallocated.
1. Flush pipes with new allocation contained into old space. None
apply, so we skip this
2. Flush pipes having their allocation reduced, but overlapping with a
previous allocation. None apply, so we also skip this
3. Flush pipes that got more space allocated. This applies to A and B,
giving us the following update order: A, B
This is wrong, since updating pipe A first will cause it to overlap with
B and potentially burst into flames. Our new order (see the code
comments for details) would update the pipes in the proper order: B, A.
As well, we calculate the order for each DDB update during the check
phase, and reference it later in the commit phase when we hit
skl_update_crtcs().
This long overdue patch fixes the rest of the underruns on Skylake.
Changes since v1:
- Add skl_ddb_entry_write() for cursor into skl_write_cursor_wm()
Changes since v2:
- Use the method for updating CRTCs that Ville suggested
- In skl_update_wm(), only copy the watermarks for the crtc that was
passed to us
Changes since v3:
- Small comment fix in skl_ddb_allocation_overlaps()
Changes since v4:
- Remove the second loop in intel_update_crtcs() and use Ville's
suggestion for updating the ddb allocations in the right order
- Get rid of the second loop and just use the ddb state as it updates
to determine what order to update everything in (thanks for the
suggestion Ville)
- Simplify skl_ddb_allocation_overlaps()
- Split actual overlap checking into it's own helper
Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
[omitting CC for stable, since this patch will need to be changed for
such backports first]
Testcase: kms_cursor_legacy
Testcase: plane-all-modeset-transition
Signed-off-by: Lyude <cpaul@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471961565-28540-2-git-send-email-cpaul@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
Thomas Hellstrom
Arnd Bergmann
Georges Savoundararadj
Maor Gottlieb
Dennis Dalessandro
Mike Marciniszyn
Nicholas Mc Guire
Larry Finger
Phil Turnbull
Christophe JAILLET
Colin Ian King
Dave Gerlach
Wei Yongjun
Romain Perier
Rajkumar Manoharan
Ashok Raj Nagarajan
Tamizh chelvam
Amitkumar Karwar
Xinming Hu
Jacob Keller
Dan Carpenter
Wei Yongjun
Uwe Kleine-König
Jan Viktorin
Suzuki K Poulose
Uma Krishnan
Chris Wilson
Ville Syrjälä
Lyude
David Weinehall
Paulo Zanoni