First version of host1x intro

[Mark Zhang]

On 12/05/2012 05:47 PM, Terje Bergström wrote:
> Hi,
> 
[...]
> 
> Channels
> --------
> 
> Channel is a push buffer containing HOST1X opcodes. The push buffer
> boundaries are defined with `HOST1X_CHANNEL_DMASTART_0` and
> `HOST1X_CHANNEL_DMAEND_0`. `HOST1X_CHANNEL_DMAGET_0` indicates the next
> position within the boundaries that is going to be processes, and
> `HOST1X_CHANNEL_DMAPUT_0` indicates the position of last valid opcode.
> Whenever `HOST1X_CHANNEL_DMAPUT_0` and `HOST1X_CHANNEL_DMAGET_0` differ,
> command DMA will copy commands from push buffer to a command FIFO.
> 
> If command DMA sees opcode GATHER, it will a memory area to command
> FIFO. The number of words is indicated in GATHER opcode, and the base
> address is read from the following word. GATHERs are not recursive.
> 

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?

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?

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?

> HOST1X command processor goes through the FIFO and executes opcodes.
> Each channel has some stored state, such as the client unit this channel
> is talking to. The most important opcodes are:
>
[...]
> First action taken is taking a reference to all buffers in the command
> stream. This includes the command stream buffers themselves, but also
> the target buffers. We also map each buffer to target hardware to get a
> device virtual address.
> 
> After this, relocation information is processed. Each reference to
> target buffers in command stream are replaced with device virtual
> addresses. The relocation information contains the reference to target
> buffer, and to command stream to be able to do this.

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?

> 
> After relocation, each wait is checked against expiration. Any wait
> whose threshold has already expired will be converted to a no-wait by
> writing `0x00000000` over the word. This will essentially turn any
> expired wait into a wait for sync point register 0, value 0, and thus we
> keep sync point 0 reserved for this purpose and never change it from
> value 0.
> 
> In upstream kernel without IOMMU support we also check the contents of
> the command stream for any accesses to memory that are not taken care of
> by relocation information.
> 
[...]
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>