linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ohaugan@codeaurora.org (Olav Haugan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 1/1] iommu-api: Add map_sg/unmap_sg functions
Date: Mon, 18 Aug 2014 15:47:56 -0700	[thread overview]
Message-ID: <53F2829C.2040809@codeaurora.org> (raw)
In-Reply-To: <20140818215553.GJ9809@8bytes.org>

On 8/18/2014 2:55 PM, Joerg Roedel wrote:
> On Mon, Aug 11, 2014 at 03:45:50PM -0700, Olav Haugan wrote:
>> +int default_iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
>> +			 struct scatterlist *sg, unsigned int nents,
>> +			 int prot, unsigned long flags)
>> +{
>> +	int ret = 0;
>> +	unsigned long offset = 0;
>> +	unsigned int i;
>> +	struct scatterlist *s;
>> +
>> +	for_each_sg(sg, s, nents, i) {
>> +		phys_addr_t phys = page_to_phys(sg_page(s));
>> +		size_t page_len = s->offset + s->length;
>> +
>> +		ret = iommu_map(domain, iova + offset, phys, page_len,
>> +				prot);
> 
> This isn't going to work, iova + offset, phys and page_len need to be
> aligned to the minimum page-size the given IOMMU implementation
> supports. See the iommu_map implementation for details.

If the alignment is not correct then iommu_map() will return error. Not
sure what other option we have here (and why make it different behavior
than iommu_map which just return error when it is not aligned properly).
I don't think we want to force any kind of alignment automatically. I
would rather have the API tell me I am doing something wrong than having
the function aligning the values and possibly undermap or overmap.

>> +int default_iommu_unmap_sg(struct iommu_domain *domain, unsigned long iova,
>> +			       size_t size, unsigned long flags)
> 
> Another asymmentry here, why don't you just pass a scatterlist and nents
> like in the map_sg function? if you implement it like this it is just a
> duplication of iommu_unmap().

Yes, I am aware of that. However, several people prefer this than
passing in scatterlist. It is not very convenient to pass a scatterlist
in some use cases. Someone mentioned a use case where they would have to
create a dummy sg list and populate it with the iova just to do an
unmap. I believe we would have to do this also. There is no use for
sglist when unmapping. However, would like to keep separate API from
iommu_unmap() to keep the API function names symmetric (map_sg/unmap_sg).

>> +static inline int iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
>> +			       struct scatterlist *sg, unsigned int nents,
>> +			       int prot, unsigned long flags)
>> +{
>> +	return domain->ops->map_sg(domain, iova, sg, nents, prot, flags);
>> +}
>> +
>> +static inline int iommu_unmap_sg(struct iommu_domain *domain,
>> +				 unsigned long iova, size_t size,
>> +				 unsigned long flags)
>> +{
>> +	return domain->ops->unmap_sg(domain, iova, size, flags);
>> +}
> 
> These function pointers need to be checked for != NULL before calling
> them.

I thought that was why we added the default fallback and set all the
drivers to point to these fallback functions. Several people wanted this
so that we don't have to have NULL-check in these functions (and have
the functions be simple inline functions).

Thanks,

Olav

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2014-08-18 22:47 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-11 22:45 [PATCH v5 0/1] Add iommu map_sg/unmap_sg API Olav Haugan
2014-08-11 22:45 ` [PATCH v5 1/1] iommu-api: Add map_sg/unmap_sg functions Olav Haugan
2014-08-12  1:35   ` Konrad Rzeszutek Wilk
2014-08-12 16:53     ` Olav Haugan
2014-08-12  1:51   ` Hiroshi Doyu
2014-08-12 10:48     ` Rob Clark
2014-08-12 16:56       ` Olav Haugan
2014-08-18 14:07         ` joro at 8bytes.org
2014-08-18 18:32           ` Rob Clark
2014-08-18 20:48             ` Olav Haugan
2014-08-18 21:26               ` joro at 8bytes.org
2014-08-18 21:32                 ` Olav Haugan
2014-08-12 16:55   ` Laurent Pinchart
2014-08-12 17:10     ` Olav Haugan
2014-08-18 21:55   ` Joerg Roedel
2014-08-18 22:47     ` Olav Haugan [this message]
2014-08-19 11:59       ` Joerg Roedel
2014-08-19 16:11         ` Laurent Pinchart
2014-08-19 18:40           ` Olav Haugan
2014-08-19 20:52             ` Laurent Pinchart
2014-08-20  5:21               ` Thierry Reding
2014-08-20 13:02               ` Konrad Rzeszutek Wilk
2014-08-20 14:15                 ` Laurent Pinchart
2014-08-19 18:37         ` Olav Haugan
2014-09-25 17:01   ` Joerg Roedel
2014-10-06 19:02     ` Olav Haugan
2014-10-15  9:16       ` Thierry Reding
2014-10-16 17:23         ` Olav Haugan
2014-10-17  9:09           ` Joerg Roedel

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=53F2829C.2040809@codeaurora.org \
    --to=ohaugan@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.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).