Re: [PATCH 17/67] microblaze: rename dma_direct to dma_microblaze
On Fri, Dec 29, 2017 at 09:11:56PM +1100, Julian Calaby wrote: > Hi Christoph, > > On Fri, Dec 29, 2017 at 7:18 PM, Christoph Hellwig wrote: > > This frees the dma_direct_* namespace for a generic implementation. > > Don't you mean "dma_nommu" not "dma_microblaze" in the subject line? Yes, thanks. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
On Wed, Jan 03, 2018 at 07:19:46PM +1100, Julian Calaby wrote: > If this is indeed a linear mapping, can we just remove this and > replace it with the new "generic" mapping being introduced by this > patchset? That is the long-term plan. But as the powerpc one includes support for non-coherent DMA it will have to wait for the next batch. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
On Tue, Jan 02, 2018 at 08:45:30PM +1100, Michael Ellerman wrote: > Christoph Hellwig writes: > > > We want to use the dma_direct_ namespace for a generic implementation, > > so rename powerpc to the second best choice: dma_nommu_. > > I'm not a fan of "nommu". Some of the users of direct ops *are* using an > IOMMU, they're just setting up a 1:1 mapping once at init time, rather > than mapping dynamically. > > Though I don't have a good idea for a better name, maybe "1to1", > "linear", "premapped" ? It seems like a nice counter part to the dma_iommu_ops used just about anywhere else in ppc. But I'll happily take any maintainer bike shed decision for the next series. Remember that in a merge window or two it will hopefully go away in favor of the new generic dma_direct ops. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 27/67] dma-direct: add dma address sanity checks
On Fri, Dec 29, 2017 at 03:12:25PM +0100, Geert Uytterhoeven wrote:
> > +check_addr(struct device *dev, dma_addr_t dma_addr, size_t size,
> > + const char *caller)
> > +{
> > + if (unlikely(dev && !dma_capable(dev, dma_addr, size))) {
> > + if (*dev->dma_mask >= DMA_BIT_MASK(32)) {
> > + dev_err(dev,
> > + "%s: overflow %llx+%zu of device mask
> > %llx\n",
>
> Please use "%pad" to format dma_addr_t ...
>
> > + caller, (long long)dma_addr, size,
>
> ... and use &dma_addr.
>
> > + (long long)*dev->dma_mask);
>
> This cast is not needed, as u64 is unsigned long long in kernelspace on
> all architectures.
Thanks, fixed.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 02/67] alpha: mark jensen as broken
On Tue, Jan 02, 2018 at 11:36:00AM +0100, Geert Uytterhoeven wrote:
> Hi Christoph,
>
> On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig wrote:
> > CONFIG_ALPHA_JENSEN has failed to compile since commit aca05038
> > ("alpha/dma: use common noop dma ops"), so mark it as broken.
>
> unknown revision or path not in the working tree.
> Ah, you dropped the leading "6":
> 6aca0503847f6329460b15b3ab2b0e30bb752793
> is less than 2 years old, though.
I'll fix the reference.
But 23 month of a whole sub-architecture not compiling should still be
enough to mark it broken.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 30/67] dma-direct: retry allocations using GFP_DMA for small masks
On Tue, Jan 02, 2018 at 04:43:15PM +, Vladimir Murzin wrote:
> On 29/12/17 08:18, Christoph Hellwig wrote:
> > If we got back an allocation that wasn't inside the support coherent mask,
> > retry the allocation using GFP_DMA.
> >
> > Based on the x86 code.
> >
> > Signed-off-by: Christoph Hellwig
> > ---
> > lib/dma-direct.c | 25 -
> > 1 file changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/dma-direct.c b/lib/dma-direct.c
> > index ab81de3ac1d3..f8467cb3d89a 100644
> > --- a/lib/dma-direct.c
> > +++ b/lib/dma-direct.c
> > @@ -28,6 +28,11 @@ check_addr(struct device *dev, dma_addr_t dma_addr,
> > size_t size,
> > return true;
> > }
> >
> > +static bool dma_coherent_ok(struct device *dev, phys_addr_t phys, size_t
> > size)
> > +{
> > + return phys_to_dma(dev, phys) + size <= dev->coherent_dma_mask;
>
> Shouldn't it be: phys_to_dma(dev, phys) + size - 1 <= dev->coherent_dma_mask ?
Yes, I think it should. The existing code was blindly copy and pasted
from x86.
> > + if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> > + __free_pages(page, page_order);
> > + page = NULL;
> > +
> > + if (dev->coherent_dma_mask < DMA_BIT_MASK(32) &&
> > + !(gfp & GFP_DMA)) {
> > + gfp = (gfp & ~GFP_DMA32) | GFP_DMA;
> > + goto again;
>
> Shouldn't we limit number of attempts?
We only retty once anyway, due to the !GFP_DMA check first and then
ORing in GFP_DMA.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
