Re: First version of host1x intro

[Mark Zhang <nvmarkzhang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 12/07/2012 02:46 AM, Stephen Warren wrote:
> On 12/06/2012 01:13 AM, Mark Zhang wrote:
[...]
>>
>> 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.
> 
> Typically there would be no CPU address; there's no need in most cases
> to ever map most buffers to the CPU.
> 
> Automatically parsing the buffer sounds like an interesting idea, but
> then the kernel relocation code would have to know the meaning of every
> single register or command-stream "method" in order to know which of
> them take a buffer address as an argument. I am not familiar with this
> HW specifically, so perhaps it's much more regular than I think and it's
> actually easy to do that, but I imagine it'd be a PITA to implement that
> (although perhaps we have to for the command-stream validation stuff
> anyway?).

Yes. To make the driver understands all command stream stuffs is not an
easy and interesting work. And this part of codes need to be taken care
with each generation of tegra.

> Also, it'd be a lot quicker at least for larger command
> buffers to go straight to the few locations in the command stream where
> a buffer is referenced (i.e. use the side-band metadata for relocation)
> rather than having the CPU re-read the entire command stream in the
> kernel to parse it.
> 

Agree. Although we can categorize the commands and ignore the commands
which not take buffer address as arguments.