search for: nv84

...ming. 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 i...

...ted 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 th...

...- factored out similar logic between vp and bsp into a new xtensa.c, similar to falcon - moved firmware loading to init rather than ctor (kinda wonder what happens if you suspend while playing a video... hmm.) - created new "blank" copies of vp/bsp for nv98+, identical to the old nv84 ones, but s/84/98/g At this point I have H.264 and MPEG1/2 working fairly well. Back when there were bugs in my mesa code, VP would freeze up sometimes and the watchdog would fire. I have no idea how to actually reset the engine though... so it's just a notification for now. These would hap...

...abri.fr> This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. Signed-off-by: Martin Peres <martin.peres at labri.fr> --- drivers/gpu/drm/nouveau/core/subdev/therm/nv84.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/nv84.c b/drivers/gpu/drm/nouveau/core/subdev/therm/nv84.c index 42ba633..8615d62 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/therm/nv84.c +++ b/drivers/gpu/drm/no...

From: Martin Peres <martin.peres at labri.fr> This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. v2: - do not limit this patch to nv84-a3 and make it nv84+ Signed-off-by: Martin Peres <martin.peres at labri.fr> --- drivers/gpu/drm/nouveau/core/subdev/therm/nv84.c | 19 ++++++++++++++++++- drivers/gpu/drm/nouveau/core/subdev/therm/nva3.c | 4 ++++ drivers/gpu/drm/nouveau/core/subdev/therm/nvd0.c | 4 ++++ 3 files changed,...

http://bugs.freedesktop.org/show_bug.cgi?id=25267 Summary: nv84 (GeForce 8600GT M) doesn't suspend with 2 cards but with 1 Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouv...

From: Martin Peres <martin.peres at labri.fr> This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. v2: - do not limit this patch to nv84-a3 and make it nv84+ v3: - move the ack to fini() - disable IRQs on fini() - silently ignore un-requested IRQs Signed-off-by: Martin Peres <martin.peres at labri.fr> --- drivers/gpu/drm/nouveau/core/subdev/therm/nv84.c | 17 +++++++++++++++-- drivers/gpu/drm/nouveau/core/subdev/therm...

From: Martin Peres <martin.peres at labri.fr> Some vbioses have extra useless entries after "the end" of the table. This is problematic since all of the vbios I found with this issue redefine the pwm freq divider to insane levels (52750 Hz instead of 2500), thus breaking fan management. The first solution to solve this mess would be to change the length of the table. The solution

...le, >>> 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...

...jections to instead sticking the ACK in a single fini() hook (along with additional code to disable all therm interrupts), and having the IRQ handle silently ignore any non-requested IRQs (see what the copy engine irq handler does, for example)? Ben. > > v2: > - do not limit this patch to nv84-a3 and make it nv84+ > > Signed-off-by: Martin Peres <martin.peres at labri.fr> > --- > drivers/gpu/drm/nouveau/core/subdev/therm/nv84.c | 19 ++++++++++++++++++- > drivers/gpu/drm/nouveau/core/subdev/therm/nva3.c | 4 ++++ > drivers/gpu/drm/nouveau/core/subdev/therm/nvd0....

...alcon 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...

uevent based fences hold a reference to the fence context, just like the legacy ones. So they need to drop this reference in the same way. Signed-off-by: Lucas Stach <dev at lynxeye.de> --- drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c index

...appen > succesfully. I'd *really* love to see proof of this. When channels die, all outstanding fences are marked as signalled. This should do absolutely nothing... > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> > --- > drivers/gpu/drm/nouveau/nv84_fence.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nv84_fence.c b/drivers/gpu/drm/nouveau/nv84_fence.c > index 2cf0ade..daf4b18 100644 > --- a/drivers/gpu/drm/nouveau/nv84_fence.c > +++ b/drivers/gpu/drm/nouveau/nv84_fence....

Signed-off-by: Martin Peres <martin.peres at free.fr> --- nvkm/subdev/therm/nv84.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/nvkm/subdev/therm/nv84.c b/nvkm/subdev/therm/nv84.c index 38b16d9..14e2e09 100644 --- a/nvkm/subdev/therm/nv84.c +++ b/nvkm/subdev/therm/nv84.c @@ -33,7 +33,12 @@ struct nv84_therm_priv { int nv84_temp_get(struct nouveau_...

...rst at canonical.com> wrote: >> This increases the chance slightly that recovery from lockup can happen >> succesfully. > I'd *really* love to see proof of this. When channels die, all > outstanding fences are marked as signalled. This should do absolutely > nothing... nv84+ heavily rely on fences though, and a race like this is possible: - channel 0 uses a bo from channel 1, queues a wait somewhere in the command stream for it. - channel 1 dies cleanly, but userspace creates a new channel in its place, fence counter is reset to 0. - channel 0 reaches the NV84_SUBCHAN...

https://bugs.freedesktop.org/show_bug.cgi?id=54359 Bug #: 54359 Summary: X crashes after resume (8600GT / NV84) Classification: Unclassified Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau...

https://bugs.freedesktop.org/show_bug.cgi?id=95330 Bug ID: 95330 Summary: [NV84] Hangs with gr: DATA_ERROR [INVALID_BITFIELD], TRAP_PROP [RT_FAULT], fb: trapped write [PGRAPH] [PROP] [RT0] [PAGE_NOT_PRESENT], bsp: Watchdog interrupt, engine hung Product: xorg Version: unspecified Hardwa...

This increases the chance slightly that recovery from lockup can happen succesfully. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nv84_fence.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nv84_fence.c b/drivers/gpu/drm/nouveau/nv84_fence.c index 2cf0ade..daf4b18 100644 --- a/drivers/gpu/drm/nouveau/nv84_fence.c +++ b/drivers/gpu/drm/nouveau/nv84_fence.c @@ -122,8 +122,11 @@ nv84_f...

...ONFIG_DRM_NOUVEAU_NV50) += core/subdev/bus/nv94.o +nouveau-$(CONFIG_DRM_NOUVEAU_NVC0) += core/subdev/bus/nvc0.o nouveau-y += core/subdev/clock/base.o -nouveau-y += core/subdev/clock/nv04.o -nouveau-y += core/subdev/clock/nv40.o -nouveau-y += core/subdev/clock/nv50.o -nouveau-y += core/subdev/clock/nv84.o -nouveau-y += core/subdev/clock/nva3.o -nouveau-y += core/subdev/clock/nvaa.o -nouveau-y += core/subdev/clock/nvc0.o -nouveau-y += core/subdev/clock/nve0.o +nouveau-$(CONFIG_DRM_NOUVEAU_NV04) += core/subdev/clock/nv04.o +nouveau-$(CONFIG_DRM_NOUVEAU_NV04) += core/subdev/clock/nv40.o +nouveau-$(CO...

...veau-y += core/subdev/bus/nvc0.o +nouveau-$(CONFIG_DRM_NOUVEAU_NVC0) += core/subdev/bus/nvc0.o nouveau-y += core/subdev/clock/base.o nouveau-y += core/subdev/clock/nv04.o nouveau-y += core/subdev/clock/nv40.o @@ -61,8 +61,8 @@ nouveau-y += core/subdev/clock/nv50.o nouveau-y += core/subdev/clock/nv84.o nouveau-y += core/subdev/clock/nva3.o nouveau-y += core/subdev/clock/nvaa.o -nouveau-y += core/subdev/clock/nvc0.o -nouveau-y += core/subdev/clock/nve0.o +nouveau-$(CONFIG_DRM_NOUVEAU_NVC0) += core/subdev/clock/nvc0.o +nouveau-$(CONFIG_DRM_NOUVEAU_NVC0) += core/subdev/clock/nve0.o nouveau-y +=...