On 12/06/2012 07:36 PM, Terje Bergström wrote: > On 06.12.2012 09:06, Mark Zhang wrote: >> Thank you for the doc. So here I have questions: >> >> Push buffer contains a lot of opcodes for this channel. So when multiple >> userspace processes submit jobs to this channel, all these jobs will be >> saved in the push buffer and return, right? I mean, nvhost driver will >> create a workqueue or something to pull stuffs out from the push buffer >> and process them one by one? > > Yes, "sync queue" contains the list of jobs that are pending (or that > kernel thinks are pending). > I see. > Push buffer in general case contains GATHER opcodes, which point to the > streams from user space. This way we don't have to copy command streams. > In case IOMMU is not available, we either have to copy the contents > directly to push buffer so user space can't modify it later (I'm trying > to implement this), or then we have to ensure the command streams cannot > be tampered with in some other way. > Yes, we have been talking about this for several days. >> Besides, "If command DMA sees opcode GATHER, it will allocate(you missed >> a verb here and I suppose it may be "allocate") a memory area to command >> FIFO" -- So why we need command FIFO, this extra component? Can't we >> just pass the correct address in push buffer to host1x clients? > > This is about the hardware, and the correct verb is "copy". HOST1X > hardware pre-fetches opcodes from push buffer and contents of GATHERs to > a FIFO to overcome memory latencies. The execution happens from FIFO. > > host1x clients don't know about push buffers. They're a feature of > HOST1X. HOST1X just interprets the opcodes and performs the operations > indicated, for example writes a value to a register of 2D. > > In general, the FIFO is invisible to users of HOST1X, but important to > understand when debugging stuck hardware. > Okay, so the command FIFO is not a part of memory we need to allocate. It's inside in every host1x clients. >> And when the host1x client starts working is controlled by userspace >> program, right? Because command DMA allocates the command FIFO when it >> sees opcode "GATHER". Or nvhost driver will generate "GATHER" as well, >> to buffer some opcodes then send them to host1x clients in one shot? > > FIFO is hardware inside HOST1X, so it's not allocated by user space or > kernel. > Got it. We just need to copy stuffs into FIFO. >> Could you explain more about this "relocation information"? I assume the >> "target buffers" here mentioned are some memory saving, e.g, textures, >> compressed video data which need to be decoded... >> But the userspace should already allocate the memory to save them, why >> we need to relocate? > > Lucas already did a better job of explaining than I could've, so I'll > pass. :-) > Yeah, I have known the idea. What I'm confused before is that why we need this reloc table because all mem are allocated from us(I mean, tegradrm/nvhost) so ideally we can find out all buffer related infos in the driver while userspace doesn't need to provide such informations. > I'll add some notes about these to the doc. > Thanks for the doc and it's really helpful. > Terje > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
