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 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 that's defintively what I'd like
to see.
> >> The
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..]
>>>
>>> On Mon, Jan 27, 2020 at 04:00:30PM
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..]
>>>
>>> On Mon, Jan 27, 2020 at 04:00:30PM
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..]
>>>
>>> On Mon, Jan 27, 2020 at 04:00:30PM
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..]
> >
> > On Mon, Jan 27, 2020 at 04:00:30PM +0200, Peter Ujfalusi wrote:
> >> I agree on the phys_to_dma().
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
[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 is just a that we in Linux don't have the concept atm
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 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. Any address outside should have offset as 0.
No, that's wrong.
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,
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, then addresses
which do not fall within any specified
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
13 matches
Mail list logo
