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
On 30/01/2020 9.53, Christoph Hellwig wrote:
> [skipping the DT bits, as I'm everything but an expert on that..]
>
> On Mon, Jan 27, 2020 at 04:00:30PM +0200, Peter Ujfalusi wrote:
>> I agree on the phys_to_dma(). It should fail for addresses which does
>> not fall into any of the ranges.
>> It
Hi Christoph,
On 30/01/2020 18.40, Christoph Hellwig wrote:
> On Thu, Jan 30, 2020 at 03:04:37PM +0200, Peter Ujfalusi via iommu wrote:
>> On 30/01/2020 9.53, Christoph Hellwig wrote:
>>> [skipping the DT bits, as I'm everything but an expert on that..]
>>>
>>>
Hi Christoph,
On 30/01/2020 18.40, Christoph Hellwig wrote:
> On Thu, Jan 30, 2020 at 03:04:37PM +0200, Peter Ujfalusi via iommu wrote:
>> On 30/01/2020 9.53, Christoph Hellwig wrote:
>>> [skipping the DT bits, as I'm everything but an expert on that..]
>>>
>>>
Hi Christoph,
On 30/01/2020 18.40, Christoph Hellwig wrote:
> On Thu, Jan 30, 2020 at 03:04:37PM +0200, Peter Ujfalusi via iommu wrote:
>> On 30/01/2020 9.53, Christoph Hellwig wrote:
>>> [skipping the DT bits, as I'm everything but an expert on that..]
>>>
>>>
Hi Christoph,
On 03/02/2020 19.16, Christoph Hellwig wrote:
> dma_direct_supported tries to find the minimum addressable bitmask
> based on the end pfn and optional magic that architectures can use
> to communicate the size of the magic ZONE_DMA that can be used
> for bounce buffering. But
On 16/01/2020 21.13, Robin Murphy wrote:
> On 15/01/2020 11:50 am, Peter Ujfalusi wrote:
>>
>>
>> On 14/01/2020 20.19, Robin Murphy wrote:
>>> On 14/01/2020 4:43 pm, Peter Ujfalusi wrote:
The dma_pfn_offset should only be applied to an address which is
within the
dma-ranges range.
On 03/02/2020 19.08, Christoph Hellwig wrote:
> On Fri, Jan 31, 2020 at 04:00:20PM +0200, Peter Ujfalusi wrote:
>> I see. My PoC patch was not too off then ;)
>> So the plan is to have a generic implementation for all of the
>> architecture, right?
>
> І don't know of a concrete plan, but
On 14/01/2020 20.19, Robin Murphy wrote:
> On 14/01/2020 4:43 pm, Peter Ujfalusi wrote:
>> The dma_pfn_offset should only be applied to an address which is
>> within the
>> dma-ranges range. Any address outside should have offset as 0.
>
> No, that's wrong. If a non-empty dma-ranges is present,
The dma_pfn_offset should only be applied to an address which is within the
dma-ranges range. Any address outside should have offset as 0.
This is a proof of concept patch which works on k2g where we have
dma-ranges = <0x8000 0x8 0x 0x8000>;
for the SoC.
Without this patch
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:
>
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
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
14 matches
Mail list logo
