[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <HE1PR0401MB24251E99564CAA526F719ECCE6D90@HE1PR0401MB2425.eurprd04.prod.outlook.com>
Date: Tue, 6 Mar 2018 04:41:56 +0000
From: Nipun Gupta <nipun.gupta@....com>
To: Robin Murphy <robin.murphy@....com>, Christoph Hellwig <hch@....de>
CC: "will.deacon@....com" <will.deacon@....com>,
"mark.rutland@....com" <mark.rutland@....com>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"joro@...tes.org" <joro@...tes.org>, Leo Li <leoyang.li@....com>,
"shawnguo@...nel.org" <shawnguo@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
Bharat Bhushan <bharat.bhushan@....com>,
"stuyoder@...il.com" <stuyoder@...il.com>,
Laurentiu Tudor <laurentiu.tudor@....com>
Subject: RE: [PATCH 5/6] dma-mapping: support fsl-mc bus
> From: Robin Murphy [mailto:robin.murphy@....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 +0000, 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
Powered by blists - more mailing lists