Maarten Lankhorst
2013-Jun-05 07:05 UTC
[Nouveau] [PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0
Hey, Op 04-06-13 20:38, Ilia Mirkin schreef:> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin <imirkin at 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 at 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: >> >> 1. 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. >> >> 2. 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. >> >> 3. 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. :-) If you fix that up, I'll stop being lazy and fix VP4 for nva3/a5/a8 in mesa. ;) ~Maarten
Ilia Mirkin
2013-Jun-05 07:16 UTC
[Nouveau] [PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0
On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst <maarten.lankhorst at 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 at 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 at 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: >>> >>> 1. 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. >>> >>> 2. 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. >>> >>> 3. 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 :) ) -ilia
Ben Skeggs
2013-Jun-11 05:49 UTC
[Nouveau] [PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0
On Wed, Jun 5, 2013 at 5:16 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:> On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst > <maarten.lankhorst at 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 at 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 at 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: >>>> >>>> 1. 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. >>>> >>>> 2. 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. >>>> >>>> 3. 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 at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
Maybe Matching Threads
- [PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0
- [PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0
- [PATCH v2] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0
- [PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0
- [PATCH] drm/nouveau/vdec: copy nvc0 bsp/vp/ppp to nv98