First version of host1x intro

[Terje Bergström]

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).

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.

> 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.

> 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.

> 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. :-)

I'll add some notes about these to the doc.

Terje