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.