First version of host1x intro

[Mark Zhang]

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
>