From: Stephan Gerhold <stephan@gerhold.net>
To: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
Cc: Vikash Garodia <quic_vgarodia@quicinc.com>,
Andy Gross <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.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: Wed, 2 Aug 2023 10:57:55 +0200 [thread overview]
Message-ID: <ZMoak_qaUSX-pkP2@gerhold.net> (raw)
In-Reply-To: <20230529-venus-of-rmem-v1-1-dfcdc5047ffb@gerhold.net>
Hi Stanimir,
I see that you already tagged the Venus updates for 6.6, but could you
try to still apply this patch as well for 6.6? It's a requirement for
some DT cleanup I'm working on and ideally needs to go in a kernel
release earlier to avoid bisect problems.
AFAICT it's been on the list for more than two months now with two
Reviewed-by, so should be fine to just apply it. :)
Thanks!
Stephan
On Mon, May 29, 2023 at 08:16:14PM +0200, 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/
> ---
> drivers/media/platform/qcom/venus/firmware.c | 24 +++++++++++++-----------
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
> index cfb11c551167..2e7ffdaff7b2 100644
> --- a/drivers/media/platform/qcom/venus/firmware.c
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -10,6 +10,7 @@
> #include <linux/io.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> +#include <linux/of_reserved_mem.h>
> #include <linux/platform_device.h>
> #include <linux/of_device.h>
> #include <linux/firmware/qcom/qcom_scm.h>
> @@ -82,9 +83,9 @@ static int venus_load_fw(struct venus_core *core, const char *fwname,
> phys_addr_t *mem_phys, size_t *mem_size)
> {
> const struct firmware *mdt;
> + struct reserved_mem *rmem;
> struct device_node *node;
> struct device *dev;
> - struct resource r;
> ssize_t fw_size;
> void *mem_va;
> int ret;
> @@ -99,13 +100,16 @@ static int venus_load_fw(struct venus_core *core, const char *fwname,
> return -EINVAL;
> }
>
> - ret = of_address_to_resource(node, 0, &r);
> - if (ret)
> - goto err_put_node;
> + rmem = of_reserved_mem_lookup(node);
> + of_node_put(node);
> + if (!rmem) {
> + dev_err(dev, "failed to lookup reserved memory-region\n");
> + return -EINVAL;
> + }
>
> ret = request_firmware(&mdt, fwname, dev);
> if (ret < 0)
> - goto err_put_node;
> + return ret;
>
> fw_size = qcom_mdt_get_size(mdt);
> if (fw_size < 0) {
> @@ -113,17 +117,17 @@ static int venus_load_fw(struct venus_core *core, const char *fwname,
> goto err_release_fw;
> }
>
> - *mem_phys = r.start;
> - *mem_size = resource_size(&r);
> + *mem_phys = rmem->base;
> + *mem_size = rmem->size;
>
> if (*mem_size < fw_size || fw_size > VENUS_FW_MEM_SIZE) {
> ret = -EINVAL;
> goto err_release_fw;
> }
>
> - 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);
> ret = -ENOMEM;
> goto err_release_fw;
> }
> @@ -138,8 +142,6 @@ static int venus_load_fw(struct venus_core *core, const char *fwname,
> memunmap(mem_va);
> err_release_fw:
> release_firmware(mdt);
> -err_put_node:
> - of_node_put(node);
> return ret;
> }
>
>
> ---
> base-commit: 9f9f8ca6f012d25428f8605cb36369a449db8508
> change-id: 20230529-venus-of-rmem-f649885114fd
>
> Best regards,
> --
> Stephan Gerhold <stephan@gerhold.net>
>
next prev parent reply other threads:[~2023-08-02 9:01 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
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 [this message]
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=ZMoak_qaUSX-pkP2@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