On Wed, Jun 5, 2013 at 5:16 PM, Ilia Mirkin imirkin@alum.mit.edu wrote:
On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst maarten.lankhorst@canonical.com wrote:
Hey,
Op 04-06-13 20:38, Ilia Mirkin schreef:
On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin imirkin@alum.mit.edu wrote:
These chipsets include the VP2 engine which is composed of a bitstream processor (BSP) that decodes H.264 and a video processor (VP) which can do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are driven by separate xtensa chips embedded in the hardware. This patch provides the mechanism to load the kernel for the xtensa chips and provide the necessary interactions to do the rest of the work.
Signed-off-by: Ilia Mirkin imirkin@alum.mit.edu
This patch applies on top of nouveau/master (16a41bcc8).
This seems to work for me. There was one boot where my userspace component didn't work right, but it could just as well be a bug there. Subsequent attempts seem to work fine. Note that I'm not particularly familiar with any of this stuff, so if something looks odd, I probably didn't know any better. I did try to faithfully reproduce whatever the blob did. A few questions/thoughts:
There's a LOT of similarity between BSP and VP setup/etc. Is it worth it to create a core/xtensa.c or some such, similar to falcon.c? Since it's only in two places, not that much code, and there _are_ differences, I decided to keep them separate.
Firmware naming. Maarten suggested to use the falcon naming style, which is nv$chipset_fuc$offset. However here, all the chips share the same firmware. Also the offset would be 103 vs 00f, and is a little arbitrary. (And fuc doesn't apply here... xt? xtensa?) I've left it the way I had it: nv84_bsp and nv84_vp.
Firmware load time. I chose to load the fw into memory in the ctor, and then copy it in in init, due to some potentially bogus suspend/resume concerns. Also e.g. mplayer likes to create/destroy decoders at startup a few times. The downside is that ~200KB of memory is gone. Let me know if I should change it to do the request_firmware in init.
There's obviously a userspace piece to this, which I'm still working on. But right now I have it working within certain parameters (e.g. 1280x544 videos), and I'm relatively confident it can be completed without further kernel-side changes.
There's also a hypothetical concern of "what if we create an open firmware with a different user API". Ideally there'd be some way to expose what kind of firmware is loaded, but I think that can be left for "later".
I also happened to notice that NV98, NVA1+ refer to these nv84 engines (in drivers/gpu/drm/nouveau/core/engine/device/nv50.c). I assume that means I should create a new nv98.c version of BSP/VP that resembles the old versions of nv84.c, and point device/nv50.c at those for nv98 and nva1+?
nv98+ should really have an implementation more like nvc0, and the copy engine is a good example on what conversion is needed to do it. :-)
That should probably be a separate patch, no? Do you mean something more falcon-y? (It still needs firmware, right?) I think I should just avoid changing things on those cards in this patch... (Also the only NV card I have access to is my NV96, so I'll be more likely to keep playing with that :) )
Just a note that I haven't forgotten about this. I'm just finish off a few things, and I'll give my comments at the end of the week!
Maarten, if you're reading this, same goes for your nvd7 branch :)
Ben.
-ilia _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel