Re: [PATCH 5/6] dma-mapping: support fsl-mc bus
On 09/03/18 18:29, Nipun Gupta wrote:
-Original Message-
From: Christoph Hellwig [mailto:h...@lst.de]
Sent: Thursday, March 08, 2018 13:11
On Tue, Mar 06, 2018 at 04:41:56AM +, Nipun Gupta wrote:
Sorry for asking a trivial question - looking into dma_configure() I see that
PCI is used in the start and the end of the API.
In the end part pci_put_host_bridge_device() is called.
So are two bus callbacks something like 'dma_config_start' &
'dma_config_end'
will be required where the former one will return "dma_dev"?
I'd just use dma_configure as the callback.
This would be a decent stuff.
Yes, the PCI version should end up looking a lot like the old
pci_dma_configure() used to, before everything got pulled together.
Currently the of_dma_configure and acpi_dma_configure are only used
for PCI anyway, as no one else sets a non-NULL dma dev.
My understanding is that even the platform bus uses the of_dma_configure
and probably acpi_dma_configure too. So platform bus may also need the
callback implemented. Please correct me if my understanding is wrong.
Indeed, platform and AMBA will want an implementation to dispatch
between {of,acpi}_dma_configre() per the current logic. Host1x doesn't
seem to care about ACPI so probably wants its own just calling
of_dma_configure().
I will submit the patch with 'dma_configure' callback implemented for
the busses shortly.
Cheers - I've been trying to find some time to take a look myself, but
having something to review instead would certainly be easier :)
Robin.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 5/6] dma-mapping: support fsl-mc bus
> -Original Message- > From: Christoph Hellwig [mailto:h...@lst.de] > Sent: Thursday, March 08, 2018 13:11 > > On Tue, Mar 06, 2018 at 04:41:56AM +, Nipun Gupta wrote: > > Sorry for asking a trivial question - looking into dma_configure() I see > > that > > PCI is used in the start and the end of the API. > > In the end part pci_put_host_bridge_device() is called. > > So are two bus callbacks something like 'dma_config_start' & > 'dma_config_end' > > will be required where the former one will return "dma_dev"? > > I'd just use dma_configure as the callback. This would be a decent stuff. > > Currently the of_dma_configure and acpi_dma_configure are only used > for PCI anyway, as no one else sets a non-NULL dma dev. My understanding is that even the platform bus uses the of_dma_configure and probably acpi_dma_configure too. So platform bus may also need the callback implemented. Please correct me if my understanding is wrong. I will submit the patch with 'dma_configure' callback implemented for the busses shortly. > For fsl-mc I suspect only of_dma_configure is relevanet, so just call that > directly. > If at some point we get enough busses with either OF or ACPI we could > create a helper called from ->dma_configure for that. Totally agree with this. Thanks, Nipun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] dma-mapping: support fsl-mc bus
On Tue, Mar 06, 2018 at 04:41:56AM +, Nipun Gupta wrote: > Sorry for asking a trivial question - looking into dma_configure() I see that > PCI is used in the start and the end of the API. > In the end part pci_put_host_bridge_device() is called. > So are two bus callbacks something like 'dma_config_start' & 'dma_config_end' > will be required where the former one will return "dma_dev"? I'd just use dma_configure as the callback. Currently the of_dma_configure and acpi_dma_configure are only used for PCI anyway, as no one else sets a non-NULL dma dev. For fsl-mc I suspect only of_dma_configure is relevanet, so just call that directly. If at some point we get enough busses with either OF or ACPI we could create a helper called from ->dma_configure for that. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 5/6] dma-mapping: support fsl-mc bus
> From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Tuesday, March 06, 2018 0:22 > > On 05/03/18 18:39, Christoph Hellwig wrote: > > On Mon, Mar 05, 2018 at 03:48:32PM +, Robin Murphy wrote: > >> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's > >> software-discoverable and the only thing described in DT is the bus "host", > >> thus we need the same sort of thing as for PCI to map from the child > >> devices back to the bus root in order to find the appropriate firmware > >> node. Worse than PCI, though, we wouldn't even have the option of > >> describing child devices statically in firmware at all, since it's actually > >> one of these runtime-configurable "build your own network accelerator" > >> hardware pools where userspace gets to create and destroy "devices" as it > >> likes. > > > > I really hate the PCI special case just as much. Maybe we just > > need a dma_configure method on the bus, and move PCI as well as fsl-mc > > to it. > > Hmm, on reflection, 100% ack to that idea. It would neatly supersede > bus->force_dma *and* mean that we don't have to effectively pull pci.h > into everything, which I've never liked. In hindsight dma_configure() > does feel like it's grown into this odd choke point where we munge > everything in just for it to awkwardly unpick things again. > > Robin. +1 to the idea. Sorry for asking a trivial question - looking into dma_configure() I see that PCI is used in the start and the end of the API. In the end part pci_put_host_bridge_device() is called. So are two bus callbacks something like 'dma_config_start' & 'dma_config_end' will be required where the former one will return "dma_dev"? Regards, Nipun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] dma-mapping: support fsl-mc bus
On 05/03/18 18:39, Christoph Hellwig wrote: On Mon, Mar 05, 2018 at 03:48:32PM +, Robin Murphy wrote: Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's software-discoverable and the only thing described in DT is the bus "host", thus we need the same sort of thing as for PCI to map from the child devices back to the bus root in order to find the appropriate firmware node. Worse than PCI, though, we wouldn't even have the option of describing child devices statically in firmware at all, since it's actually one of these runtime-configurable "build your own network accelerator" hardware pools where userspace gets to create and destroy "devices" as it likes. I really hate the PCI special case just as much. Maybe we just need a dma_configure method on the bus, and move PCI as well as fsl-mc to it. Hmm, on reflection, 100% ack to that idea. It would neatly supersede bus->force_dma *and* mean that we don't have to effectively pull pci.h into everything, which I've never liked. In hindsight dma_configure() does feel like it's grown into this odd choke point where we munge everything in just for it to awkwardly unpick things again. Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] dma-mapping: support fsl-mc bus
On Mon, Mar 05, 2018 at 03:48:32PM +, Robin Murphy wrote: > Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's > software-discoverable and the only thing described in DT is the bus "host", > thus we need the same sort of thing as for PCI to map from the child > devices back to the bus root in order to find the appropriate firmware > node. Worse than PCI, though, we wouldn't even have the option of > describing child devices statically in firmware at all, since it's actually > one of these runtime-configurable "build your own network accelerator" > hardware pools where userspace gets to create and destroy "devices" as it > likes. I really hate the PCI special case just as much. Maybe we just need a dma_configure method on the bus, and move PCI as well as fsl-mc to it. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] dma-mapping: support fsl-mc bus
On 05/03/18 15:08, Christoph Hellwig wrote: We should not add any new hardocded busses here. Please mark them in OF/ACPI. Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's software-discoverable and the only thing described in DT is the bus "host", thus we need the same sort of thing as for PCI to map from the child devices back to the bus root in order to find the appropriate firmware node. Worse than PCI, though, we wouldn't even have the option of describing child devices statically in firmware at all, since it's actually one of these runtime-configurable "build your own network accelerator" hardware pools where userspace gets to create and destroy "devices" as it likes. Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] dma-mapping: support fsl-mc bus
We should not add any new hardocded busses here. Please mark them in OF/ACPI. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
