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 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.