Age | Commit message (Collapse) | Author |
|
<Change Type>: FR(Feature Request)
<<< Test Notes >>>
<Test-Proposal>:
1)BT function(power on/restart/connect/disconnect/iop)
2)BT BR/EDR gamepad wakeup function
3)BT BLE gamepad wakeup function
<Stress-Test>: Y
|
|
500k uNits * 65k max brightness range overflows in the conversion code.
Scale back brightness range to 12bit max.
|
|
This reverts commit f1f63fbd6a31efad6165f4b35b20ba65f25f877b.
|
|
(cherry picked from commit 36301114e8a32e7f13985cbbeff7282d4c599aed)
|
|
amdgpu_dm_plane_set_color_properties
Pure luck we didn't run into this before.
Could be a newly allocated dc_plane_state.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
|
|
This was done on the new copy rather the old one, so it was never actually duplicating any of this state.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
|
|
Signed-off-by: Joshua Ashton <joshua@froggi.es>
|
|
Otherwise we can end up with a frame on unsuspend where color management
is not applied when userspace has not committed themselves.
Fixes re-applying color management on Steam Deck/Gamescope on S3 resume.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
|
|
We are seeing below error randomly in one MSI case:
kernel: ath11k_pci 0000:03:00.0: wmi command 16387 timeout
The reason is, currently, in ath11k_pcic_ext_irq_enable(),
ATH11K_FLAG_EXT_IRQ_ENABLED is set before NAPI is enabled,
this results in a race condition: after
ATH11K_FLAG_EXT_IRQ_ENABLED is set but before NAPI enabled,
CE interrupt breaks in, in one MSI case, since IRQ is shared,
ath11k_pcic_ext_interrupt_handler() is called where IRQ is
disabled. Because NAPI is not enaled at that time, it is
not scheduled, meaning ath11k_pcic_ext_grp_napi_poll() will
not be called at last, so we have no chance to enable IRQ
and finally get above error.
Fix it by setting ATH11K_FLAG_EXT_IRQ_ENABLED after all
NAPI and IRQ work are done.
Signed-off-by: cnssbldsw <cnssbldsw@qualcomm.com>
|
|
[Why]
Currently, we are adding various common modes to drm_connector for DP
and eDP connection even if they aren't part of EDID. This results in
unsupported modes getting added to eDP connector.
[How]
Add common modes to drm_connector only for DP connection.
Signed-off-by: Swapnil Patel <swapnil.patel@amd.com>
|
|
|
|
This reverts commit 3bcc6695165be2fee1e2a2b0216b890348436ac3.
Reverting debugging commits
|
|
mhi_intvec_threaded_handler"
This reverts commit 4cb8ca7274de547cfa8f3bb42e4a0164a91de952.
Reverting debugging commits~
|
|
Firmwares advertising the support of triggering 11d algorithm on the
scan results of a regular scan expects driver to send
WMI_11D_SCAN_START_CMDID before sending WMI_START_SCAN_CMDID.
Triggering 11d algorithm on the scan results of a normal scan helps
in completely avoiding a separate 11d scan for determining regdomain.
This indirectly helps in speeding up connections on station
interfaces on the chipsets supporting 11D scan.
To enable this feature, send WMI_11D_SCAN_START_CMDID just before
sending WMI_START_SCAN_CMDID if the firmware advertises
WMI_TLV_SERVICE_SUPPORT_11D_FOR_HOST_SCAN service flag.
WCN6750 & WCN6855 supports this feature.
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-01160-QCAMSLSWPLZ-1
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230315161817.29627-1-quic_mpubbise@quicinc.com
|
|
This reverts commit 047982b7295b07ed26fd877d5cdec203d018cb01.
|
|
porch time
Changing refresh rates on OLED displays works differently to typical
LCD panels in that instead of changing the clock, the vertical porch
is extended significantly for lower rates.
This can mean that the vertical porch can be incredibly large for
non-base refresh rates eg. 60Hz on a 90Hz display.
This isn't an issue for X11/typical compositors as their present slop
is 1/2th of the refresh interval so the issue never manifests.
However in Gamescope, the present slop very small and tuned to be
optimal in real-time to try and reduce display latency significantly.
This results in us queueing up the atomic commit inside the vertical
porch region which, due to legacy X11/sync control reasons, means that
AMDGPU must target the next vblank.
This patch changes that behaviour to make FRR displays match what occurs
on VRR/Freesync displays where the vertical porch time is not included
in determining what vblank to target and solves the issue.
This means that smarter compositors can get large input latency
reductions when using OLED displays at lower than base refresh rates.
For upstreaming this patch, it will need to be considered what the best
solution is to enable this behaviour from the userspace side.
Obviously the X11/legacy stuff probably cannot change here -- so we
either need to enable this new behaviour globally for all DRM atomic
clients (ie. basically Wayland compositors) or have a
new DRM_MODE_ATOMIC flag.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
|
|
|
|
|
|
The CSIB command pocket was sent to GFX block while amdgpu driver
loading or S3 resuming time.
PREAMBLE_CNTL packet coming in the ring after PG event where the RLC
already sent its copy of CSIB, send another CSIB pocket will cause
Gfx IB testing timeout when system resume from S3.
And ME FW is jumping to the next Program Stream from the ring that is IB1.
when the INDIRCET_BUFFER packet comes from the test PFP jumps to IB1, but
ME was already in IB1 and jumps to IB2. So they are not aligned anymore.
Driver change is only sending PREAMBLE_CNTL packet once at booting time.
no need to send it during S3 resume.
Error dmesg log:
amdgpu 0000:04:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on gfx_0.0.0 (-110).
[drm:amdgpu_device_delayed_init_work_handler [amdgpu]] *ERROR* ib ring test failed (-110).
PM: resume of devices complete after 2373.995 msecs
PM: Finishing wakeup.
Signed-off-by: Perry Yuan <perry.yuan@amd.com>
|
|
Signed-off-by: Perry Yuan <perry.yuan@amd.com>
|
|
|
|
|
|
Peer rx_tid is locally copied thrice during peer_rx_tid_cleanup to
send REO_CMD_UPDATE_RX_QUEUE followed by REO_CMD_FLUSH_CACHE to flush
all aged REO descriptors from HW cache.
When sending REO_CMD_FLUSH_CACHE fails, we do dma unmap of already
mapped rx_tid->vaddr and free it. This is not checked during
reo_cmd_list_cleanup() and dp_reo_cmd_free() before trying to free and
unmap again.
Fix this by setting rx_tid->vaddr NULL in rx tid delete and also
wherever freeing it to check in reo_cmd_list_cleanup() and
reo_cmd_free() before trying to free again.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Signed-off-by: Sathishkumar Muruganandam <quic_murugana@quicinc.com>
Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230403182420.23375-2-quic_hprem@quicinc.com
|
|
"__fls" would have an undefined behavior if the argument is passed
as "0". Hence, added changes to handle the same.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com>
Signed-off-by: Nagarajan Maran <quic_nmaran@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230403184155.8670-3-quic_nmaran@quicinc.com
|
|
The WMI management rx event has multiple arrays of TLVs, however the common
WMI TLV parser won't handle multiple TLV tags of same type.
So the multiple array tags of WMI management rx TLV is parsed incorrectly
and the length calculated becomes wrong when the target sends multiple
array tags.
Add separate TLV parser to handle multiple arrays for WMI management rx
TLV. This fixes invalid length issue when the target sends multiple array
tags.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Signed-off-by: Bhagavathi Perumal S <quic_bperumal@quicinc.com>
Co-developed-by: Nagarajan Maran <quic_nmaran@quicinc.com>
Signed-off-by: Nagarajan Maran <quic_nmaran@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230320133840.30162-1-quic_nmaran@quicinc.com
|
|
Currently after the hardware restart triggered from the driver, the
station interface connection remains intact, since a disconnect trigger
is not sent to userspace. This can lead to a problem in targets where
the wifi mac sequence is added by the firmware.
After the target restart, its wifi mac sequence number gets reset to
zero. Hence AP to which our device is connected will receive frames with
a wifi mac sequence number jump to the past, thereby resulting in the
AP dropping all these frames, until the frame arrives with a wifi mac
sequence number which AP was expecting.
To avoid such frame drops, its better to trigger a station disconnect
upon target hardware restart which can be done with API
ieee80211_reconfig_disconnect exposed to mac80211.
The other targets are not affected by this change, since the hardware
params flag is not set.
Reported-by: kernel test robot <lkp@intel.com>
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1
Signed-off-by: Youghandhar Chintala <quic_youghand@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20221104085403.11025-1-quic_youghand@quicinc.com
accepted upstream changes
|
|
Current code does not wait for vdev delete completion on vdev create
failures and tries to send another vdev create followed by vdev set
param to firmware with same vdev id. This causes firmware crash.
Fix this crash by waiting for vdev delete completion on vdev
create failures.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.6.0.1-00905-QCAHKSWPL_SILICONZ-1
Signed-off-by: Sowmiya Sree Elavalagan <quic_ssreeela@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20221011095346.3901-1-quic_ssreeela@quicinc.com
|
|
Currently, ath11k_pcic_read() returns an error if wakeup()
fails, this makes firmware crash debug quite hard because we can
get nothing.
Change to go ahead on wakeup failure, in that case we still may
get something valid to check. There should be no mislead due
to incorrect content because we are aware of the failure with the
log printed.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220928015140.5431-1-quic_bqiang@quicinc.com
|
|
Currently, recovery flag is set immediately upon firmware
exit but tx queues are stopped once firmware arrives back
and is ready which is during ath11k_core_restart. Once
ieee80211 hw restart is completed, tx queues are resumed.
If during the time delta between firmware exit and firmware
ready, mac80211 send packets, currently ath11k will drop it
since recovery flag will be set. But warning prints will
come -
"ath11k c000000.wifi: failed to transmit frame -108"
If more tx packets are there, this could lead to flooding
of above print.
However, actually tx queues should be stopped immediately
when firmware leaves. This will prevent packets to get
dropped when firmware is recovering.
Add fix to stop tx queues immediately after firmware exit.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220923170235.18873-1-quic_adisi@quicinc.com
|
|
Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
|
|
Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
|
|
don't know why it is false now, change it back to true.
|
|
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
|
|
When station is connected to a 6 GHz AP, it has 2 way to configure
the power limit to firmware. The first way is to send 2 wmi command
WMI_PDEV_PARAM_TXPOWER_LIMIT2G/WMI_PDEV_PARAM_TXPOWER_LIMIT5G to
firmware, the second way is to send WMI_VDEV_SET_TPC_POWER_CMDID to
firmware which include more parameters for power control.
The first way is disabled in previous patch
"ath11k: discard BSS_CHANGED_TXPOWER when EXT_TPC_REG_SUPPORT for 6 GHz".
Prepare the parameter for wmi command WMI_VDEV_SET_TPC_POWER_CMDID and
send the firmware after vdev start response success from firmware, it
is for the second way of power control.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
|
|
Add the handler for WMI_VDEV_SET_TPC_POWER_CMDID, it is for 6 GHz band.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
|
|
When station is connected to a 6 GHz AP, it has 2 way to configure
the power limit to firmware. The first way is to send 2 wmi command
WMI_PDEV_PARAM_TXPOWER_LIMIT2G/WMI_PDEV_PARAM_TXPOWER_LIMIT5G to
firmware, the second way is to send WMI_VDEV_SET_TPC_POWER_CMDID to
firmware which include more parameters for power control.
When firmware support SERVICE_EXT_TPC_REG, it means firmware support
the second way for WMI_VDEV_SET_TPC_POWER_CMDID, then ath11k discard
BSS_CHANGED_TXPOWER flag from mac80211 which is used to the first way
for 6 GHz band in this patch and select the second way in the subsequent
patch.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
|
|
Firmware advertises support for SERVICE_EXT_TPC_REG via a WMI service bit.
Add the definition of this service bit so that a subsequent patch can
check whether or not firmware supports this service.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
|
|
Prepare the parameters which is needed for wmi cmd vdev_set_tpc_power.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
|
|
Save the max tx power received in the vdev start response event from
firmware. A subsequent patch will use this to calculate the final power
value for WMI_VDEV_SET_TPC_POWER_CMDID.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
|
|
The transmit power envelope element has some fields for power, ath11k
should parse it according to IEEE Std 802.11ax™‐2021.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
|
|
Save the power spectral density(psd) report from firmware to struct
ieee80211_reg_rule.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
|
|
When wait flag is set for ath11k_reg_update_chan_list(), it maybe wait
the completion of 11d/hw scan if 11d/hw scan are running, and now after
the previous patch "wifi: ath11k: move update channel list from update
reg worker to reg notifier", ath11k_reg_update_chan_list() is called by
ath11k_reg_notifier() which is running in the reg_work of cfg80211, the
reg_work is running with rtnl_lock() which is a global lock, if the wait
of completion of 11d/hw scan happened in ath11k_reg_update_chan_list(),
it will increase the time of occupy the rtnl_lock by reg_work, and then
increase the wait time of the rtnl_lock for other threads.
Move update channel list operation in ath11k_reg_update_chan_list() to
a worker of ath11k, then the wait of completion of 11d/hw scan will not
happen in reg_work and not increase the time of occupy the rtnl_lock by
reg_work.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
|
|
Currently ath11k call regulatory_set_wiphy_regd() in ath11k_regd_update()
to notify the reg domain change to cfg80211, and then ath11k update the
channel list to firmware by ath11k_reg_update_chan_list() immediately in
ath11k_regd_update(), they are running in two threads, it leads the channel
list data out of sync caused by muti-threads without synchronization.
cfg80211 calculate the flags of ieee80211_channel asynchronously in its
reg_work, it is calculated by the callstack below and ath11k get the
flags of ieee80211_channel in another thread without synchronization
for the channel list data.
callstack:
handle_channel_custom()
handle_band_custom()
reg_process_self_managed_hint()
reg_process_self_managed_hints()
reg_todo()
ath11k_reg_update_chan_list() need to use the flags calculated by the
reg_work, they are two thread and have no synchronization for the flags,
then ath11k_reg_update_chan_list() maybe get the wrong flags value before
the calculation finished.
The correct flow is ath11k_reg_update_chan_list() should be called after
the flags finished calculation by reg_work. reg_call_notifier() with
initiator type NL80211_REGDOM_SET_BY_DRIVER will be called by
reg_process_self_managed_hint() after the calculation finished.
So change to update channel list in ath11k_reg_notifier() for initiator
type NL80211_REGDOM_SET_BY_DRIVER, then the calculation of flags of
ieee80211_channel has already finished and ath11k_reg_update_chan_list()
will use the correct value of flags.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
Fixes: f45cb6b29cd3 ("wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update()")
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
|
|
station
When station connect to AP on 6 GHz band, it need switch the regulatory
rules according to the regulatory info subfield in HE operation element.
Swith to the power type of AP for station mode.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Patchwork-Id: 13270318
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
|
|
When wlan boot up, WMI_REG_CHAN_LIST_CC_EXT_EVENTID is sent from
firmware at an early stage, the interface mode is not decided at
this point, then ath11k select reg rules of AP mode as default.
After interface is created, it is exactly decided AP/station mode,
then ath11k need to update reg rules to the exact one.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Patchwork-Id: 13270319
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
|
|
|
|
|
|
|
|
Add some more debug prints in processing regulatory WMI event in order to
increase more debuggability.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230110121024.14051-4-quic_adisi@quicinc.com
|
|
In order to support different power levels of 6 GHz AP and client,
new WMI event for regulatory - WMI_REG_CHAN_LIST_CC_EXT_EVENTID is
added in firmware. This event provides new parameters required for
6 GHz regulatory rules.
Add support for parsing 2.4 GHz, 5 GHz and 6 GHz reg rules and other
parameters from WMI_REG_CHAN_LIST_CC_EXT_EVENTID.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
Signed-off-by: Lavanya Suresh <quic_lavaks@quicinc.com>
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230110121024.14051-3-quic_adisi@quicinc.com
|