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,
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
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
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
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
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
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
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 @@
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
11 matches
Mail list logo
