From: Laurentiu Tudor <laurentiu.tudor@nxp.com> To: "hch@lst.de" <hch@lst.de> Cc: Robin Murphy <robin.murphy@arm.com>, "joro@8bytes.org" <joro@8bytes.org>, Ioana Ciocoi Radulescu <ruxandra.radulescu@nxp.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, Ioana Ciornei <ioana.ciornei@nxp.com>, Leo Li <leoyang.li@nxp.com>, Diana Madalina Craciun <diana.craciun@nxp.com>, "davem@davemloft.net" <davem@davemloft.net>, Madalin Bucur <madalin.bucur@nxp.com> Subject: Re: [RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr() Date: Thu, 24 Oct 2019 07:49:03 +0000 [thread overview] Message-ID: <ebbf742e-4d1f-ba90-0ed8-93ea445d0200@nxp.com> (raw) In-Reply-To: <20191024020140.GA6057@lst.de> On 24.10.2019 05:01, hch@lst.de wrote: > On Wed, Oct 23, 2019 at 11:53:41AM +0000, Laurentiu Tudor wrote: >> We had an internal discussion over these points you are raising and >> Madalin (cc-ed) came up with another idea: instead of adding this prone >> to misuse api how about experimenting with a new dma unmap and dma sync >> variants that would return the physical address by calling the newly >> introduced dma map op. Something along these lines: >> * phys_addr_t dma_unmap_page_ret_phys(...) >> * phys_addr_t dma_unmap_single_ret_phys(...) >> * phys_addr_t dma_sync_single_for_cpu_ret_phys(...) >> I'm thinking that this proposal should reduce the risks opened by the >> initial variant. >> Please let me know what you think. > > I'm not sure what the ret is supposed to mean, but I generally like > that idea better. It was supposed to be short for "return" but given that I'm not good at naming stuff I'll just drop it. > We also need to make sure there is an easy way > to figure out if these APIs are available, as they generally aren't > for any non-IOMMU API IOMMU drivers. I was really hoping to manage making them as generic as possible but anyway, I'll start working on a PoC and see how it turns out. This will probably happen sometime next next week as the following week I'll be traveling to a conference. --- Best Regards, Laurentiu
WARNING: multiple messages have this Message-ID (diff)
From: Laurentiu Tudor <laurentiu.tudor@nxp.com> To: "hch@lst.de" <hch@lst.de> Cc: Ioana Ciocoi Radulescu <ruxandra.radulescu@nxp.com>, Madalin Bucur <madalin.bucur@nxp.com>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Leo Li <leoyang.li@nxp.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, Ioana Ciornei <ioana.ciornei@nxp.com>, Robin Murphy <robin.murphy@arm.com>, "davem@davemloft.net" <davem@davemloft.net> Subject: Re: [RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr() Date: Thu, 24 Oct 2019 07:49:03 +0000 [thread overview] Message-ID: <ebbf742e-4d1f-ba90-0ed8-93ea445d0200@nxp.com> (raw) In-Reply-To: <20191024020140.GA6057@lst.de> On 24.10.2019 05:01, hch@lst.de wrote: > On Wed, Oct 23, 2019 at 11:53:41AM +0000, Laurentiu Tudor wrote: >> We had an internal discussion over these points you are raising and >> Madalin (cc-ed) came up with another idea: instead of adding this prone >> to misuse api how about experimenting with a new dma unmap and dma sync >> variants that would return the physical address by calling the newly >> introduced dma map op. Something along these lines: >> * phys_addr_t dma_unmap_page_ret_phys(...) >> * phys_addr_t dma_unmap_single_ret_phys(...) >> * phys_addr_t dma_sync_single_for_cpu_ret_phys(...) >> I'm thinking that this proposal should reduce the risks opened by the >> initial variant. >> Please let me know what you think. > > I'm not sure what the ret is supposed to mean, but I generally like > that idea better. It was supposed to be short for "return" but given that I'm not good at naming stuff I'll just drop it. > We also need to make sure there is an easy way > to figure out if these APIs are available, as they generally aren't > for any non-IOMMU API IOMMU drivers. I was really hoping to manage making them as generic as possible but anyway, I'll start working on a PoC and see how it turns out. This will probably happen sometime next next week as the following week I'll be traveling to a conference. --- Best Regards, Laurentiu _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-10-24 7:49 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-22 12:55 [RFC PATCH 0/3] dma-mapping: introduce a new dma api Laurentiu Tudor 2019-10-22 12:55 ` Laurentiu Tudor 2019-10-22 12:55 ` [RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr() Laurentiu Tudor 2019-10-22 12:55 ` Laurentiu Tudor 2019-10-22 13:25 ` Robin Murphy 2019-10-22 13:25 ` Robin Murphy 2019-10-22 13:53 ` Laurentiu Tudor 2019-10-22 13:53 ` Laurentiu Tudor 2019-10-23 11:53 ` Laurentiu Tudor 2019-10-23 11:53 ` Laurentiu Tudor 2019-10-24 2:01 ` hch 2019-10-24 2:01 ` hch 2019-10-24 7:49 ` Laurentiu Tudor [this message] 2019-10-24 7:49 ` Laurentiu Tudor 2019-10-24 11:04 ` Robin Murphy 2019-10-24 11:04 ` Robin Murphy 2019-10-24 11:27 ` Laurentiu Tudor 2019-10-24 11:27 ` Laurentiu Tudor 2019-10-22 12:55 ` [RFC PATCH 2/3] iommu/dma: wire-up new dma op dma_addr_to_phys_addr() Laurentiu Tudor 2019-10-22 12:55 ` Laurentiu Tudor 2019-10-22 12:55 ` [RFC PATCH 3/3] dpaa2_eth: use dma_addr_to_phys_addr() new dma api Laurentiu Tudor 2019-10-22 12:55 ` Laurentiu Tudor
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=ebbf742e-4d1f-ba90-0ed8-93ea445d0200@nxp.com \ --to=laurentiu.tudor@nxp.com \ --cc=davem@davemloft.net \ --cc=diana.craciun@nxp.com \ --cc=hch@lst.de \ --cc=ioana.ciornei@nxp.com \ --cc=iommu@lists.linux-foundation.org \ --cc=joro@8bytes.org \ --cc=leoyang.li@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=madalin.bucur@nxp.com \ --cc=netdev@vger.kernel.org \ --cc=robin.murphy@arm.com \ --cc=ruxandra.radulescu@nxp.com \ /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.