On 02/04/18 11:20 AM, Jerome Glisse wrote:
> The point i have been trying to get accross is that you do have this
> information with dma_map_resource() you know the device to which you
> are trying to map (dev argument to dma_map_resource()) and you can
> easily get the device to which the memory
On 30/03/18 01:45 PM, Jerome Glisse wrote:
> Looking at upstream code it seems that the x86 bits never made it upstream
> and thus what is now upstream is only for ARM. See [1] for x86 code. Dunno
> what happen, i was convince it got merge. So yes current code is broken on
> x86. ccing Joerg mayb
On 02/04/18 01:16 PM, Jerome Glisse wrote:
> There isn't good API at the moment AFAIK, closest thing would either be
> lookup_resource() or region_intersects(), but a more appropriate one can
> easily be added, code to walk down the tree is readily available. More-
> over this can be optimize lik
On 29/03/18 07:58 PM, Jerome Glisse wrote:
> On Thu, Mar 29, 2018 at 10:25:52AM -0600, Logan Gunthorpe wrote:
>>
>>
>> On 29/03/18 10:10 AM, Christian König wrote:
>>> Why not? I mean the dma_map_resource() function is for P2P while other
>>> dma_map_* functions are only for system memory.
>>
>>
On Mon, Apr 02, 2018 at 01:32:37PM -0600, Logan Gunthorpe wrote:
>
>
> On 02/04/18 01:16 PM, Jerome Glisse wrote:
> > There isn't good API at the moment AFAIK, closest thing would either be
> > lookup_resource() or region_intersects(), but a more appropriate one can
> > easily be added, code to w
On Mon, Apr 02, 2018 at 11:37:07AM -0600, Logan Gunthorpe wrote:
>
>
> On 02/04/18 11:20 AM, Jerome Glisse wrote:
> > The point i have been trying to get accross is that you do have this
> > information with dma_map_resource() you know the device to which you
> > are trying to map (dev argument t
On Mon, Apr 02, 2018 at 11:02:10AM -0600, Logan Gunthorpe wrote:
>
>
> On 30/03/18 01:45 PM, Jerome Glisse wrote:
> > Looking at upstream code it seems that the x86 bits never made it upstream
> > and thus what is now upstream is only for ARM. See [1] for x86 code. Dunno
> > what happen, i was co
On Fri, Mar 30, 2018 at 12:46:42PM -0600, Logan Gunthorpe wrote:
>
>
> On 29/03/18 07:58 PM, Jerome Glisse wrote:
> > On Thu, Mar 29, 2018 at 10:25:52AM -0600, Logan Gunthorpe wrote:
> >>
> >>
> >> On 29/03/18 10:10 AM, Christian König wrote:
> >>> Why not? I mean the dma_map_resource() function
On Thu, Mar 29, 2018 at 11:33:34PM -0700, Christoph Hellwig wrote:
> On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote:
> > dma_map_resource() is the right API (thought its current implementation
> > is fill with x86 assumptions). So i would argue that arch can decide to
> > implement i
On 29/03/18 05:44 AM, Christian König wrote:
> Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe:
>>
>> On 28/03/18 01:44 PM, Christian König wrote:
>>> Well, isn't that exactly what dma_map_resource() is good for? As far as
>>> I can see it makes sure IOMMU is aware of the access route and
>>> tran
On 28/03/18 12:28 PM, Christian König wrote:
> I'm just using amdgpu as blueprint because I'm the co-maintainer of it
> and know it mostly inside out.
Ah, I see.
> The resource addresses are translated using dma_map_resource(). As far
> as I know that should be sufficient to offload all the a
On 28/03/18 10:02 AM, Christian König wrote:
> Yeah, that looks very similar to what I picked up from the older
> patches, going to read up on that after my vacation.
Yeah, I was just reading through your patchset and there are a lot of
similarities. Though, I'm not sure what you're trying to a
On 28/03/18 09:07 AM, Christian König wrote:
> Am 28.03.2018 um 14:38 schrieb Christoph Hellwig:
>> On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote:
>>> From: "wda...@nvidia.com"
>>>
>>> Add an interface to find the first device which is upstream of both
>>> devices.
>> Please wo
On 29/03/18 10:10 AM, Christian König wrote:
> Why not? I mean the dma_map_resource() function is for P2P while other
> dma_map_* functions are only for system memory.
Oh, hmm, I wasn't aware dma_map_resource was exclusively for mapping
P2P. Though it's a bit odd seeing we've been working under
On 28/03/18 01:44 PM, Christian König wrote:
> Well, isn't that exactly what dma_map_resource() is good for? As far as
> I can see it makes sure IOMMU is aware of the access route and
> translates a CPU address into a PCI Bus address.
> I'm using that with the AMD IOMMU driver and at least the
On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote:
> dma_map_resource() is the right API (thought its current implementation
> is fill with x86 assumptions). So i would argue that arch can decide to
> implement it or simply return dma error address which trigger fallback
> path into the
On Thu, Mar 29, 2018 at 10:25:52AM -0600, Logan Gunthorpe wrote:
>
>
> On 29/03/18 10:10 AM, Christian König wrote:
> > Why not? I mean the dma_map_resource() function is for P2P while other
> > dma_map_* functions are only for system memory.
>
> Oh, hmm, I wasn't aware dma_map_resource was exc
Am 29.03.2018 um 18:25 schrieb Logan Gunthorpe:
On 29/03/18 10:10 AM, Christian König wrote:
Why not? I mean the dma_map_resource() function is for P2P while other
dma_map_* functions are only for system memory.
Oh, hmm, I wasn't aware dma_map_resource was exclusively for mapping
P2P. Though i
Am 29.03.2018 um 17:45 schrieb Logan Gunthorpe:
On 29/03/18 05:44 AM, Christian König wrote:
Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe:
On 28/03/18 01:44 PM, Christian König wrote:
Well, isn't that exactly what dma_map_resource() is good for? As far as
I can see it makes sure IOMMU is aw
Sorry, didn't mean to drop the lists here. re-adding.
On Wed, Mar 28, 2018 at 4:05 PM, Alex Deucher wrote:
> On Wed, Mar 28, 2018 at 3:53 PM, Logan Gunthorpe wrote:
>>
>>
>> On 28/03/18 01:44 PM, Christian König wrote:
>>> Well, isn't that exactly what dma_map_resource() is good for? As far as
>
Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe:
On 28/03/18 01:44 PM, Christian König wrote:
Well, isn't that exactly what dma_map_resource() is good for? As far as
I can see it makes sure IOMMU is aware of the access route and
translates a CPU address into a PCI Bus address.
I'm using that wit
Am 28.03.2018 um 20:57 schrieb Logan Gunthorpe:
On 28/03/18 12:28 PM, Christian König wrote:
I'm just using amdgpu as blueprint because I'm the co-maintainer of it
and know it mostly inside out.
Ah, I see.
The resource addresses are translated using dma_map_resource(). As far
as I know that
Am 28.03.2018 um 18:25 schrieb Logan Gunthorpe:
On 28/03/18 10:02 AM, Christian König wrote:
Yeah, that looks very similar to what I picked up from the older
patches, going to read up on that after my vacation.
Yeah, I was just reading through your patchset and there are a lot of
similarities.
Am 28.03.2018 um 17:47 schrieb Logan Gunthorpe:
On 28/03/18 09:07 AM, Christian König wrote:
Am 28.03.2018 um 14:38 schrieb Christoph Hellwig:
On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote:
From: "wda...@nvidia.com"
Add an interface to find the first device which is upstre
Am 28.03.2018 um 14:38 schrieb Christoph Hellwig:
On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote:
From: "wda...@nvidia.com"
Add an interface to find the first device which is upstream of both
devices.
Please work with Logan and base this on top of the outstanding peer
to peer
On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote:
> From: "wda...@nvidia.com"
>
> Add an interface to find the first device which is upstream of both
> devices.
Please work with Logan and base this on top of the outstanding peer
to peer patchset.
__
From: "wda...@nvidia.com"
Add an interface to find the first device which is upstream of both
devices.
Signed-off-by: Will Davis
Signed-off-by: Christian König
---
drivers/pci/search.c | 24
include/linux/pci.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a
27 matches
Mail list logo
