From: Laurentiu Tudor <laurentiu.tudor@nxp.com> To: Robin Murphy <robin.murphy@arm.com>, "hch@lst.de" <hch@lst.de>, "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> Cc: Leo Li <leoyang.li@nxp.com>, Diana Madalina Craciun <diana.craciun@nxp.com>, "davem@davemloft.net" <davem@davemloft.net>, Madalin-cristian Bucur <madalin.bucur@nxp.com> Subject: Re: [RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr() Date: Tue, 22 Oct 2019 13:53:14 +0000 [thread overview] Message-ID: <ab195e02-e7d5-2ca2-9fe0-f2175faf0072@nxp.com> (raw) In-Reply-To: <62561dca-cdd7-fe01-a0c3-7b5971c96e7e@arm.com> On 22.10.2019 16:25, Robin Murphy wrote: > On 22/10/2019 13:55, Laurentiu Tudor wrote: >> From: Laurentiu Tudor <laurentiu.tudor@nxp.com> >> >> Introduce a new dma map op called dma_addr_to_phys_addr() that converts >> a dma address to the physical address backing it up and add wrapper for >> it. > > I'd really love it if there was a name which could encapsulate that this > is *only* for extreme special cases of constrained descriptors/pagetable > entries/etc. where there's simply no practical way to keep track of a > CPU address alongside the DMA address, and the only option is this > potentially-arbitrarily-complex operation (I mean, on some systems it > may end up taking locks and poking hardware). > > Either way it's tricky - much as I don't like adding an interface which > is ripe for drivers to misuse, I also really don't want hacks like > bdf95923086f shoved into other APIs to compensate, so on balance I'd > probably consider this proposal ever so slightly the lesser evil. > >> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> >> --- >> include/linux/dma-mapping.h | 21 +++++++++++++++++++++ >> 1 file changed, 21 insertions(+) >> >> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h >> index 4a1c4fca475a..5965d159c9a9 100644 >> --- a/include/linux/dma-mapping.h >> +++ b/include/linux/dma-mapping.h >> @@ -132,6 +132,8 @@ struct dma_map_ops { >> u64 (*get_required_mask)(struct device *dev); >> size_t (*max_mapping_size)(struct device *dev); >> unsigned long (*get_merge_boundary)(struct device *dev); >> + phys_addr_t (*dma_addr_to_phys_addr)(struct device *dev, >> + dma_addr_t dma_handle); > > I'd be inclined to name the internal callback something a bit snappier > like .get_phys_addr. Alright. Want me to also rename the wrapper to something like dma_get_phys_addr()? Sounds a bit nicer to me. >> }; >> #define DMA_MAPPING_ERROR (~(dma_addr_t)0) >> @@ -442,6 +444,19 @@ static inline int dma_mapping_error(struct device >> *dev, dma_addr_t dma_addr) >> return 0; >> } >> +static inline phys_addr_t dma_addr_to_phys_addr(struct device *dev, >> + dma_addr_t dma_handle) >> +{ >> + const struct dma_map_ops *ops = get_dma_ops(dev); >> + >> + if (dma_is_direct(ops)) >> + return (phys_addr_t)dma_handle; > > Well that's not right, is it - remember why you had that namespace > collision? ;) > Ugh, correct. Don't know what I was thinking. Will rework the check. --- Thanks & Best Regards, Laurentiu
WARNING: multiple messages have this Message-ID (diff)
From: Laurentiu Tudor <laurentiu.tudor@nxp.com> To: Robin Murphy <robin.murphy@arm.com>, "hch@lst.de" <hch@lst.de>, "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> Cc: Madalin-cristian Bucur <madalin.bucur@nxp.com>, "davem@davemloft.net" <davem@davemloft.net>, Leo Li <leoyang.li@nxp.com> Subject: Re: [RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr() Date: Tue, 22 Oct 2019 13:53:14 +0000 [thread overview] Message-ID: <ab195e02-e7d5-2ca2-9fe0-f2175faf0072@nxp.com> (raw) In-Reply-To: <62561dca-cdd7-fe01-a0c3-7b5971c96e7e@arm.com> On 22.10.2019 16:25, Robin Murphy wrote: > On 22/10/2019 13:55, Laurentiu Tudor wrote: >> From: Laurentiu Tudor <laurentiu.tudor@nxp.com> >> >> Introduce a new dma map op called dma_addr_to_phys_addr() that converts >> a dma address to the physical address backing it up and add wrapper for >> it. > > I'd really love it if there was a name which could encapsulate that this > is *only* for extreme special cases of constrained descriptors/pagetable > entries/etc. where there's simply no practical way to keep track of a > CPU address alongside the DMA address, and the only option is this > potentially-arbitrarily-complex operation (I mean, on some systems it > may end up taking locks and poking hardware). > > Either way it's tricky - much as I don't like adding an interface which > is ripe for drivers to misuse, I also really don't want hacks like > bdf95923086f shoved into other APIs to compensate, so on balance I'd > probably consider this proposal ever so slightly the lesser evil. > >> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> >> --- >> include/linux/dma-mapping.h | 21 +++++++++++++++++++++ >> 1 file changed, 21 insertions(+) >> >> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h >> index 4a1c4fca475a..5965d159c9a9 100644 >> --- a/include/linux/dma-mapping.h >> +++ b/include/linux/dma-mapping.h >> @@ -132,6 +132,8 @@ struct dma_map_ops { >> u64 (*get_required_mask)(struct device *dev); >> size_t (*max_mapping_size)(struct device *dev); >> unsigned long (*get_merge_boundary)(struct device *dev); >> + phys_addr_t (*dma_addr_to_phys_addr)(struct device *dev, >> + dma_addr_t dma_handle); > > I'd be inclined to name the internal callback something a bit snappier > like .get_phys_addr. Alright. Want me to also rename the wrapper to something like dma_get_phys_addr()? Sounds a bit nicer to me. >> }; >> #define DMA_MAPPING_ERROR (~(dma_addr_t)0) >> @@ -442,6 +444,19 @@ static inline int dma_mapping_error(struct device >> *dev, dma_addr_t dma_addr) >> return 0; >> } >> +static inline phys_addr_t dma_addr_to_phys_addr(struct device *dev, >> + dma_addr_t dma_handle) >> +{ >> + const struct dma_map_ops *ops = get_dma_ops(dev); >> + >> + if (dma_is_direct(ops)) >> + return (phys_addr_t)dma_handle; > > Well that's not right, is it - remember why you had that namespace > collision? ;) > Ugh, correct. Don't know what I was thinking. Will rework the check. --- Thanks & 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-22 13:53 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 [this message] 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 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=ab195e02-e7d5-2ca2-9fe0-f2175faf0072@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.