mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kumari Pallavi <kumari.pallavi@oss.qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: kpallavi@qti.qualcomm.com, srini@kernel.org,
	amahesh@qti.qualcomm.com, arnd@arndb.de,
	gregkh@linuxfoundation.org, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, quic_bkumar@quicinc.com,
	ekansh.gupta@oss.qualcomm.com, linux-kernel@vger.kernel.org,
	quic_chennak@quicinc.com, dri-devel@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	jingyi.wang@oss.qualcomm.com, aiqun.yu@oss.qualcomm.com,
	ktadakam@qti.qualcomm.com
Subject: Re: [PATCH v5 3/4] misc: fastrpc: Add support for new DSP IOVA formatting
Date: Mon, 8 Dec 2025 12:56:18 +0530	[thread overview]
Message-ID: <18c6b95a-961d-4544-856d-7dc08f7d5d74@oss.qualcomm.com> (raw)
In-Reply-To: <mlyaklczl4ngeckk7nle2xwmmzmqlphi6d47octomc5tewohh7@ipc2ik3kqj6q>



On 12/6/2025 8:00 AM, Dmitry Baryshkov wrote:
> On Tue, Dec 02, 2025 at 11:36:27AM +0530, Kumari Pallavi wrote:
>> Implement the new IOVA formatting required by the DSP architecture change
>> on Kaanapali SoC. Place the SID for DSP DMA transactions at bit 56 in the
>> physical address. This placement is necessary for the DSPs to correctly
>> identify streams and operate as intended.
>> To address this, set SID position to bit 56 via OF matching on the fastrpc
>> node; otherwise, default to legacy 32-bit placement.
>> This change ensures consistent SID placement across DSPs.
>>
>> Signed-off-by: Kumari Pallavi <kumari.pallavi@oss.qualcomm.com>
>> ---
>>   drivers/misc/fastrpc.c | 48 ++++++++++++++++++++++++++++++++++++------
>>   1 file changed, 41 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
>> index eb9501fe79bc..6a67daafeaa1 100644
>> --- a/drivers/misc/fastrpc.c
>> +++ b/drivers/misc/fastrpc.c
>> @@ -33,7 +33,6 @@
>>   #define FASTRPC_ALIGN		128
>>   #define FASTRPC_MAX_FDLIST	16
>>   #define FASTRPC_MAX_CRCLIST	64
>> -#define FASTRPC_PHYS(p)	((p) & 0xffffffff)
>>   #define FASTRPC_CTX_MAX (256)
>>   #define FASTRPC_INIT_HANDLE	1
>>   #define FASTRPC_DSP_UTILITIES_HANDLE	2
>> @@ -105,6 +104,17 @@
>>   
>>   #define miscdev_to_fdevice(d) container_of(d, struct fastrpc_device, miscdev)
>>   
>> +/* Extract smmu pa from consolidated iova */
> 
> Nit: SMMU, PA, IOVA
> 

ACK

>> +#define IPA_TO_DMA_ADDR(iova, sid_pos) (iova & ((1ULL << sid_pos) - 1ULL))
> 
> GENMASK?
> 

Thanks for the suggestion. I’ve updated the macro to use GENMASK_ULL 
instead of the hand‑rolled (1ULL << sid_pos) - 1ULL.
The new version looks like this:

#define IPA_TO_DMA_ADDR(iova, sid_pos) \
         ((sid_pos) ? ((iova) & GENMASK_ULL((sid_pos) - 1, 0)) : 0)


>> +/*
>> + * Prepare the consolidated iova to send to dsp by prepending the sid
> 
> Nit: DSP, SID, PA
> 

ACK

>> + * to smmu pa at the appropriate position
>> + */
>> +static inline u64 fastrpc_compute_sid_offset(u64 sid, u32 sid_pos)
>> +{
>> +	return sid << sid_pos;
>> +}
>> +
>>   struct fastrpc_phy_page {
>>   	dma_addr_t addr;	/* dma address */
>>   	u64 size;		/* size of contiguous region */
>> @@ -257,6 +267,10 @@ struct fastrpc_session_ctx {
>>   	bool valid;
>>   };
>>   
>> +struct fastrpc_soc_data {
>> +	u32 sid_pos;
>> +};
>> +
>>   struct fastrpc_channel_ctx {
>>   	int domain_id;
>>   	int sesscount;
>> @@ -278,6 +292,7 @@ struct fastrpc_channel_ctx {
>>   	bool secure;
>>   	bool unsigned_support;
>>   	u64 dma_mask;
>> +	const struct fastrpc_soc_data *soc_data;
>>   };
>>   
>>   struct fastrpc_device {
>> @@ -390,7 +405,7 @@ static int fastrpc_map_lookup(struct fastrpc_user *fl, int fd,
>>   static void fastrpc_buf_free(struct fastrpc_buf *buf)
>>   {
>>   	dma_free_coherent(buf->dev, buf->size, buf->virt,
>> -			  FASTRPC_PHYS(buf->dma_addr));
>> +			  IPA_TO_DMA_ADDR(buf->dma_addr, buf->fl->cctx->soc_data->sid_pos));
>>   	kfree(buf);
>>   }
>>   
>> @@ -440,7 +455,8 @@ static int fastrpc_buf_alloc(struct fastrpc_user *fl, struct device *dev,
>>   	buf = *obuf;
>>   
>>   	if (fl->sctx && fl->sctx->sid)
>> -		buf->dma_addr += ((u64)fl->sctx->sid << 32);
>> +		buf->dma_addr += fastrpc_compute_sid_offset((u64)fl->sctx->sid,
> 
> Drop type conversion
> 

ACK

>> +				 fl->cctx->soc_data->sid_pos);
>>   
>>   	return 0;
>>   }
>> @@ -685,7 +701,8 @@ static int fastrpc_dma_buf_attach(struct dma_buf *dmabuf,
>>   		return -ENOMEM;
>>   
>>   	ret = dma_get_sgtable(buffer->dev, &a->sgt, buffer->virt,
>> -			      FASTRPC_PHYS(buffer->dma_addr), buffer->size);
>> +			      IPA_TO_DMA_ADDR(buffer->dma_addr,
>> +					      buffer->fl->cctx->soc_data->sid_pos), buffer->size);
>>   	if (ret < 0) {
>>   		dev_err(buffer->dev, "failed to get scatterlist from DMA API\n");
>>   		kfree(a);
>> @@ -734,7 +751,8 @@ static int fastrpc_mmap(struct dma_buf *dmabuf,
>>   	dma_resv_assert_held(dmabuf->resv);
>>   
>>   	return dma_mmap_coherent(buf->dev, vma, buf->virt,
>> -				 FASTRPC_PHYS(buf->dma_addr), size);
>> +				 IPA_TO_DMA_ADDR(buf->dma_addr,
>> +						 buf->fl->cctx->soc_data->sid_pos), size);
>>   }
>>   
>>   static const struct dma_buf_ops fastrpc_dma_buf_ops = {
>> @@ -789,7 +807,8 @@ static int fastrpc_map_attach(struct fastrpc_user *fl, int fd,
>>   		map->dma_addr = sg_phys(map->table->sgl);
>>   	} else {
>>   		map->dma_addr = sg_dma_address(map->table->sgl);
>> -		map->dma_addr += ((u64)fl->sctx->sid << 32);
>> +		map->dma_addr += fastrpc_compute_sid_offset((u64)fl->sctx->sid,
> 
> Drop type conversion. Hmm. Looking at it, would it be better:
> 
> map->dma_addr = fastrpc_compute_dma_addr(fl->sctx, sg_dma_address(map->table->sgl))
> 

Thanks for the suggestion. To confirm: you’re proposing that the call 
site use a single helper returning the final DMA address, i.e.

map->dma_addr = fastrpc_compute_dma_addr(fl,
                                          sg_dma_address(map->table->sgl));
I can implement fastrpc_compute_dma_addr() as a thin wrapper that 
internally calls our existing fastrpc_compute_sid_offset() and composes 
the consolidated IOVA (SID in upper bits, base DMA/PA in lower bits)
?


>> +				 fl->cctx->soc_data->sid_pos);
>>   	}
>>   	for_each_sg(map->table->sgl, sgl, map->table->nents,
>>   		sgl_index)
>> @@ -2290,6 +2309,14 @@ static int fastrpc_get_domain_id(const char *domain)
>>   	return -EINVAL;
>>   }
>>   
>> +static const struct fastrpc_soc_data kaanapali_soc_data = {
>> +	.sid_pos = 56,
>> +};
>> +
>> +static const struct fastrpc_soc_data default_soc_data = {
>> +	.sid_pos = 32,
>> +};
>> +
>>   static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
>>   {
>>   	struct device *rdev = &rpdev->dev;
>> @@ -2298,6 +2325,11 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
>>   	const char *domain;
>>   	bool secure_dsp;
>>   	unsigned int vmids[FASTRPC_MAX_VMIDS];
>> +	const struct fastrpc_soc_data *soc_data;
>> +
>> +	soc_data = device_get_match_data(rdev);
>> +	if (!soc_data)
>> +		soc_data = &default_soc_data;
> 
> Define it for all the entries, drop if-check.
> 

ACK

>>   
>>   	err = of_property_read_string(rdev->of_node, "label", &domain);
>>   	if (err) {
>> @@ -2350,6 +2382,7 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
>>   
>>   	secure_dsp = !(of_property_read_bool(rdev->of_node, "qcom,non-secure-domain"));
>>   	data->secure = secure_dsp;
>> +	data->soc_data = soc_data;
>>   
>>   	switch (domain_id) {
>>   	case ADSP_DOMAIN_ID:
>> @@ -2487,7 +2520,8 @@ static int fastrpc_rpmsg_callback(struct rpmsg_device *rpdev, void *data,
>>   }
>>   
>>   static const struct of_device_id fastrpc_rpmsg_of_match[] = {
>> -	{ .compatible = "qcom,fastrpc" },
>> +	{ .compatible = "qcom,kaanapali-fastrpc", .data = &kaanapali_soc_data },
>> +	{ .compatible = "qcom,fastrpc", .data = &default_soc_data },
>>   	{ },
>>   };
>>   MODULE_DEVICE_TABLE(of, fastrpc_rpmsg_of_match);
>> -- 
>> 2.34.1
>>
> 
Thanks,
Pallavi

  reply	other threads:[~2025-12-08  7:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-02  6:06 [PATCH v5 0/4] Add ADSP and CDSP support on Kaanapali SoC Kumari Pallavi
2025-12-02  6:06 ` [PATCH v5 1/4] dt-bindings: misc: qcom,fastrpc: Add compatible for Kaanapali Kumari Pallavi
2025-12-02  8:17   ` Krzysztof Kozlowski
2025-12-02 10:01     ` Kumari Pallavi
2025-12-05  8:33       ` Krzysztof Kozlowski
2025-12-02  6:06 ` [PATCH v5 2/4] misc: fastrpc: Rename phys to dma_addr for clarity Kumari Pallavi
2025-12-06  2:26   ` Dmitry Baryshkov
2025-12-08  7:08     ` Kumari Pallavi
2025-12-02  6:06 ` [PATCH v5 3/4] misc: fastrpc: Add support for new DSP IOVA formatting Kumari Pallavi
2025-12-06  2:30   ` Dmitry Baryshkov
2025-12-08  7:26     ` Kumari Pallavi [this message]
2025-12-09 22:52       ` Dmitry Baryshkov
2025-12-02  6:06 ` [PATCH v5 4/4] misc: fastrpc: Update dma_bits for CDSP support on Kaanapali SoC Kumari Pallavi
2025-12-06  2:31   ` Dmitry Baryshkov
2025-12-08  7:04     ` Kumari Pallavi
2025-12-09 22:55       ` Dmitry Baryshkov

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=18c6b95a-961d-4544-856d-7dc08f7d5d74@oss.qualcomm.com \
    --to=kumari.pallavi@oss.qualcomm.com \
    --cc=aiqun.yu@oss.qualcomm.com \
    --cc=amahesh@qti.qualcomm.com \
    --cc=arnd@arndb.de \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ekansh.gupta@oss.qualcomm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jingyi.wang@oss.qualcomm.com \
    --cc=kpallavi@qti.qualcomm.com \
    --cc=krzk+dt@kernel.org \
    --cc=ktadakam@qti.qualcomm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_bkumar@quicinc.com \
    --cc=quic_chennak@quicinc.com \
    --cc=robh@kernel.org \
    --cc=srini@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

all inboxes | Powered by JetHome®