| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
I missed an important part when porting the change over, fixing my
compiler warning but breaking -Werror=format-security.
Fixes: e6ff5ac4468e ("v3d: use snprintf(..., "%s", ...) instead of strncpy")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107443
|
| |
|
|
|
| |
Fixes a compiler warning about terminator NUL, based on f836d799f906
("intel/decoder: use snprintf(..., "%s", ...) instead of strncpy")
|
| |
|
|
|
|
|
| |
These will match the names that the CLIF parser expects to see. I may in
the future decide to change more of the other names so that I match the
names the HW/closed SW team uses for their packets, rather than the names
in the spec (which only they and I can read anyway).
|
| |
|
|
| |
The parser doesn't handle float input, so we have to dump the raw value.
|
| |
|
|
|
| |
The struct field names aren't part of the CLIF ABI, just the order of
fields within the struct. The comments are there for human readability.
|
| |
|
|
|
|
| |
V3D only has one of these (the top 16 bits of a float32) left in its CLs,
but VC4 had many more. This gets us proper pretty-printing of the values
instead of a large uint.
|
| |
|
|
|
| |
The parser doesn't expect them, so our fields would end up mismatched.
They're not really useful in console output, either.
|
| |
|
|
|
|
| |
Previously, we emitted in XML order, which I happen to type in the
decreasing offset order of the specifications. However, the CLIF parser
wants increasing offsets.
|
| |
|
|
|
|
|
| |
With CLIFs, the parser will choose an address for the buffer being
created, so we need to use effectively relocations to buffers instead of
the addresses that the driver uses. This is also a whole lot more
intelligible for console output than raw addresses!
|
| |
|
|
|
| |
The parser wants to see a 1 or 0. We can put "true" and "false" in a
comment to clarify that it's a boolean and the parser will skip it.
|
| |
|
|
|
|
| |
To generate CLIF files that the v3dv3 simulator can parse, we're going to
need to decode addresses, and for that we'll need the vaddr lookup
function from the clif structure from within v3d_decoder.
|
| |
|
|
| |
This lets the comments be ignored by the CLIF parser.
|
| |
|
|
|
| |
That's what a user should want to see, and what the CLIF parser wants.
This should maybe be generalized.
|
| |
|
|
|
|
|
| |
The XML zipper wants one XML per version for filling out its tables, but
we want to do more than one GPU version per XML now. Assume that the
"gen" field will be the same as min_ver and look up our XML text assuming
that they're listed in increasing min_ver.
|
| |
|
|
|
| |
This will be used to merge together the V3D 3.3-4.1 XML with the variants
disabled based on the version.
|
| |
|
|
|
|
|
|
|
|
| |
Right now, we name these fields as "field name minus one" so that your C
code obviously states what the value should be. However, it's easy enough
to handle at the codegen level with another little XML attribute, meaning
less C code and easier-to-read values in CLIF dumping and gdb as well.
(The actual CLIF format for simulator and FPGA replay takes in
pre-minus-one values, so we need it there too).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Groups containing fields smaller than a byte probably not being decoded
correctly. For example:
<group count="32" start="32" size="4">
<field name="Vertex Element Enables" start="0" end="3" type="uint"/>
</group>
gen_field_iterator_next would properly walk over each element of the
array, incrementing group_iter. However, the code to print the actual
values only considered iter->field->start/end, which are 0 and 3 in the
above example. So it would always fetch bits 3:0 of the current byte,
printing the same value over and over.
Cc: Eric Anholt <[email protected]>
|
| |
|
|
|
|
| |
VC5 introduces packet variants where the same opcode has behavior that is
decided by a sub-id field in the early bits of the packet. Keep iterating
over packets until we find the one with the matching sub-id.
|
| |
|
|
|
|
|
|
|
|
| |
I was writing the XML such that the address field overlapped various flags
in the alignment bits, which caused pain when trying to unpack for decode.
Instead, keep the XML matching the docs (address fields don't overlap),
and just infer the appropriate shift value during decode.
During pack, the address is just applied to the appropriate bits
already, ignoring the sub-byte start/end fields.
|
|
|
This is copied from Intel's XML decoder, modified to handle V3D's
byte-oriented packets.
v2: Squash in robher's fixes for Android
|
