When driver calls ops_bus_request with high bandwidth requirement,
affinity of wil6210 interrupt is set to first big core. However this
setting is not cleared when driver lowers bandwidth requirement.
This causes WARN_ON_ONCE(desc->affinity_hint) upon wil6210 rmmod.
Fix this by clearing affinity hint upon low bandwidth request.
Change-Id: I87b6b7ec9b369b84a9d3724d92a821a1302d1f83
Signed-off-by: Dedy Lansky <dlansky@codeaurora.org>
Update HDMI drift mixer controls name to be aligned with
drift mixer controls for other devices(speaker, BT).
CRs-Fixed: 2036899
Change-Id: If7aa29ea9511b65de71ff12143a1c34d977de2b8
Signed-off-by: Manish Dewangan <manish@codeaurora.org>
As a part of 'commit 64db44d65e ("ARM: dts: msm:
move ref-clk from phy to ufs node in sdm660")',
ref-clk node is moved from phy to ufs and ref-clk
related property should be prefixed with "qcom,".
This change updates the same for sdm660 mtp so as
to turn-off the ref-clk supply when link is off.
Change-Id: Iee0fcaaaa34108c35d836d6136f8c1a0964f0fa4
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Initialize mutex before using in irq handler.
CRs-fixed: 2047720
Change-Id: I5ebfbc22f2a64dde239fcbb13eb26be50543b484
Signed-off-by: Mohan Pallaka <mpallaka@codeaurora.org>
Upon cable disconnect PMI calls qusb_phy_update_dpdm() to turn off phy
regulators before notifying vbus off to usb. As a result phy power down
sequence is executed with phy regulators turned off. This may result into
improper phy line state. Fix this issue by adding a reference counter to
keep track of all regulator enable and disable requests and only disable
regulator when ref count becomes zero. Also add a mutex in
qusb_phy_enable_power() API to prevent any race condition in enabling and
disabling phy regulators between the callers i.e. PMI and phy driver.
Change-Id: I620f2b8cbf4f9271db81d5a517f1ee2a13c57f27
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
QUSB PHY requires VDD, 1p8 and 3p1 regulators to remove any unwanted
pull downs on DP/DM lines. These pull downs may result in incorrect charger
detection by PMI. Avoid incorrect charger detection by turning on VDD,
1p8 and 3p1 whenever PMI requests DP/DM to be floating.
Change-Id: I27e68d5ebf2f49fb6571ad777318483f9c123407
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Specify LDO24 voltage as 2.4V for charger detection and 3.088V
for USB data.
Change-Id: I9f365caf89226f1ce0e28b07306906c5d83541fe
Signed-off-by: Jack Pham <jackp@codeaurora.org>
CONFIG_TIMER_STATS is no longer needed and the kconfig option
will be removed in subsequent commits.
Change-Id: I380f9f925332c594c9d500312a06713170e48505
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
The specific voltage levels for the vdda33 regulator may vary
depending on the target. Add an optional device tree property to
allow specifying a 3-tuple of voltages for minimum, operating
and maximum voltage levels. The minimum level is used when simply
powering on, whereas the operating level is used when initializing
the PHY.
Change-Id: Ia5d301efdb6964434a01264e7aa19421a41e98ca
Signed-off-by: Jack Pham <jackp@codeaurora.org>
This change initializes the tmp array elements to
ensure no use of uninitialized variable. This was caught
through Static Analysis
Change-Id: Ibc01493e9f0ce1a492579b568fa7362cb3c3b1d7
Signed-off-by: Vijay Ganti <viganti@codeaurora.org>
The range checking between "WCD_CPE_IMAGE_FNAME_MAX" and
"copy_count" is off-by-one due to the size of array
"core->dyn_fname" is "WCD_CPE_IMAGE_FNAME_MAX". Subtract
one from the range checking to fix this issue.
Change-Id: I87fd55206f79ad7b13c3878f6642bf5579303b17
Signed-off-by: Xiaoyu Ye <benyxy@codeaurora.org>
Add device tree to support guest virtual machine on
msm kernel.
CRs-Fixed: 2000645
Change-Id: I4ca06c28c349dd533057b24fe6794a7c11a84cc6
Signed-off-by: Atul Raut <araut@codeaurora.org>
Exceeding sink hard reset count means no PD session active. Hence vote
to turn off PD phy regulator by closing the PD phy.
Change-Id: I2aaa3c9c7b651aec77e67139e3cdcbbf9437f091
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
We take a lock of drvdata->mutex and further wait on a lock
'drvdata->handle->handle_lock' in below path
remote_etm_disable => qmi_send_req_wait => qmi_encode_and_send_req
So, it is possible that while we wait on a handle lock in above mentioned
path The handle itself gets destroyed via below path
remote_etm_svc_exit => qmi_handle_destroy
and the handle is not valid anymore.
This patch adds lock drvdata->mutex at number of possible cases.
CRs-Fixed: 2045013
Change-Id: I4a5110630b78e551bab1b4f454d23aacd599c000
Signed-off-by: Mukesh Ojha <mojha@codeaurora.org>