First version of host1x intro - dri-devel - freedesktop.org experimental mailing list

5 Dec 2012


      Hi,
I created a base for host1x introduction text, and pasted it into
https://gitorious.org/linux-tegra-drm/pages/Host1xIntroduction. For
convenience, I also copy it below.
As I've worked with all of this for so long, I cannot know what areas
are most interesting to you, so I just tried to put in the basics and
scope it to the features we've been discussing so far. Please point out
the features that you'd like more information on so I can add details.
2D is still totally missing from here. Everything is treated as generic
host1x clients. libdrm is touched on only briefly.
The text is written in LaTeX, and converted with pandoc. I beg for
forgiveness for any formatting oddities.
Hardware introduction
=====================
HOST1X is a front-end to a list of client units which deal with graphics
and multimedia. The most important features are channels for serializing
and offloading programming of the client units, and sync points for
synchronizing client units with each other, or with CPU.
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.
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:
-   SETCL for changing the target client unit
-   IMM, INCR, NONINCR, MASK write values to registers of client unit
-   GATHER instructs command DMA to fetch from another memory area
-   RESTART instructs command DMA to start over from beginning of push
    buffer
Channel class can also be HOST1X itself. Register writes to HOST1X will
invoke host class methods. The most important use is
`NV_CLASS_HOST_WAIT_SYNCPT_0`, which freezes a channel until sync point
reaches a threshold value.
Synchronization
---------------
A sync point is a 32-bit register in HOST1X. There are 32 sync points in
Tegra2 and Tegra3. HOST1X can be programmed to assert an interrupt when
a value higher than a pre-determined threshold is written to sync
pointer register. Each channel can also be frozen waiting for a
threshold to be reached.
Sync points are initialized to zero at boot-up, and treated as
monotonously incrementing counter with wrapping. CPU can increment a
sync point by writing the sync point id (0-31 in Tegra2 and Tegra3) to
register `HOST1X_SYNC_SYNCPT_CPU_INCR_0`. Client units all have sync
point increment method at offset 0, and the command streams request
client units to increment sync point using that. The parameters for the
increment method are condition and sync point id. Condition could be
`OP_DONE` telling to increment sync point when previous operations are
done, or `RD_DONE` indicating that client unit has finished all reads
from buffers.
Software
========
There are three components involved with programming HOST1X and its
client units. Linux kernel contains the drivers tegradrm and host1x.
User space library libdrm is added functionality to communicate with the
tegradrm, which communicates with host1x driver.
This text discusses only pieces relevant to HOST1X and its client units,
excluding the part about frame buffer and display controller
programming.
libdrm
======
libdrm communicates with tegradrm kernel driver to allocate buffers,
create and send command streams, synchronize.
TODO
tegradrm
========
tegradrm contains functionality to allocate buffers, and open channels.
The only channel available at the moment is 2D channel, which is handled
by the 2D driver inside tegradrm.
Command stream management and synchronization is passed on from 2D
driver to host1x driver. The 2D driver inside tegradrm processes the
requests from user space, and calls relevant calls in host1x.
host1x driver
=============
At bootup, host1x initializes hardware. It clears sync points, and
registers interrupt handlers.
Sync points
-----------
Each sync point register is treated as a range. The range minimum is a
shadow copy of the sync point register, and the maximum tracks how many
increments we expect to be done. A fence is a pair (sync point id,
threshold value) indicating completion of an event of interest to
software.
Due to wrapping, software does pre-checking for each sync point wait,
whether done via HOST1X channel, or CPU. Each wait is potentially for an
already expired fence. Any wait whose threshold value lies outside the
range ]min, max] is treated as already expired and will not be sent to
HOST1X hardware.
The sync point CPU wait is handled by registering the threshold value as
an event to the interrupt code, and waiting for completion of that
event.
Interrupt management
--------------------
HOST1X has two kinds of interrupt: generic and sync point. Generic
interrupts are not interesting in this scope, so this text focuses on
sync point threshold interrupts.
Interrupt code manages a sorted list of events, and their sync point
threshold values. The earliest event is kept first in the list.
`nvhost_intr_add_action()` adds an action to the event list. If the
event list was empty, HOST1X interrupt is programmed to assert interrupt
when that threshold is reached.
When an interrupt is asserted, the event list is processed. Each event
that has had its threshold passes will be moved to a completed list, and
removed from the event list. Submit complete is treated specially to
optimize for the fact that processing the event is heavy, so we call it
only once even though we have completed multiple submit complete events.
`action_submit_complete()` handles all clean-up for completed jobs.
`action_wakeup()` and `action_wakeup_interruptible()` wake up a thread
waiting for a particular sync point threshold.
After the list of events is processed, the value of the head of the list
is written to HOST1X as the next interrupt threshold.
Job management
--------------
Each command stream sent from user space to kernel is treated as a job.
User space indicates how many sync point increments that stream
generates, and which sync point register it’s using. It also indicates
the buffers involved with the command stream, and the locations in
command stream where the buffers are referred to. Last but not least,
user space indicates locations of sync point waits and thresholds.
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.
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.
Next, the number of sync point increments is checked and the id of the
sync point. The sync point maximum value is incremented by the number of
increments, and thus kernel ends up with a fence indicating when that
job has completed. Then each command stream is added to push buffer. In
case of IOMMU support, GATHER opcodes referring to the command streams
are added to the channel push buffer. If IOMMU isn’t supported, the
contents of the GATHER is copied. The fence is added to interrupt event
list as a submit complete action, and at this point the job is
submitted.
When a fence for a job is reached, `action_submit_complete()` will call
`nvhost_cdma_update()`. It goes through list of jobs in channel, and
frees the resources associated for all jobs whose fence has been
reached.
At submit time, we also start a timer for each job. If the timer times
out, the job is removed from the channel, and the sync point increments
that haven’t been done, will be done by the host1x driver. This prevents
channel from remaining stuck in case a command stream is formed
incorrectly and cannot be completed.