First version of host1x intro

[Mark Zhang]

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
> 
>