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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
