Christoph, Robin,
On 09/01/2020 16.49, Christoph Hellwig wrote:
> On Wed, Jan 08, 2020 at 03:20:07PM +, Robin Murphy wrote:
>>> The problem - I think - is that the DMA_BIT_MASK(32) from
>>> dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32)) is treated as physical
>>> address along the call path
On Wed, Jan 08, 2020 at 03:20:07PM +, Robin Murphy wrote:
>> The problem - I think - is that the DMA_BIT_MASK(32) from
>> dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32)) is treated as physical
>> address along the call path so the dma_pfn_offset is applied to it and
>> the check will fail, say
On 08/01/2020 2:00 pm, Peter Ujfalusi wrote:
Robin,
On 08/01/2020 14.21, Robin Murphy wrote:
On 08/01/2020 8:28 am, Peter Ujfalusi via iommu wrote:
Hi Christoph,
On 19/12/2019 17.20, Peter Ujfalusi wrote:
Hi Christoph,
On 19/12/2019 17.02, Christoph Hellwig wrote:
Hi Peter,
can you try th
Robin,
On 08/01/2020 14.21, Robin Murphy wrote:
> On 08/01/2020 8:28 am, Peter Ujfalusi via iommu wrote:
>> Hi Christoph,
>>
>> On 19/12/2019 17.20, Peter Ujfalusi wrote:
>>> Hi Christoph,
>>>
>>> On 19/12/2019 17.02, Christoph Hellwig wrote:
Hi Peter,
can you try the patch below (i
On 08/01/2020 8:28 am, Peter Ujfalusi via iommu wrote:
Hi Christoph,
On 19/12/2019 17.20, Peter Ujfalusi wrote:
Hi Christoph,
On 19/12/2019 17.02, Christoph Hellwig wrote:
Hi Peter,
can you try the patch below (it will need to be split into two):
Thank you!
Unfortunately it does not help:
Hi Christoph,
On 19/12/2019 17.20, Peter Ujfalusi wrote:
> Hi Christoph,
>
> On 19/12/2019 17.02, Christoph Hellwig wrote:
>> Hi Peter,
>>
>> can you try the patch below (it will need to be split into two):
>
> Thank you!
>
> Unfortunately it does not help:
> [0.596208] edma: probe of 27000
Hi Christoph,
On 19/12/2019 17.02, Christoph Hellwig wrote:
> Hi Peter,
>
> can you try the patch below (it will need to be split into two):
Thank you!
Unfortunately it does not help:
[0.596208] edma: probe of 270.edma failed with error -5
[0.596626] edma: probe of 2728000.edma fail
Hi,
On 09/07/2019 17.20, Christoph Hellwig wrote:
> The DMA API requires that 32-bit DMA masks are always supported, but on
> arm LPAE configs they do not currently work when memory is present
> above 4GB. Wire up the swiotlb code like for all other architectures
> to provide the bounce buffering
Hi Peter,
can you try the patch below (it will need to be split into two):
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index e822af0d9219..30b9c6786ce3 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -221,7 +221,8 @@ EXPORT_SYMBOL(arm_coherent_dma_
On Wed, Jul 24, 2019 at 07:23:50PM +0200, Nicolas Saenz Julienne wrote:
> Out of curiosity, what is the reason stopping us from using dma-direct/swiotlb
> instead of arm_dma_ops altogether?
Nothing fundamental. We just need to do a very careful piecemeal
migration as the arm code handles a ot of
On Tue, 2019-07-09 at 07:20 -0700, Christoph Hellwig wrote:
> The DMA API requires that 32-bit DMA masks are always supported, but on
> arm LPAE configs they do not currently work when memory is present
> above 4GB. Wire up the swiotlb code like for all other architectures
> to provide the bounce
The DMA API requires that 32-bit DMA masks are always supported, but on
arm LPAE configs they do not currently work when memory is present
above 4GB. Wire up the swiotlb code like for all other architectures
to provide the bounce buffering in that case.
Fixes: 21e07dba9fb11 ("scsi: reduce use of
12 matches
Mail list logo
