From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> To: Olav Haugan <ohaugan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> Cc: laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, will.deacon-5wv7dgnIgG8@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org, kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Subject: Re: [PATCH v5 1/1] iommu-api: Add map_sg/unmap_sg functions Date: Tue, 19 Aug 2014 13:59:54 +0200 [thread overview] Message-ID: <20140819115954.GC16329@8bytes.org> (raw) In-Reply-To: <53F2829C.2040809-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote: > 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. But sg->offset is an offset into the page (at least it is used that way in the DMA-API and since you do 'page_len = s->offset + s->length' you use it the same way). So when you pass iova + offset the result will no longer be page-aligned. You should force sg->offset == 0 and sg->length to be page-aligned instead. This makes more sense because the IOMMU-API works on (io)-page granularity and not on arbitrary phys-addr ranges like the DMA-API. > 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). Keeping it symetric is not more complicated, the caller just needs to keep the sg-list used for mapping around. I prefer the unmap_sg call to work in sg-lists too. > 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). Okay, since you add these call-backs to all drivers I think I can live with not doing a pointer check here. Joerg
WARNING: multiple messages have this Message-ID (diff)
From: joro@8bytes.org (Joerg Roedel) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v5 1/1] iommu-api: Add map_sg/unmap_sg functions Date: Tue, 19 Aug 2014 13:59:54 +0200 [thread overview] Message-ID: <20140819115954.GC16329@8bytes.org> (raw) In-Reply-To: <53F2829C.2040809@codeaurora.org> On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote: > 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. But sg->offset is an offset into the page (at least it is used that way in the DMA-API and since you do 'page_len = s->offset + s->length' you use it the same way). So when you pass iova + offset the result will no longer be page-aligned. You should force sg->offset == 0 and sg->length to be page-aligned instead. This makes more sense because the IOMMU-API works on (io)-page granularity and not on arbitrary phys-addr ranges like the DMA-API. > 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). Keeping it symetric is not more complicated, the caller just needs to keep the sg-list used for mapping around. I prefer the unmap_sg call to work in sg-lists too. > 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). Okay, since you add these call-backs to all drivers I think I can live with not doing a pointer check here. Joerg
next prev parent reply other threads:[~2014-08-19 11:59 UTC|newest] Thread overview: 58+ 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 ` Olav Haugan 2014-08-11 22:45 ` [PATCH v5 1/1] iommu-api: Add map_sg/unmap_sg functions Olav Haugan 2014-08-11 22:45 ` Olav Haugan [not found] ` <1407797150-515-2-git-send-email-ohaugan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2014-08-12 1:35 ` Konrad Rzeszutek Wilk 2014-08-12 1:35 ` Konrad Rzeszutek Wilk [not found] ` <20140812013559.GA25121-0iZWjJA6G8GSPmnEAIUT9EEOCMrvLtNR@public.gmane.org> 2014-08-12 16:53 ` Olav Haugan 2014-08-12 16:53 ` Olav Haugan 2014-08-12 1:51 ` Hiroshi Doyu 2014-08-12 1:51 ` Hiroshi Doyu 2014-08-12 10:48 ` Rob Clark 2014-08-12 10:48 ` Rob Clark 2014-08-12 16:56 ` Olav Haugan 2014-08-12 16:56 ` Olav Haugan [not found] ` <53EA472B.3020900-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2014-08-18 14:07 ` joro-zLv9SwRftAIdnm+yROfE0A 2014-08-18 14:07 ` joro at 8bytes.org [not found] ` <20140818140730.GC9809-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> 2014-08-18 18:32 ` Rob Clark 2014-08-18 18:32 ` Rob Clark [not found] ` <CAF6AEGtGmAQjMc5W5a6x5QiyUc8v0XHcsNAFe65Znc=DDKPS+w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-08-18 20:48 ` Olav Haugan 2014-08-18 20:48 ` Olav Haugan [not found] ` <53F266AE.40303-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2014-08-18 21:26 ` joro-zLv9SwRftAIdnm+yROfE0A 2014-08-18 21:26 ` joro at 8bytes.org [not found] ` <20140818212627.GI9809-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> 2014-08-18 21:32 ` Olav Haugan 2014-08-18 21:32 ` Olav Haugan 2014-08-12 16:55 ` Laurent Pinchart 2014-08-12 16:55 ` Laurent Pinchart 2014-08-12 17:10 ` Olav Haugan 2014-08-12 17:10 ` Olav Haugan 2014-08-18 21:55 ` Joerg Roedel 2014-08-18 21:55 ` Joerg Roedel 2014-08-18 22:47 ` Olav Haugan 2014-08-18 22:47 ` Olav Haugan [not found] ` <53F2829C.2040809-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2014-08-19 11:59 ` Joerg Roedel [this message] 2014-08-19 11:59 ` Joerg Roedel [not found] ` <20140819115954.GC16329-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> 2014-08-19 16:11 ` Laurent Pinchart 2014-08-19 16:11 ` Laurent Pinchart 2014-08-19 18:40 ` Olav Haugan 2014-08-19 18:40 ` Olav Haugan [not found] ` <53F39A18.70409-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2014-08-19 20:52 ` Laurent Pinchart 2014-08-19 20:52 ` Laurent Pinchart 2014-08-20 5:21 ` Thierry Reding 2014-08-20 5:21 ` Thierry Reding 2014-08-20 13:02 ` Konrad Rzeszutek Wilk 2014-08-20 13:02 ` Konrad Rzeszutek Wilk [not found] ` <20140820130250.GA3120-0iZWjJA6G8GSPmnEAIUT9EEOCMrvLtNR@public.gmane.org> 2014-08-20 14:15 ` Laurent Pinchart 2014-08-20 14:15 ` Laurent Pinchart 2014-08-19 18:37 ` Olav Haugan 2014-08-19 18:37 ` Olav Haugan 2014-09-25 17:01 ` Joerg Roedel 2014-09-25 17:01 ` Joerg Roedel [not found] ` <20140925170108.GE8306-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> 2014-10-06 19:02 ` Olav Haugan 2014-10-06 19:02 ` Olav Haugan 2014-10-15 9:16 ` Thierry Reding 2014-10-15 9:16 ` Thierry Reding 2014-10-16 17:23 ` Olav Haugan 2014-10-16 17:23 ` Olav Haugan 2014-10-17 9:09 ` Joerg Roedel 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=20140819115954.GC16329@8bytes.org \ --to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \ --cc=Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org \ --cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \ --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \ --cc=laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=ohaugan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \ --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=will.deacon-5wv7dgnIgG8@public.gmane.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.