On 12/06/2012 04:00 PM, Lucas Stach wrote: > Am Donnerstag, den 06.12.2012, 15:49 +0800 schrieb Mark Zhang: [...] >> >> OK. So these relocation addresses are used to let userspace tells kernel >> which buffers mentioned in the command should be relocated to addresses >> which host1x clients able to reach. >> > Yep, preferably all buffers referenced by a command stream should > already be set up in such a position (CMA with Tegra2) or the relocation > should be nothing more than setting up IOMMU page tables (Tegra3). > >> I'm also wondering that, if our driver understands the stuffs in the >> commands, maybe we can find out all addresses in the command, in that >> way, we will not need userspace tells us which are the addresses need to >> be relocated, right? > > No. How will the kernel ever know which buffer gets referenced in a > command stream? All the kernel sees is is a command stream with > something like "blit data to address 0xADDR" in it. The only info that > you can gather from that is that there must be some buffer to blit into. > Neither do you know which buffer the stuff should be going to, nor can > you know if you blit to offset zero in this buffer. It's perfectly valid > to only use a subregion of a buffer. > > Or maybe I'm misunderstanding you and you mean it the other way around. > You don't let userspace dictate the addresses, the relocation > information just tells the kernel to find the addresses of the > referenced buffers for you and insert them, instead of the dummy > information, into the command stream. Yes, I think this is what I mean. No dummy information in the command stream, userspace just fills the address which it uses(actually this is cpu address of the buffer) in the command stream, and our driver must have a HashTable or something which contains the buffer address pair -- (cpu address, dma address), so our driver can find the dma addresses for every buffer then modify the addresses in the command stream. Hope I explain that clear. > > Regards, > Lucas > > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
