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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.