- 31 Jul, 2023 5 commits
-
-
Neil Armstrong authored
Altmode is also supported for SM8550, allow it. Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230601-topic-sm8550-upstream-type-c-v5-3-9221cd300903@linaro.orgSigned-off-by:
Bjorn Andersson <andersson@kernel.org>
-
Neil Armstrong authored
Some boards have a retimer/redriver between the SuperSpeed PHY and the USB-C connector to compensates signal integrity losses mainly due to PCB & transmission cables. Add support for an optional retimer-switch in the USB-C connector graph. Signed-off-by:
-
Neil Armstrong authored
On some Qcom SoCs, the Altmode event mode is set to 0xff when the Type-C port is disconnected. Handle this specific mode and translate it as the SAFE mode. Signed-off-by:
-
Rohit Agarwal authored
Add the power domains exposed by RPMH in the Qualcomm SDX75 platform. Signed-off-by:
Rohit Agarwal <quic_rohiagar@quicinc.com> Link: https://lore.kernel.org/r/1690803007-8640-3-git-send-email-quic_rohiagar@quicinc.comSigned-off-by:
-
Rohit Agarwal authored
Add a compatible string for power domains in sdx75. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/1690803007-8640-2-git-send-email-quic_rohiagar@quicinc.comSigned-off-by:
-
- 28 Jul, 2023 2 commits
-
-
Guru Das Srinagesh authored
Commit 3a99f121 ("firmware: qcom: scm: Introduce pas_metadata context") left out the `extern` specifier for the API it introduced, so add it. Signed-off-by:
Guru Das Srinagesh <quic_gurus@quicinc.com> Link: https://lore.kernel.org/r/bce25c8e215f7cfc7b0780d6965d09f5efe1cc5f.1690503893.git.quic_gurus@quicinc.comSigned-off-by:
-
Guru Das Srinagesh authored
The `qcom_scm` module is GPL v2-licenced and so there is no reason why the APIs it exports should not be, too. Signed-off-by:
Trilok Soni <quic_tsoni@quicinc.com> Link: https://lore.kernel.org/r/19d9ac0bf79f957574ef9b3b73246ea0113cc0fd.1690503893.git.quic_gurus@quicinc.comSigned-off-by:
-
- 26 Jul, 2023 1 commit
-
-
Krzysztof Kozlowski authored
dt-bindings: arm: msm: kpss-acc: Revert "dt-bindings: arm: msm: kpss-acc: Make the optional reg truly optional" This reverts commit 981be238e1d28e156aa9da2a8722f86f02fd0453 because it was totally bogus and duplicated existing minItems: ruamel.yaml.constructor.DuplicateKeyError: while constructing a mapping Documentation/devicetree/bindings/power/qcom,kpss-acc-v2.yaml: ignoring, error parsing file Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
-
- 24 Jul, 2023 4 commits
-
-
Konrad Dybcio authored
There are three categories of compatibles within the driver: 1. Ones which were introduced without a qcom,scm fallback 2. Ones which were introduced with a qcom,scm fallback 3. Ones which were defined but never used Keep 1 for backwards compatibility and axe 2 & 3. Signed-off-by:
-
Konrad Dybcio authored
If devm_clk_get_optional throws an error, something is really wrong. It may be a probe deferral, or it may be a problem with the clock provider. Regardless of what it may be, it should definitely not be ignored. Stop doing that. Signed-off-by:
-
Konrad Dybcio authored
The code for handling more than 1 clock is a bit messy and requires one to add new, SoC-specific compatibles if one wants to attach a clock. Switch devm_clk_get to devm_clk_get_optional to prevent throwing it from throwing errors when the clock is absent and defer checking the clock requirements to dt schema. This lets us get rid of compatibles that aren't necessary for backwards compatibility *and* will hopefully prevent the addition of meaningless new compatibles. Signed-off-by:
-
Konrad Dybcio authored
The description of reg[1] says that register is optional. Adjust minItems to make it truly optional. Fixes: 4260ddfb ("dt-bindings: arm: msm: Convert and split kpss-acc driver Documentation to yaml") Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230627-topic-more_bindings-v1-9-6b4b6cd081e5@linaro.orgSigned-off-by:
-
- 22 Jul, 2023 4 commits
-
-
Yuanjun Gong authored
in gsbi_probe(), the return value of function clk_prepare_enable() should be checked, since it may fail. using devm_clk_get_enabled() instead of devm_clk_get() and clk_prepare_enable() can avoid this problem. Signed-off-by:
Yuanjun Gong <ruc_gongyuanjun@163.com> Link: https://lore.kernel.org/r/20230720140834.33557-1-ruc_gongyuanjun@163.com [bjorn: Dropped unnecessary "ret" variable] Signed-off-by:
-
Rohit Agarwal authored
Update the SoC SM8[2345]50 entries to use the new generic RPMHPD bindings. Signed-off-by:
-
Bjorn Andersson authored
Merge the new generic RPMHPD defines from a topic branch, to alow them being used in DeviceTree source, and the driver.
-
Rohit Agarwal authored
Add Generic RPMh Power Domain indexes that can be used for all the Qualcomm SoC henceforth. The power domain indexes of these bindings are based on compatibility with current targets like SM8[2345]50 targets. Signed-off-by:
-
- 14 Jul, 2023 11 commits
-
-
Rob Herring authored
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by:
-
Stephan Gerhold authored
Add a simple driver for the qcom,rpm-proc compatible that registers the "smd-edge" and populates other children defined in the device tree. Note that the DT schema belongs to the remoteproc subsystem while this driver is added inside soc/qcom. I argue that the RPM *is* a remoteproc, but as an implementation detail in Linux it can currently not benefit from anything provided by the remoteproc subsystem. The RPM firmware is usually already loaded and started by earlier components in the boot chain and is not meant to be ever restarted. To avoid breaking existing kernel configurations the driver is always built when smd-rpm.c is also built. They belong closely together anyway. To avoid build errors CONFIG_RPMSG_QCOM_SMD must be also built-in if rpm-proc is. Reviewed-by:
Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230531-rpm-rproc-v3-9-a07dcdefd918@gerhold.netSigned-off-by:
-
Stephan Gerhold authored
Rather than looking up a dummy item from SMEM, use the new qcom_smem_is_available() function to make the code more clear (and reduce the overhead slightly). Add the same check to qcom_smd_register_edge() as well to ensure that it only succeeds if SMEM is already available - if a driver calls the function and SMEM is not available yet then the initial state will be read incorrectly and the RPMSG devices might never become available. Reviewed-by:
-
Stephan Gerhold authored
Avoid having to look up a dummy item from SMEM to detect if it is already available or if we need to defer probing. Reviewed-by:
-
Stephan Gerhold authored
On Qualcomm platforms, most subsystems (e.g. audio/modem DSP) are described as remote processors in the device tree, with a dedicated node where properties and services related to them can be described. The Resource Power Manager (RPM) is also such a subsystem, with a remote processor that is running a special firmware. Unfortunately, the RPM never got a dedicated node representing it properly in the device tree. Most of the RPM services are described below a top-level /smd or /rpm-glink node. However, SMD/GLINK is just one of the communication channels to the RPM firmware. For example, the MPM interrupt functionality provided by the RPM does not use SMD/GLINK but writes directly to a special memory region allocated by the RPM firmware in combination with a mailbox. Currently there is no good place in the device tree to describe this functionality. It doesn't belong below SMD/GLINK but it's not an independent top-level device either. Introduce a new "qcom,rpm-proc" compatible that allows describing the RPM as a remote processor/subsystem like all others. The SMD/GLINK node is moved to a "smd-edge"/"glink-edge" subnode consistent with other existing bindings. Additional subnodes (e.g. interrupt-controller for MPM, rpm-master-stats) can be also added there. Deprecate using the old top-level /smd node since all SMD edges are now specified as subnodes of the remote processor. Signed-off-by:
-
Stephan Gerhold authored
Semantically glink-edge and glink-rpm-edge are similar: Both describe the communication channels to a remote processor. The RPM glink-edge is a special case that needs slightly different properties but otherwise it is used exactly the same. To improve consistency use the same "glink-edge" node name also for glink-rpm-edge. Drop the $nodename from qcom,glink-edge.yaml to avoid matching the wrong schema. qcom,glink-edge.yaml is always referenced explicitly from other schemas. This will already ensure that the nodes are being checked, so it's not necessary to bind to all nodes named "glink-edge". Signed-off-by:
-
Stephan Gerhold authored
There is an ever growing list of compatibles in the smd-rpm.c driver. A fallback compatible would help here but would still require keeping the current list around for backwards compatibility. As an alternative, let's switch the driver to match the rpmsg_device_id instead, which is always "rpm_requests" on all platforms. Add a check to ensure that there is a device tree node defined for the device since otherwise the of_platform_populate() call will operate on the root node (/). Similar approaches with matching rpmsg_device_id are already used in qcom_sysmon, qcom_glink_ssr, qrtr, and rpmsg_wwan_ctrl. Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> # SM6375 (G-Link) Reviewed-by:
-
Stephan Gerhold authored
To avoid several more small patches adding new RPM compatibles in the future, add MDM9607, MSM8610, MSM8917, MSM8937 and MSM8952 at once. All of these have been worked on over the time by some people and are definitely compatible as-is with the smd-rpm driver. Acked-by:
-
Stephan Gerhold authored
MSM8909 is using qcom,smd-channels but is missing in the list, add it there as well. Fixes: 709d473d ("dt-bindings: soc: qcom: smd-rpm: Add MSM8909") Reviewed-by:
-
Stephan Gerhold authored
Some of the enum entries are not properly ordered, fix that. Acked-by:
-
Christophe JAILLET authored
Use struct_size() instead of hand-writing it, when allocating a structure with a flex array. This is less verbose. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/f74328551cfab0262ba353f37d047ac74bf616e1.1689194490.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
- 10 Jul, 2023 11 commits
-
-
Yangtao Li authored
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by:
Yangtao Li <frank.li@vivo.com> Link: https://lore.kernel.org/r/20230705122644.32236-3-frank.li@vivo.comSigned-off-by:
-
Konrad Dybcio authored
Just like all other Qualcomm SoCs, SC8280XP SCM should be fed an interconnect path. Do so. Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Tested-by:
-
Bjorn Andersson authored
When tracing messages written to the RSC it's very useful to know the type of TCS being targeted, in particular if/when the code borrows a WAKE TCS for ACTIVE votes. Add the "state" of the message to the traced information. While at it, drop the "send-msg:" substring, as this is already captured by the trace event itself. Signed-off-by:
Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Acked-by:
-
Bjorn Andersson authored
The debugfs dump of Command DB relies uses %*pEp to print the resource identifiers, with escaping of non-printable characters. But p (ESCAPE_NP) does not escape NUL characters, so for identifiers less than 8 bytes in length the output will retain these. This does not cause an issue while looking at the dump in the terminal (no known complaints at least), but when programmatically consuming the debugfs output the extra characters are unwanted. Change the fixed 8-byte sizeof() to a dynamic strnlen() to avoid printing these NUL characters. Signed-off-by:
-
Konrad Dybcio authored
Add a sync_state implementation, very similar to the one already present in the RPMhPD driver. Signed-off-by:
-
Luca Weiss authored
The msm8226 SoC also contains OCMEM but with one region only. Reviewed-by:
Luca Weiss <luca@z3ntu.xyz> Link: https://lore.kernel.org/r/20230506-msm8226-ocmem-v3-5-79da95a2581f@z3ntu.xyzSigned-off-by:
-
Luca Weiss authored
Add the compatible for the OCMEM found on msm8226 which compared to msm8974 only has a core clock and no iface clock. Reviewed-by:
-
Luca Weiss authored
Some platforms such as msm8226 do not have an iface clk. Since clk_bulk APIs don't offer to a way to treat some clocks as optional simply add core_clk and iface_clk members to our drvdata. Reviewed-by:
-
Luca Weiss authored
Use dev_err_probe in the driver probe function where useful, to simplify getting PTR_ERR and to ensure the underlying errors are included in the error message. Reviewed-by:
Caleb Connolly <caleb.connolly@linaro.org> Reviewed-by:
-
Luca Weiss authored
Since we're using these two macros to read a value from a register, we need to use the FIELD_GET instead of the FIELD_PREP macro, otherwise we're getting wrong values. So instead of: [ 3.111779] ocmem fdd00000.sram: 2 ports, 1 regions, 512 macros, not interleaved we now get the correct value of: [ 3.129672] ocmem fdd00000.sram: 2 ports, 1 regions, 2 macros, not interleaved Fixes: 88c1e940 ("soc: qcom: add OCMEM driver") Reviewed-by:
-
Konrad Dybcio authored
Currently we use predefined initial threshold values. This works, but does not really scale well with more and more SoCs gaining bwmon support, as the necessary kickoff values may differ between platforms due to memory type and/or controller setup. All of the data we need for that is already provided in the device tree, anyway. Change the thresholds to: * low = 0 (as we've been doing up until now) * med = high = BW_MIN Throughput going below the med threshold nudges bwmon into signaling that we should slow down (e.g. if we inherited too high bandwidth from the bootloader). Throughput going above the high threshold nudges bwmon into signaling that we should speed up so as not to choke the bus traffic due to insufficient transfer rates. F_MIN is a perfect initial value for both of these cases - if we go above it (and there's a 99.99% chance it'll happen at boot time), we should definitely make the memory go faster, whereas if we go below it, we should slow down, no matter what performance state we were at before (it's only possible for them to be >= FMIN). This only changes the values programmed at probe time, as high and med thresholds are updated at interrupt, also based on the OPP table from DT. Signed-off-by:
-
- 09 Jul, 2023 2 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
We just sorted the entries and fields last release, so just out of a perverse sense of curiosity, I decided to see if we can keep things ordered for even just one release. The answer is "No. No we cannot". I suggest that all kernel developers will need weekly training sessions, involving a lot of Big Bird and Sesame Street. And at the yearly maintainer summit, we will all sing the alphabet song together. I doubt I will keep doing this. At some point "perverse sense of curiosity" turns into just a cold dark place filled with sadness and despair. Repeats: 80e62bc8 ("MAINTAINERS: re-sort all entries and fields") Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
