[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <81C3A93C17462B4BBD7E272753C1057923B9DB3227@EXDCVYMBSTM005.EQ1STM.local>
Date: Mon, 10 Sep 2012 15:07:55 +0200
From: Sjur BRENDELAND <sjur.brandeland@...ricsson.com>
To: Ohad Ben-Cohen <ohad@...ery.com>
Cc: Linus Walleij <linus.walleij@...aro.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Sjur Brændeland <sjurbren@...il.com>
Subject: RE: Remoteproc: Translating between host and device addresses.
Hi Ohad,
> > One way for the device to figure out the translation between
> > host-physical and device-address is to peek into some CarveOut
> > resource entry and compute this translation. Because a CarveOut
> > resource entry contains both the host-physical-address and the
> > device address for the same memory location. But this feels
> > like a workaround, shouldn't we make a more explicit way of
> > communicating this mapping between host-physical and device
> > addresses?
>
> Yes, we should. The plan is, when relevant, to switch to the
> IOMMU-based DMA API to allocate device addresses (by programming the
> IOMMUs automatically), and stop sending physical addresses remotely.
But the vring descriptor table will still contain the host's physical address for the
buffers, right?
So how can the device then find the device-address of these buffers if we don't
use an IOMMU and have no address translation from host-physical-address
to device-address?
> For OMAP, btw, we will still provide those device->physical
> translation resource entries, because OMAP4 has a few remote
> components that access the host-physical memory directly.
Thanks,
Sjur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists