devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Prakash Gupta <quic_guptap@quicinc.com>,
	Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
	Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
	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>,
	linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/5] Introduce "non-pixel" sub node within iris video node
Date: Tue, 15 Jul 2025 14:15:49 +0200	[thread overview]
Message-ID: <bffc8478-4de9-4a9b-9248-96a936f20096@oss.qualcomm.com> (raw)
In-Reply-To: <25c64712-960a-50b4-e7fa-398e4bf809ef@quicinc.com>

On 7/10/25 8:18 PM, Prakash Gupta wrote:
> 
> 
> On 7/5/2025 4:14 AM, Bryan O'Donoghue wrote:
>> On 04/07/2025 17:45, Dmitry Baryshkov wrote:
>>> What about instead:
>>>
>>> - keep IOMMU entries as is
>> ack
>>
>>> - Add iommu-maps, mapping the non-pixel SID
>>> - In future expand iommu-maps, describing the secure contexts?
>>
>> Interesting, we are _adding_ so that's not an ABI break and if I'm
>> reading the documentation right, there's no hard rule on what iommu-map
>> defines i.e. nothing to preclude us from encoding the information we
>> want here.
>>
>> This might work.
>>
>> drivers/pci/controller/dwc/pcie-qcom.c::qcom_pcie_config_sid_1_9_0()
>>
>> You can register your platform device to the SID map you parse.
> 
> I see few limitations with using iommu-map here, some of these are
> listed in [1]
> 
> 1. We can't specify SMR mask with iommu-map.
> 2. We can't specify different iommu-addresses range for specific contexts.
> 3. The secure CB support [2] would require vmid information associated
> with per context. I think this can't be provided with iommu-map.

FWIW iommu-map should probably be evolved to support passing more
than one cell of iommu_spec in general.. For us specifically, it's
only a matter of time before some platform's PCIe controller
requires* we pass a non-zero SMR mask (unless we should be doing
that already somewhere..)

(* we can obviously do the masking manually and put the effective
values in dt, but "eeh")

Perhaps that can even be done without messing up backwards
compatiblity (treat it as pseudocode, def incomplete):

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 7043acd971a0..bca54035f90e 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2068,9 +2068,12 @@ int of_map_id(const struct device_node *np, u32 id,
               const char *map_name, const char *map_mask_name,
               struct device_node **target, u32 *id_out)
 {
+       const char *cells_prop_name __free(kfree);
        u32 map_mask, masked_id;
+       u32 cell_count;
        int map_len;
        const __be32 *map = NULL;
+       int ret;
 
        if (!np || !map_name || (!target && !id_out))
                return -EINVAL;
@@ -2084,7 +2087,15 @@ int of_map_id(const struct device_node *np, u32 id,
                return 0;
        }
 
-       if (!map_len || map_len % (4 * sizeof(*map))) {
+       cells_prop_name = kasprintf(GFP_KERNEL, "#%s-cells", map_name);
+       if (!cells_prop_name)
+               return -EINVAL;
+
+       ret = of_property_read_u32(np, cells_prop_name, &cell_count);
+       if (ret)
+               return ret;
+
+       if (!map_len || map_len % ((2 + cell_count + 1) * sizeof(*map))) {
                pr_err("%pOF: Error: Bad %s length: %d\n", np,
                        map_name, map_len);
                return -EINVAL;
@@ -2106,7 +2117,7 @@ int of_map_id(const struct device_node *np, u32 id,
                u32 id_base = be32_to_cpup(map + 0);
                u32 phandle = be32_to_cpup(map + 1);
                u32 out_base = be32_to_cpup(map + 2);
-               u32 id_len = be32_to_cpup(map + 3);
+               u32 id_len = be32_to_cpup(map + cell_count - 1);
 
                if (id_base & ~map_mask) {
                        pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores id-base (0x%x)\n",

Konrad

  reply	other threads:[~2025-07-15 12:15 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
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 [this message]
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=bffc8478-4de9-4a9b-9248-96a936f20096@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=dmitry.baryshkov@oss.qualcomm.com \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@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_guptap@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).