search for: vdec

From: Ben Skeggs <bskeggs at redhat.com> The kernel previously exposed incorrect classes for some of the chipsets that this code supports. It no longer does, but the older object ioctls have compatibility to avoid breaking userspace. This needs to be fixed before switching over to the newer interfaces. Rather than hardcoding chipset->class like the rest of the driver does, this makes

On 26 November 2015 at 07:15, Ben Skeggs <skeggsb at gmail.com> wrote: > +static const struct nouveau_mclass > +nv98_decoder_msvld[] = { > + { 0x88b1, -1 }, > + { 0x86b1, -1 }, > + { 0x85b1, -1 }, > + {} > +}; > + > +static const struct nouveau_mclass > +nv98_decoder_mspdec[] = { > + { 0x88b2, -1 }, > + { 0x85b2, -1 }, > + {} > +};

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- I decided to let the user still specify config=BLA=1 to override the hw disable in case we get something wrong or for double-checking stuff, but I suspect it won't really be used much. I'm not terribly fond of the message text, if you come up with something better, feel free to drop it in.

...6.917639] nouveau [ PTHERM][0000:03:00.0] FAN control: none / external [ 6.917677] nouveau [ PTHERM][0000:03:00.0] fan management: automatic [ 6.917686] nouveau [ PTHERM][0000:03:00.0] internal sensor: yes [ 6.917714] nouveau [ CLK][0000:03:00.0] 03: core 200 MHz shader 400 MHz vdec 200 MHz [ 6.917732] nouveau [ CLK][0000:03:00.0] 05: core 300 MHz shader 600 MHz vdec 300 MHz [ 6.917744] nouveau [ CLK][0000:03:00.0] 07: core 350 MHz shader 800 MHz vdec 350 MHz [ 6.917756] nouveau [ CLK][0000:03:00.0] 0f: core 450 MHz shader 1100 MHz vdec 450 MHz [ 6.9...

...gt; P; + return clk->read(clk, nv_clk_src_crystal) >> P; + case 0x00000010: break; + case 0x00000020: return read_pll(clk, 0x004028) >> P; + case 0x00000030: return read_pll(clk, 0x004020) >> P; + } + break; + case nv_clk_src_mem: + return 0; + break; + case nv_clk_src_vdec: + P = (read_div(clk) & 0x00000700) >> 8; + + switch (mast & 0x00400000) { + case 0x00400000: + return clk->read(clk, nv_clk_src_core) >> P; + break; + default: + return 500000 >> P; + break; + } + break; + default: + break; + } + + nv_debug(priv, "u...

...gt; P; + return clk->read(clk, nv_clk_src_crystal) >> P; + case 0x00000010: break; + case 0x00000020: return read_pll(clk, 0x004028) >> P; + case 0x00000030: return read_pll(clk, 0x004020) >> P; + } + break; + case nv_clk_src_mem: + return 0; + break; + case nv_clk_src_vdec: + P = (read_div(clk) & 0x00000700) >> 8; + + switch (mast & 0x00400000) { + case 0x00400000: + return clk->read(clk, nv_clk_src_core) >> P; + break; + default: + return 500000 >> P; + break; + } + break; + default: + break; + } + + nv_debug(priv, "u...

...udio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio) decoder) ========================================================================== [AO OSS] audio_setup: Can't open audio device /dev/dsp: Device or resource busy AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Starting playback... VDec: vo config request - 320 x 240 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. VO: [xv] 320x240 => 320x240 Planar YV12 New_Face failed. Maybe the font path is wrong. Please supply the text font file (~/...

...HERM][0000:03:00.0] FAN control: none / > external > [ 6.917677] nouveau [ PTHERM][0000:03:00.0] fan management: automatic > [ 6.917686] nouveau [ PTHERM][0000:03:00.0] internal sensor: yes > [ 6.917714] nouveau [ CLK][0000:03:00.0] 03: core 200 MHz shader 400 > MHz vdec 200 MHz > [ 6.917732] nouveau [ CLK][0000:03:00.0] 05: core 300 MHz shader 600 > MHz vdec 300 MHz > [ 6.917744] nouveau [ CLK][0000:03:00.0] 07: core 350 MHz shader 800 > MHz vdec 350 MHz > [ 6.917756] nouveau [ CLK][0000:03:00.0] 0f: core 450 MHz shader >...

Reclocking of NVAA/NVAC is substantially different from NV50+, enough to justify a separate clock implementation. This code is a forward-port of reclocking code that has been sitting in a branch for a while, and has been tested on my NVAC. Traces show no significant reasons why this shouldn't work on NVAA, but testers are always welcome. And since these are IGPs without dedicated RAM to

For NV98+, BSP/VP/PPP are all FUC-based engines. Hook them all up in the same way as NVC0, but with a couple of different values. Also make sure that the PPP engine is handled in the fifo/mc/vm. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- It seems like VP4.0 is basically working here... only mpeg2/vc1 work, but I'm pretty sure that's just a user-side issue. My guess is

...edesktop.org/show_bug.cgi?id=58378 --- Comment #47 from Andreas Loew <awl1 at gmx.net> --- Hi - it's me again ;-) > Well, given that it doesn't work on the blob makes it sound like you have some > sort of funkiness in your hardware. One unsubstantiated theory is that the > vdec clock is *disabled*, and pcrypt is hooked up to that clock. Or perhaps > that clock is somehow broken. It'd be interesting to see whether the old blob > version can be made to work, but I wouldn't spend _too_ much time on it. May > be easy to do with an older livecd or something....

Hello everyone, I would need testers to check that this patch doesn't break working NVAA/NVAC configurations. It fixes an issue where some NVAC would hang on boot; if similar issues exist on NVAA, it may fix them too. You will find the patch below in two different versions: one will apply on Ben Skeggs' repository, the other one will apply on a regular Linux tree. Thanks in advance,

I have no idea what this bogus restriction on placement is, but it breaks decoding 1080p VDPAU at boot speed. With this patch applied I only need to bump the vdec clock to get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer moves. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index d506da5..86eb321 100644 --- a...

...gs schreef: > On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> I have no idea what this bogus restriction on placement is, but it breaks decoding 1080p >> VDPAU at boot speed. With this patch applied I only need to bump the vdec clock to >> get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer moves. > It's not bogus, and is required for pre-GF8 boards with VRAM > BAR size. > > What configuration does the buffer that's getting moved here have > exactly? The placement re...

https://bugs.freedesktop.org/show_bug.cgi?id=88272 Bug ID: 88272 Summary: [NVAC] Flickering screen on 1920x1080 monitor with 9400M in MacbookPro 5,5 Product: xorg Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

...IDE_SCREEN the width of the movie is doubled too. So I don't understand. I'd like to have the same resolution for encoding and for playing. eg. mplayer output: Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family [theora @ 0x892a230]Missing extradata! Could not open codec. VDecoder init failed :( Opening video decoder: [theora] Theora/VP3 VDec: vo config request - 640 x 480 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 2.37:1 - prescaling to correct movie aspect. VO: [xv] 640x480 => 1138x480 Planar YV12 Selected video...

...Input file file_1.yuv is neither a WAV nor YUV4MPEG2 file. so the error message is understandable for anyone. when this file is play with mplayer it shows as follow ========================================================================== Opening video decoder: [raw] RAW Uncompressed Video VDec: vo config request - 176 x 144 (preferred colorspace: Planar I420) VDec: using Planar I420 as output csp (no 0) Movie-Aspect is undefined - no prescaling applied. VO: [xv] 176x144 => 176x144 Planar I420 Selected video codec: [rawi420] vfm: raw (RAW I420) =========================================...

...explain the issues seen... Here you are: [aloew at aloew-lap nva]$ sudo ./nvapeek 154c 0000154c: 0000009c [aloew at aloew-lap nva]$ sudo ./nvapeek 1540 00001540: b1010001 Looking at the patch you provided, if the rusty binary arithmetics chip in my brain is still valid, this means for my case: vdec = nv_rd32(device, 0x1540) & 0x40000000; 0xb(...) = 1011(...) 0x4(...) = 0100(...) => for me, vdec indeed is 0x00000000, i.e. false and as my chipset is 0x86, furthermore: MPEG -> disabled VP -> disabled and for the dynamic features, 0x9c = 10011100 binary 0x20 = 00100000 binary...

https://bugs.freedesktop.org/show_bug.cgi?id=99913 Bug ID: 99913 Summary: [G96] Reclocking fails on voltage Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

Hello Ilia, > > [ 7.569394] nouveau [ DEVICE][0000:02:00.0] BOOT0 : 0x0ac080b1 > > [ 7.569460] nouveau [ DEVICE][0000:02:00.0] Chipset: MCP79/MCP7A (NVAC) > > [ 7.569530] nouveau [ DEVICE][0000:02:00.0] Family : NV50 > > [ 7.571151] nouveau [ VBIOS][0000:02:00.0] checking PRAMIN for image... > > [ 7.633082] nouveau [ VBIOS][0000:02:00.0]