The following error was reported when building x86_64 allmodconfig:
error: the following would cause module name conflict:
drivers/soc/qcom/ice.ko
drivers/net/ethernet/intel/ice/ice.ko
Seems the 'ice' module name is already used by some Intel ethernet
driver, so lets rename the Qualcomm Inline Crypto Engine (ICE) module
from 'ice' to 'qcom_ice' to avoid any kind of errors/confusions.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: 2afbf43a4aec ("soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver")
Acked-by: Mukesh Ojha <quic_mojha@quicinc.com>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230516082856.150214-1-abel.vesa@linaro.org
This takes the already existing duplicated support in both ufs-qcom and sdhci-msm drivers and makes it a dedicated driver that can be used by both mentioned drivers. The reason for this is because, staring with SM8550, the ICE IP block is shared between UFS and SDCC, which means we need to probe a dedicated device and share it between those two consumers. So let's add the ICE dedicated driver as a soc driver. Platforms that already have ICE supported, will use it as a library as the of_qcom_ice_get will return an ICE instance created for the consumer device. This allows the backwards compatibility with old-style devicetree approach. Also, add support to HW version 4.x since it works out-of-the-box with the current driver. The 4.x HW version is found on SM8550 platform. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230407105029.2274111-4-abel.vesa@linaro.org
With the PMIC GLINK service, the host OS subscribes to USB-C altmode messages, which are sent by the firmware to notify the host OS about state updates and HPD interrupts. The pmic_glink_altmode driver registers for these notifications and propagates the notifications as typec_mux, typec_switch and DRM OOB notifications as necessary to implement DisplayPort altmode support. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> # SM8350 PDX215 Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-MTP & SM8450-HDK Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230201041853.1934355-4-quic_bjorande@quicinc.com
The PMIC GLINK service runs on one of the co-processors of some modern Qualcomm platforms and implements USB-C and battery managements. It uses a message based protocol over GLINK for communication with the OS, hence the name. The driver implemented provides the rpmsg device for communication and uses auxiliary bus to spawn off individual devices in respective subsystem. The auxiliary devices are spawned off from a platform_device, so that the drm_bridge is available early, to allow the DisplayPort driver to probe even before the remoteproc has spun up. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> # SM8350 PDX215 Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-MTP & SM8450-HDK Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230201041853.1934355-3-quic_bjorande@quicinc.com
Arnd asks for the DCC driver to be dropped for now, in order to allow for more thorough review, by a wider audience, of the ABI introduced. The Devicetree binding is adequately describing the hardware block, so this is kept. Requested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The DCC is a DMA Engine designed to capture and store data during system crash or software triggers. The DCC operates based on user inputs via the debugfs interface. The user gives addresses as inputs and these addresses are stored in the dcc sram. In case of a system crash or a manual software trigger by the user through the debugfs interface, the dcc captures and stores the values at these addresses. This patch contains the driver which has all the methods pertaining to the debugfs interface, auxiliary functions to support all the four fundamental operations of dcc namely read, write, read/modify/write and loop. The probe method here instantiates all the resources necessary for dcc to operate mainly the dedicated dcc sram where it stores the values. The DCC driver can be used for debugging purposes without going for a reboot since it can perform software triggers as well based on user inputs. Also add the documentation for debugfs entries which explains the functionalities of each debugfs file that has been created for dcc. The following is the justification of using debugfs interface over the other alternatives like sysfs/ioctls i) As can be seen from the debugfs attribute descriptions, some of the debugfs attribute files here contains multiple arguments which needs to be accepted from the user. This goes against the design style of sysfs. ii) The user input patterns have been made simple and convenient in this case with the use of debugfs interface as user doesn't need to shuffle between different files to execute one instruction as was the case on using other alternatives. Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> Reviewed-by: Alex Elder <elder@linaro.org> [bjorn: Fixed up a few indents and line wraps] Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/644b4f66a358492a8a6738454035c3b120092fe7.1672148732.git.quic_schowdhu@quicinc.com
The Ramp Controller is used to program the sequence ID for pulse swallowing, enable sequence and linking sequence IDs for the CPU cores on some Qualcomm SoCs. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221117132956.169432-3-angelogioacchino.delregno@collabora.com
Bandwidth monitoring (BWMON) sits between various subsytems like CPU, GPU, Last Level caches and memory subsystem. The BWMON can be configured to monitor the data throuhput between memory and other subsytems. The throughput is measured within specified sampling window and is used to vote for corresponding interconnect bandwidth. Current implementation brings support for BWMON v4, used for example on SDM845 to measure bandwidth between CPU (gladiator_noc) and Last Level Cache (memnoc). Usage of this BWMON allows to remove fixed bandwidth votes from cpufreq (CPU nodes) thus achieve high memory throughput even with lower CPU frequencies. The driver was tested on SDM845. Co-developed-by: Thara Gopinath <thara.gopinath@gmail.com> Signed-off-by: Thara Gopinath <thara.gopinath@gmail.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220704121730.127925-3-krzysztof.kozlowski@linaro.org
Let's add a driver to read the stats from remote processor and export to debugfs. The driver creates "qcom_sleep_stats" directory in debugfs and adds files for various low power mode available. Below is sample output with command cat /sys/kernel/debug/qcom_sleep_stats/ddr count = 0 Last Entered At = 0 Last Exited At = 0 Accumulated Duration = 0 Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org> Signed-off-by: Lina Iyer <ilina@codeaurora.org> [mkshah: add subsystem sleep stats, create one file for each stat] Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Tested-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1634107104-22197-3-git-send-email-mkshah@codeaurora.org