From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Vikash Garodia <quic_vgarodia@quicinc.com>,
Dikshita Agarwal <quic_dikshita@quicinc.com>,
Abhinav Kumar <abhinav.kumar@linux.dev>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
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 2/5] media: iris: register and configure non-pixel node as platform device
Date: Wed, 2 Jul 2025 14:45:46 +0200 [thread overview]
Message-ID: <13046a5b-f66e-42f6-90e3-17f7adb709b4@oss.qualcomm.com> (raw)
In-Reply-To: <20250627-video_cb-v3-2-51e18c0ffbce@quicinc.com>
On 6/27/25 5:48 PM, Vikash Garodia wrote:
> Register "non_pixel" child node as a platform device, and configure its
> DMA via of_dma_configure(). This ensures proper IOMMU attachment and DMA
> setup for the "non_pixel" device.
> All non pixel memory, i.e bitstream buffers, HFI queues and internal
> buffers related to bitstream processing, would be managed by non_pixel
> device.
>
> Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
> ---
[...]
> + memset(&info, 0, sizeof(info));
> + info.fwnode = &np_node->fwnode;
> + info.parent = core->dev;
> + info.name = np_node->name;
> + info.dma_mask = DMA_BIT_MASK(32);
I'm not 1000% sure, but I fear that with the current description:
iris_resv: reservation-iris {
iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>,
<&iris_non_pixel 0x0 0xe0000000 0x0 0x20000000>;
};
this only works by luck, and once we introduce a platform that needs >32b
address space access, a change here will break the existing platforms, as
the higher parts are not forbidden.
We can work around it like the Tegra folks by filling out the upper size
dword, but I think it only further makes the iommu-addresses binding look
silly..
I'll submit a patch to (in my view) improve it soon
Konrad
next prev parent reply other threads:[~2025-07-02 12:45 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 [this message]
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
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=13046a5b-f66e-42f6-90e3-17f7adb709b4@oss.qualcomm.com \
--to=konrad.dybcio@oss.qualcomm.com \
--cc=abhinav.kumar@linux.dev \
--cc=bryan.odonoghue@linaro.org \
--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).