From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
To: Vikash Garodia <quic_vgarodia@quicinc.com>,
Dikshita Agarwal <quic_dikshita@quicinc.com>,
Abhinav Kumar <abhinav.kumar@linux.dev>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>
Cc: linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/5] media: iris: use np_dev as preferred DMA device in HFI queue management
Date: Fri, 27 Jun 2025 18:03:56 +0100 [thread overview]
Message-ID: <ebdbb517-ffa2-422a-989e-a4f19ab0163a@linaro.org> (raw)
In-Reply-To: <20250627-video_cb-v3-3-51e18c0ffbce@quicinc.com>
On 27/06/2025 16:48, Vikash Garodia wrote:
> Update HFI interface queues to use np_dev(preferred non-pixel device)
> for DMA memory allocation and deallocation if available. This allows
> platforms with separate DMA domain for non-pixel to use the appropriate
> device handle when managing HFI queues and SFR regions.
>
> Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
> ---
> drivers/media/platform/qcom/iris/iris_hfi_queue.c | 20 +++++++++++++-------
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_queue.c b/drivers/media/platform/qcom/iris/iris_hfi_queue.c
> index fac7df0c4d1aec647aeca275ab19651c9ba23733..a31ebe947f525f0d7c09f8b786939d01b62532c3 100644
> --- a/drivers/media/platform/qcom/iris/iris_hfi_queue.c
> +++ b/drivers/media/platform/qcom/iris/iris_hfi_queue.c
> @@ -247,24 +247,27 @@ static void iris_hfi_queue_deinit(struct iris_iface_q_info *iface_q)
> int iris_hfi_queues_init(struct iris_core *core)
> {
> struct iris_hfi_queue_table_header *q_tbl_hdr;
> + struct device *dev;
> u32 queue_size;
>
> + dev = core->np_dev ? core->np_dev : core->dev;
> +
dev = core->dev;
if (core->np_dev)
dev = core->np_dev;
Is much easier to read.
> /* Iris hardware requires 4K queue alignment */
> queue_size = ALIGN((sizeof(*q_tbl_hdr) + (IFACEQ_QUEUE_SIZE * IFACEQ_NUMQ)), SZ_4K);
> - core->iface_q_table_vaddr = dma_alloc_attrs(core->dev, queue_size,
> + core->iface_q_table_vaddr = dma_alloc_attrs(dev, queue_size,
> &core->iface_q_table_daddr,
> GFP_KERNEL, DMA_ATTR_WRITE_COMBINE);
> if (!core->iface_q_table_vaddr) {
> - dev_err(core->dev, "queues alloc and map failed\n");
> + dev_err(dev, "queues alloc and map failed\n");
> return -ENOMEM;
> }
>
> - core->sfr_vaddr = dma_alloc_attrs(core->dev, SFR_SIZE,
> + core->sfr_vaddr = dma_alloc_attrs(dev, SFR_SIZE,
> &core->sfr_daddr,
> GFP_KERNEL, DMA_ATTR_WRITE_COMBINE);
> if (!core->sfr_vaddr) {
> - dev_err(core->dev, "sfr alloc and map failed\n");
> - dma_free_attrs(core->dev, sizeof(*q_tbl_hdr), core->iface_q_table_vaddr,
> + dev_err(dev, "sfr alloc and map failed\n");
> + dma_free_attrs(dev, sizeof(*q_tbl_hdr), core->iface_q_table_vaddr,
> core->iface_q_table_daddr, DMA_ATTR_WRITE_COMBINE);
> return -ENOMEM;
> }
> @@ -292,6 +295,7 @@ int iris_hfi_queues_init(struct iris_core *core)
>
> void iris_hfi_queues_deinit(struct iris_core *core)
> {
> + struct device *dev;
> u32 queue_size;
>
> if (!core->iface_q_table_vaddr)
> @@ -301,7 +305,9 @@ void iris_hfi_queues_deinit(struct iris_core *core)
> iris_hfi_queue_deinit(&core->message_queue);
> iris_hfi_queue_deinit(&core->command_queue);
>
> - dma_free_attrs(core->dev, SFR_SIZE, core->sfr_vaddr,
> + dev = core->np_dev ? core->np_dev : core->dev;
and again
> +
> + dma_free_attrs(dev, SFR_SIZE, core->sfr_vaddr,
> core->sfr_daddr, DMA_ATTR_WRITE_COMBINE);
>
> core->sfr_vaddr = NULL;
> @@ -310,7 +316,7 @@ void iris_hfi_queues_deinit(struct iris_core *core)
> queue_size = ALIGN(sizeof(struct iris_hfi_queue_table_header) +
> (IFACEQ_QUEUE_SIZE * IFACEQ_NUMQ), SZ_4K);
>
> - dma_free_attrs(core->dev, queue_size, core->iface_q_table_vaddr,
> + dma_free_attrs(dev, queue_size, core->iface_q_table_vaddr,
> core->iface_q_table_daddr, DMA_ATTR_WRITE_COMBINE);
>
> core->iface_q_table_vaddr = NULL;
>
Other than that.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
next prev parent reply other threads:[~2025-06-27 17:04 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-27 15:48 [PATCH v3 0/5] Introduce "non-pixel" sub node within iris video node Vikash Garodia
2025-06-27 15:48 ` [PATCH v3 1/5] media: dt-bindings: add non-pixel property in iris schema Vikash Garodia
2025-06-27 16:31 ` Bryan O'Donoghue
2025-06-27 17:16 ` Vikash Garodia
2025-06-30 15:48 ` neil.armstrong
2025-06-30 15:56 ` Neil Armstrong
2025-07-02 11:13 ` Krzysztof Kozlowski
2025-07-02 11:32 ` Vikash Garodia
2025-07-02 11:46 ` Krzysztof Kozlowski
2025-07-02 13:11 ` Konrad Dybcio
2025-07-02 13:59 ` Krzysztof Kozlowski
2025-07-02 16:36 ` Vikash Garodia
2025-07-02 20:16 ` Krzysztof Kozlowski
2025-07-03 10:11 ` Konrad Dybcio
2025-07-03 7:29 ` Krzysztof Kozlowski
2025-07-02 11:23 ` Krzysztof Kozlowski
2025-07-02 11:45 ` Vikash Garodia
2025-07-02 11:47 ` Krzysztof Kozlowski
2025-07-02 11:55 ` Vikash Garodia
2025-07-02 11:58 ` Krzysztof Kozlowski
2025-07-02 12:08 ` Vikash Garodia
2025-07-02 12:11 ` Krzysztof Kozlowski
2025-06-27 15:48 ` [PATCH v3 2/5] media: iris: register and configure non-pixel node as platform device Vikash Garodia
2025-06-27 17:01 ` Bryan O'Donoghue
2025-07-02 11:04 ` Krzysztof Kozlowski
2025-07-02 11:39 ` Vikash Garodia
2025-07-02 12:45 ` Konrad Dybcio
2025-06-27 15:48 ` [PATCH v3 3/5] media: iris: use np_dev as preferred DMA device in HFI queue management Vikash Garodia
2025-06-27 17:03 ` Bryan O'Donoghue [this message]
2025-06-27 15:48 ` [PATCH v3 4/5] media: iris: select appropriate DMA device for internal buffers Vikash Garodia
2025-06-27 17:07 ` Bryan O'Donoghue
2025-06-27 15:48 ` [PATCH v3 5/5] media: iris: configure DMA device for vb2 queue on OUTPUT plane Vikash Garodia
2025-06-27 17:08 ` Bryan O'Donoghue
2025-06-30 7:58 ` Vikash Garodia
2025-07-01 12:04 ` Konrad Dybcio
2025-06-27 16:30 ` [PATCH v3 0/5] Introduce "non-pixel" sub node within iris video node Bryan O'Donoghue
2025-06-27 17:00 ` Vikash Garodia
2025-07-02 11:05 ` Krzysztof Kozlowski
2025-06-30 15:55 ` neil.armstrong
2025-06-30 18:04 ` neil.armstrong
2025-07-01 8:42 ` Konrad Dybcio
2025-07-01 10:23 ` Vikash Garodia
2025-07-01 13:19 ` Neil Armstrong
2025-07-01 16:11 ` Vikash Garodia
2025-07-02 7:59 ` Neil Armstrong
2025-07-02 11:06 ` Krzysztof Kozlowski
2025-07-02 11:18 ` Krzysztof Kozlowski
2025-07-02 11:37 ` Vikash Garodia
2025-07-02 11:52 ` Krzysztof Kozlowski
2025-07-02 11:54 ` Krzysztof Kozlowski
2025-07-02 12:01 ` Vikash Garodia
2025-07-02 12:05 ` Krzysztof Kozlowski
2025-07-02 12:57 ` Vikash Garodia
2025-07-02 12:06 ` Bryan O'Donoghue
2025-07-02 22:26 ` Dmitry Baryshkov
2025-07-03 7:27 ` Krzysztof Kozlowski
2025-07-03 12:38 ` Konrad Dybcio
2025-07-03 12:54 ` Krzysztof Kozlowski
2025-07-03 15:28 ` Konrad Dybcio
2025-07-03 20:28 ` Bryan O'Donoghue
2025-07-03 21:23 ` Dmitry Baryshkov
2025-07-04 8:23 ` Bryan O'Donoghue
2025-07-04 10:28 ` Konrad Dybcio
2025-07-04 16:45 ` Dmitry Baryshkov
2025-07-04 22:44 ` Bryan O'Donoghue
2025-07-10 18:18 ` Prakash Gupta
2025-07-15 12:15 ` Konrad Dybcio
2025-07-04 19:15 ` Vikash Garodia
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=ebdbb517-ffa2-422a-989e-a4f19ab0163a@linaro.org \
--to=bryan.odonoghue@linaro.org \
--cc=abhinav.kumar@linux.dev \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.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_dikshita@quicinc.com \
--cc=quic_vgarodia@quicinc.com \
--cc=robh@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).