On Fri, Mar 30, 2018 at 09:15:30AM +0200, Christoph Hellwig wrote:
> Can you resend the current state of affairs so we can get it in for
> 4.17?
Changes to the driver core and 3 different busses 2 days before 4.16 is
out, preventing any testing at all in linux-next? This needs to wait
for the
mu@lists.linux-foundation.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH] dma-mapping: move dma configuration to bus
> infrastructure
>
> Can you resend the current state of affairs so we can get it in for
> 4.17?
___
iommu
Can you resend the current state of affairs so we can get it in for
4.17?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
> Agree. There is no good point in duplicating the code.
> So this new API will be part of 'drivers/base/dma-mapping.c' file?
Yes.
> > As mention in my previous reply I think we don't even need a deconfigure
> > callback at this point - just remove the ACPI and OF wrappers and
> > clear the dma
>> +.dev_groups = amba_dev_groups,
>> +.match = amba_match,
>> +.uevent = amba_uevent,
>> +.pm = _pm,
>> +.dma_configure = amba_dma_configure,
>> +.dma_deconfigure= amba_dma_deconfigure,
>> +
Hi Nipun,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.16-rc5 next-20180313]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Tuesday, March 13, 2018 17:06
>
> On 12/03/18 15:24, Nipun Gupta wrote:
> > The change introduces 'dma_configure' & 'dma_deconfigure'as
> > bus callback functions so each bus can choose to implement
> > its
> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Tuesday, March 13, 2018 13:05
> > +int amba_dma_configure(struct device *dev)
> > +{
> > + enum dev_dma_attr attr;
> > + int ret = 0;
> > +
> > + if (dev->of_node) {
> > + ret =
On 12/03/18 15:24, Nipun Gupta wrote:
The change introduces 'dma_configure' & 'dma_deconfigure'as
bus callback functions so each bus can choose to implement
its own dma configuration function.
This eases the addition of new busses w.r.t. adding the dma
configuration functionality.
It's
> +int amba_dma_configure(struct device *dev)
> +{
> + enum dev_dma_attr attr;
> + int ret = 0;
> +
> + if (dev->of_node) {
> + ret = of_dma_configure(dev, dev->of_node);
> + } else if (has_acpi_companion(dev)) {
> + attr =
On Tue, Mar 13, 2018 at 04:22:53AM +, Nipun Gupta wrote:
> > Isn't this one or the other one but not both?
> >
> > Something like:
> >
> > if (dev->of_node)
> > of_dma_deconfigure(dev);
> > else
> > acpi_dma_deconfigure(dev);
> >
> > should work.
>
> I understand your point. Seems
bhelg...@google.com
> Cc: dmitry.torok...@gmail.com; rafael.j.wyso...@intel.com;
> jarkko.sakki...@linux.intel.com; linus.wall...@linaro.org; jo...@kernel.org;
> msucha...@suse.de; linux-ker...@vger.kernel.org; iommu@lists.linux-
> foundation.org; linux-...@vger.kernel.org
> Sub
On 3/12/2018 11:24 AM, Nipun Gupta wrote:
> + if (dma_dev->of_node) {
> + ret = of_dma_configure(dev, dma_dev->of_node);
> + } else if (has_acpi_companion(dma_dev)) {
> + attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
> + if (attr !=
13 matches
Mail list logo