This patch fixes the following sparse error:
drivers/soc/qcom/smem.c:738:30: error: incompatible types in comparison expression (different add ress spaces):
drivers/soc/qcom/smem.c:738:30: void *
drivers/soc/qcom/smem.c:738:30: void [noderef] __iomem *
In addr_in_range(), "base" is of type void __iomem *, converting
void *addr to the same type to fix above sparse error.
Fixes: 20bb6c9de1 ("soc: qcom: smem: map only partitions used by local HOST")
Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
Link: https://lore.kernel.org/r/20230801094807.4146779-1-chenjiahao16@huawei.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230623-topic-scm_cleanup-v2-1-9db8c583138d@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230714175142.4067795-1-robh@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230531-rpm-rproc-v3-9-a07dcdefd918@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230531-rpm-rproc-v3-8-a07dcdefd918@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <stephan@gerhold.net>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230531-rpm-rproc-v3-6-a07dcdefd918@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <stephan@gerhold.net>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230531-rpm-rproc-v3-5-a07dcdefd918@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230531-rpm-rproc-v3-4-a07dcdefd918@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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: Bjorn Andersson <quic_bjorande@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230620213703.283583-1-quic_bjorande@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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: 88c1e9404f ("soc: qcom: add OCMEM driver")
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Link: https://lore.kernel.org/r/20230506-msm8226-ocmem-v3-1-79da95a2581f@z3ntu.xyz
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230610-topic-bwmon_opp-v2-1-0d25c1ce7dca@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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: 80e62bc848 ("MAINTAINERS: re-sort all entries and fields")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull dma-mapping fixes from Christoph Hellwig:
- swiotlb area sizing fixes (Petr Tesarik)
* tag 'dma-mapping-6.5-2023-07-09' of git://git.infradead.org/users/hch/dma-mapping:
swiotlb: reduce the number of areas to match actual memory pool size
swiotlb: always set the number of areas before allocating the pool
Pull irq update from Borislav Petkov:
- Optimize IRQ domain's name assignment
* tag 'irq_urgent_for_v6.5_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqdomain: Use return value of strreplace()
