From: "Alexey Klimov" <alexey.klimov@linaro.org>
To: "Bjorn Andersson" <andersson@kernel.org>
Cc: <konradybcio@kernel.org>, <linux-arm-msm@vger.kernel.org>,
<robh@kernel.org>, <krzk+dt@kernel.org>, <conor+dt@kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<srini@kernel.org>, <quic_ekangupt@quicinc.com>,
<krzysztof.kozlowski@linaro.org>,
<dmitry.baryshkov@oss.qualcomm.com>
Subject: Re: [PATCH v2] arm64: dts: qcom: sm8750: Add adsp fastrpc nodes/support
Date: Wed, 06 Aug 2025 13:47:33 +0100 [thread overview]
Message-ID: <DBVCTYZVRR8C.39D28DAAS36UX@linaro.org> (raw)
In-Reply-To: <ovlwlyuwj3q2g4eudesq7qtc3q6omylvnnriagd2nfsrbkbldk@zwdw2yovumeh>
On Wed Aug 6, 2025 at 1:25 AM BST, Bjorn Andersson wrote:
Previous version was sent few months back.
> On Tue, Aug 05, 2025 at 05:20:41PM +0100, Alexey Klimov wrote:
>> While at this, also add required memory region for adsp fastrpc.
>
> Please https://docs.kernel.org/process/submitting-patches.html#describe-your-changes
> rather than lazily continue the subject.
Ok.
It also seems that some other commits that were merged doesn't
really describe addition of fastrpc nodes well.
> Also, the way you wrote this makes me believe adsp_rpc_remote_heap_mem
> is optional, and as I don't know what it's for I don't understand why
> that would be part of this patch.
Yeah, after looking further at the bindings I agree that this should be
described better.
Although some of this is confusing:
>required memory region
>adsp_rpc_remote_heap_mem is optional
Anyhow this mem region seems to be optional so I'll try to split it into
two patches (need to check that dtbs check will be happy with that).
It also seems that when adsp_rpc_remote_heap_mem was merged for other
dtsi-es then no questions were asked.
>> Tested on sm8750-mtp device with adsprpdcd.
>
> Just adsprpdcd?
Yeah, I forgot to mention that getserial can libcalculator tests.
> Is that sufficient to say that fastrpc is functional? Or
> at least that the information here is sufficiently tested?
The testing of fastrpc for adsp is quite limited. If you or Qualcomm can
provide the usable tests to run and verify then please do so.
I think what happens is that often the info for fastrpc nodes just being
copied and filled in with info from downstream with no requests to provide
test results.
Here it was tested with adsprpdcd with compressed playback and two tests
above I forgot to mention.
[..]
Thanks,
Alexey
prev parent reply other threads:[~2025-08-06 12:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-05 16:20 [PATCH v2] arm64: dts: qcom: sm8750: Add adsp fastrpc nodes/support Alexey Klimov
2025-08-05 16:51 ` Konrad Dybcio
2025-08-06 0:25 ` Bjorn Andersson
2025-08-06 12:47 ` Alexey Klimov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DBVCTYZVRR8C.39D28DAAS36UX@linaro.org \
--to=alexey.klimov@linaro.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_ekangupt@quicinc.com \
--cc=robh@kernel.org \
--cc=srini@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).