From: Stephan Gerhold <stephan@gerhold.net>
To: Konrad Dybcio <konrad.dybcio@linaro.org>
Cc: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>,
Vikash Garodia <quic_vgarodia@quicinc.com>,
Andy Gross <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] media: venus: firmware: Use of_reserved_mem_lookup()
Date: Mon, 29 May 2023 20:43:00 +0200 [thread overview]
Message-ID: <ZHTyNA7CCQft-_HP@gerhold.net> (raw)
In-Reply-To: <ec745998-8b07-c5a5-5220-b2e21528eac1@linaro.org>
On Mon, May 29, 2023 at 08:36:27PM +0200, Konrad Dybcio wrote:
> On 29.05.2023 20:16, Stephan Gerhold wrote:
> > Reserved memory can be either looked up using the generic function
> > of_address_to_resource() or using the special of_reserved_mem_lookup().
> > The latter has the advantage that it ensures that the referenced memory
> > region was really reserved and is not e.g. status = "disabled".
> >
> > of_reserved_mem also supports allocating reserved memory dynamically at
> > boot time. This works only when using of_reserved_mem_lookup() since
> > there won't be a fixed address in the device tree.
> >
> > Switch the code to use of_reserved_mem_lookup(). There is no functional
> > difference for static reserved memory allocations.
> >
> > Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
> > ---
> > See e.g. [1] for an example of dynamically allocated reserved memory.
> > (This patch does *not* depend on [1] and is useful without as well...)
> >
> > [1]: https://lore.kernel.org/linux-arm-msm/20230510-dt-resv-bottom-up-v1-5-3bf68873dbed@gerhold.net/
> > ---
> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>
> > drivers/media/platform/qcom/venus/firmware.c | 24 +++++++++++++-----------
> > 1 file changed, 13 insertions(+), 11 deletions(-)
> >
> [...]
>
> > - mem_va = memremap(r.start, *mem_size, MEMREMAP_WC);
> > + mem_va = memremap(*mem_phys, *mem_size, MEMREMAP_WC);
> > if (!mem_va) {
> > - dev_err(dev, "unable to map memory region: %pR\n", &r);
> > + dev_err(dev, "unable to map memory region %pa size %#zx\n", mem_phys, *mem_size);
> Nit : I'm not sure which is more useful, but many mapping functions
> seem to prefer printing
>
> start, start+size-1
>
> instead of
>
> start, size
>
> on failure.
>
Shrug, both is fine for me. I just used this because the qcom remoteproc
usages of of_address_to_resource() that I also patched already seemed to
log it similar to this.
If someone wants me to resend this with start, start+size-1 as suggested
by Konrad (or something else) then just let me know. :)
Thanks,
Stephan
next prev parent reply other threads:[~2023-05-29 18:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-29 18:16 [PATCH] media: venus: firmware: Use of_reserved_mem_lookup() Stephan Gerhold
2023-05-29 18:36 ` Konrad Dybcio
2023-05-29 18:43 ` Stephan Gerhold [this message]
2023-05-31 6:06 ` Vikash Garodia
2023-05-31 6:56 ` Stephan Gerhold
2023-05-31 7:34 ` Vikash Garodia
2023-05-31 7:45 ` Mukesh Ojha
2023-05-31 9:23 ` Stephan Gerhold
2023-05-31 8:55 ` Vikash Garodia
2023-08-02 8:57 ` Stephan Gerhold
2023-08-02 11:55 ` Stanimir Varbanov
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=ZHTyNA7CCQft-_HP@gerhold.net \
--to=stephan@gerhold.net \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=quic_vgarodia@quicinc.com \
--cc=stanimir.k.varbanov@gmail.com \
/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