[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9bd83815-6f54-2efb-9398-42064f73ab1c@arm.com>
Date: Wed, 12 Feb 2020 14:04:31 +0000
From: Robin Murphy <robin.murphy@....com>
To: Roger Quadros <rogerq@...com>, Christoph Hellwig <hch@....de>,
Péter Ujfalusi <peter.ujfalusi@...com>,
Murali Karicheri <m-karicheri2@...com>,
"Nori, Sekhar" <nsekhar@...com>, "Anna, Suman" <s-anna@...com>
Cc: stefan.wahren@...e.com, afaerber@...e.de, hverkuil@...all.nl,
Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Nishanth Menon <nm@...com>,
"hdegoede@...hat.com" <hdegoede@...hat.com>
Subject: Re: dma_mask limited to 32-bits with OF platform device
On 12/02/2020 12:33 pm, Roger Quadros wrote:
[...]
> For now, let's say that we limit dma-ranges to 4GB size. with
> "dma-ranges = <0x00000000 0x00000000 0x1 0x00000000>;"
> Then, dma_bus_limit is set correctly to 0xffffffff, SATA driver sets
> masks to 64-bit as IP supports that.
>
> [ 13.306847] ahci 4a140000.sata: dma_mask 0xffffffffffffffff,
> coherent_mask 0xffffffffffffffff, dma_bus_limit 0xffffffff
>
> However, the SATA controller still tries to do DMA above 32-bits.
> dma_alloc() doesn't seem to be taking dma_bus_limit into account?
Yay ARM LPAE... Peter and Christoph have already been playing
whack-a-mole with other bugs under that config - is this with or without
SWIOTLB? (and whichever way, does the other work any better?)
Robin.
Powered by blists - more mailing lists