[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5126606.XdciyP3Dft@wuerfel>
Date: Fri, 30 Oct 2015 23:47:46 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Timur Tabi <timur@...eaurora.org>
Cc: Sinan Kaya <okaya@...eaurora.org>, dmaengine@...r.kernel.org,
cov@...eaurora.org, jcm@...hat.com,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Vinod Koul <vinod.koul@...el.com>,
Dan Williams <dan.j.williams@...el.com>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] dma: add Qualcomm Technologies HIDMA channel driver
On Friday 30 October 2015 16:55:16 Timur Tabi wrote:
>
> On 10/30/2015 04:42 PM, Sinan Kaya wrote:
> >>
> >> if (WARN_ON(!pdev->dev.dma_mask))
> >> return -ENXIO;
> >>
> >> The dma mask has to always be set by the platform code before probe()
> >> is called. If it is not set, you are not allowed to perform DMA.
> >
> > I tested this on an ACPI platform BTW when I was working on the initial
> > implementation.
>
> PowerPC sets the mask to 32 bits by default:
>
> http://lxr.free-electrons.com/ident?i=arch_setup_pdev_archdata
>
> Should we do something similar in ARM64? Today, we have to manually set
> the DMA mask in all drivers.
We set the dma mask from the 'dma-ranges' property of the parent device,
but fall back to 32-bit because we did not manage to mandate this property
in time for all arm64 machines to use.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists