For what it's worth, I managed to get the engine to work in the simplest
mode (ie. decompressing LZO1X bytestream). Triggering the operation is
dead simple, and the whole thing is done in hw:
1. Destination and source have to be 0x100-byte aligned
2. Destination bufffer length is in bytes, but it's rounded up to a
multiple of 0x100
3. Poke source address >> 8 to base+0xa00
4. Poke source length, in bytes, to base+0xa04
5. Poke destination address >> 8 to base+0xa20
6. Poke destination buffer length, in bytes, to base+0xa24
7. Poke 1 to base+0xa1c
However, I haven't figured out error handling, or other operation modes
(there is at least one, judging by nv hardware - raw copy without
decompression, perhaps?).
The whole thing has a grand total of 17 MMIO registers, 9 of them
writable. Shouldn't be that hard to figure it out...
Marcin Kościelnicki
On 25/11/14 02:33, Andy Ritger wrote:
On Fri, Nov 21, 2014 at 01:39:55AM -0500, Ilia Mirkin wrote:
On Fri, Nov 21, 2014 at 1:16 AM, Andy Ritger <arit...@nvidia.com> wrote:
Hi Ilia,
Actually 0x90b8 is different than copy engine. I'm not very familiar
with it, but 0x90b8 is an engine for performing LZO decompression as
part of performing the copy. It has a variety of limitations (e.g.,
cannot handle blocklinear format), and was only in a few Fermi chips,
as I understand it.
According to our driver source, GF100, GF104, GF110, GF114, and GF116
all have it. [So GF106, GF108, GF117, GF119 don't have it.] We've only
had problems reported against GF116... and only for some people.
Hmm, some of our internal documentation is inconsistent about whether it
applies to GF100, but otherwise what I see matches your list. I guess
"few" was not entirely accurate.
It is probably easiest to just ignore it. You can distinguish this
decompress engine from normal copy engine by looking at the CE capability
register on falcon (0x00000650). If bit 2 is '1', then the falcon is
a decompress engine.
I presume you mean a +0x650 register on the pcopy engines (0x104000
and 0x105000). I only have access to the GF108 right now, which
returns 3 for 0x104650 and 4 for 0x105650. We're using the engine at
0x104000 for copy on the GF108...
Yes, 0x104650 and 0x105650 are the right addresses, from what I can tell.
FWIW, the other capability bits are:
bit 0: "DMACOPY_SUPPORTED"
bit 1: "PIXREMAP_SUPPORTED"
(I think PIXREMAP_SUPPORTED is in reference to the component remapping
controlled by methods 0x00000700, 0x00000704, and 0x00000708 in the
copy engine class).
From my admittedly limited understanding, both 0x104000 and 0x105000
appear to be falcon engines, where the fuc is presumably able to drive
some underlying hardware. The actual fifo methods are implemented in
the fuc, which in turn does iowr/etc commands.
Are you saying that the "decompress" engine (at 0x105000 right?) has a
different piece of hardware behind it than the copy engine at
0x104000, or does NVIDIA simply provide different fuc for it that
exposes somewhat different functionality via FIFO methods?
There is definitely a falcon at the frontend, and there is different
falcon ucode for "normal" copy engine versus the "decompress" engine.
But, I don't know off hand what dedicated hardware, if any, is behind it.
- Andy
I hope that helps,
- Andy
On Thu, Nov 20, 2014 at 02:18:02PM -0500, Ilia Mirkin wrote:
Hello,
There's a long-standing bug on nouveau (this is a sample bug, but the
issue has been around for a while:
https://bugs.freedesktop.org/show_bug.cgi?id=85465) whereby we attempt
to use the second PCOPY engine on GF116, and it is sometimes does
nothing, despite mmio register 22500 saying that it's not disabled
(0x22500 == 0 for this user). In the bug you can see a dump from
22400..22600, and all values after 22440 are read as 0. The issue
appears to be more common on mobile GF116's, but I don't know that the
correlation is 100%. No errors are reported by the FIFO or invalid
mmio reads, but the data transfer just does not happen. Switching to
using the first copy engine resolves things, so it's unlikely to be a
more systemic issue in nouveau's usage of the copy engine.
To be clear, when I'm talking about the second PCOPY engine, I'm
talking about the engine at mmio 0x105000, and whose fifo class id is
0x90b8.
Any information on properly detecting that the engine is, in fact,
missing, would be greatly appreciated. Or, conversely, an assurance
that the engine _is_ there on all GF116's and we're just not
initializing something properly, along with perhaps some suggestions
as to what we might be missing.
Thanks,
Ilia Mirkin
imir...@alum.mit.edu
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
