Displaying 20 results from an estimated 1000 matches similar to: "[PATCH 1/3] drm/nouveau: provide a way for devinit to mark engines as disabled"
2014 Jan 19
2
[PATCH] devinit: lock/unlock crtc regs for all devices, not just pre-nv50
Also make nv_lockvgac work for nv50+ devices. This should fix IO_CONDITION and
related VBIOS opcodes that read/write the crtc regs.
See https://bugs.freedesktop.org/show_bug.cgi?id=60680
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---
Ben, is this what you had in mind? I haven't gotten a chance to test this yet
since your tree doesn't build against mine (which is largely
2014 Jan 19
2
[PATCH] devinit: lock/unlock crtc regs for all devices, not just pre-nv50
No problem. I applied the patch (plus the other for the MXM issue),
replaced the preexisting nouveau.ko.gz in /lib/mod/? with the new
gzipped one, and rebuilt the initramfs. (With an updated DRIVER_DATE
define just to be sure.)
The HDMI output works fine.
Attached are the dmesg outputs before and after, grepped for
'nouveau'. As you can see, there's no real change.
On Sun, Jan 19,
2016 Feb 11
1
[PATCH] devinit/gf100-: detect if BIOS invoked devinit
It is not advisable to perform devinit if it has already been done.
VBIOS will very likely have invoked devinit if the GPU is the primary
graphics device, but there is no accurate way to detect this fact yet.
This patch adds such a method for gf100 and later chips, by means of the
NV_PTOP_SCRATCH1_DEVINIT_COMPLETED bit. This bit is set to 1 by devinit,
and reset to 0 when the GPU is powered.
2013 Jun 03
4
[PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0
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
2013 Sep 05
6
[PATCH 1/7] drm/nouveau: remove prototype for non-existent nouveau_connector_bpp
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---
drivers/gpu/drm/nouveau/nouveau_connector.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h b/drivers/gpu/drm/nouveau/nouveau_connector.h
index 6e399aa..4cefce3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -107,7 +107,4
2013 Nov 09
2
[PATCH] drm/nouveau/clk: Initial implementation for reclocking NVAA/NVAC
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
2014 Feb 12
2
[PATCH v2] drm/nouveau: support for platform devices
On 12/02/14 05:38, Alexandre Courbot wrote:
> Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead
> of PCI to which Nouveau is tightly dependent. This patch allows Nouveau
> to handle platform devices by:
>
> - abstracting PCI-dependent functions that were typically used for
> resource querying and page mapping,
> - introducing a nv_device_is_pci()
2014 Feb 11
2
[PATCH] drm/nouveau: support for platform devices
On Mon, Feb 10, 2014 at 8:50 PM, Thierry Reding
<thierry.reding at gmail.com> wrote:
> On Mon, Feb 10, 2014 at 02:53:00PM +0900, Alexandre Courbot wrote:
> [...]
>> diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c b/drivers/gpu/drm/nouveau/core/engine/device/base.c
> [...]
>> +resource_size_t
>> +nv_device_resource_start(struct nouveau_device *device,
2019 Jun 02
3
[PATCH 0/2] drm/nouveau/bios/init: Improve pre-PMU devinit opcode coverage
NVIDIA GPUs include a common scripting language (devinit) that can be
interpreted by a number of "engines", e.g. within a kernel-mode software
driver, the VGA BIOS or an on-board small microcontroller which provides
certain security assertions (the 'PMU').
This system allows a GPU programming sequence to be shared by multiple
entities that would not otherwise be able to execute
2014 Aug 24
8
[PATCH 1/3] subdev: add a pfuse subdev
We will use this subdev to disable temperature reading on cards that did not
get a sensor calibration in the factory.
Signed-off-by: Martin Peres <martin.peres at free.fr>
---
configure.ac | 1 +
drm/Kbuild | 4 ++
drm/core/include/subdev/fuse.h | 1 +
drm/core/subdev/fuse/base.c | 1 +
drm/core/subdev/fuse/g80.c | 1 +
2012 Jan 21
4
[NOT for merge] Patches that reduce power usage on NV86
This is more or less simplified series of patches that bring power usage on my
NV86 close to that of binary blob.
Best regards,
Maxim Levitsky
2014 Jan 09
0
[Bug 58378] [NV86] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version
https://bugs.freedesktop.org/show_bug.cgi?id=58378
--- Comment #74 from Andreas Loew <awl1 at gmx.net> ---
Just received
drivers/gpu/drm/nouveau/core/subdev/devinit/nv50.c:164: error:
'NVDEV_ENGINE_VIC' undeclared (first use in this function)
but "fixed" it for me by commenting out the lines for a 0xaf card (I have a
0x86 type anyway, so this code does not apply to me):
2014 Jul 26
5
[PATCH v2 0/3] drm/gk20a: support for reclocking
Second version of the gk20a clock patches. I have tried to keep the therm and
volt devices mandatory in the clock driver, but unfortunately they are too tied
to bios to allow this, at least for the moment. Consequently this version is
mostly a port of the first version to Ben's tree.
Ben, please let me know what I have done wrong in terms of integration to your
tree, as the main purpose of
2014 Jul 10
10
[PATCH 0/3] drm/gk20a: support for reclocking
This series adds support for reclocking on GK20A. The first two patches touch
the clock subsystem to allow GK20A to operate, by making the presence of the
thermal and voltage devices optional, and allowing pstates to be provided
directly instead of being probed using the BIOS (which Tegra does not have).
The last patch adds the GK20A clock device. Arguably the clock can be seen as a
stripped-down
2014 Dec 18
4
[RFC PATCH 0/3] introduce DVFS for GK20A
Hi,
This is a try to have some simple DVFS (Dynamic Voltage and Frequency Scaling)
support for GK20A. Instead of relying on other existing frequency scaling
framework, we create a simple subdev in Nouveau for the same purpose. That's
because we don't want to make the DVFS implementation for GK20A far more
than enough in the beginning and hinder the implementation for dGPU in the
future.
2014 May 12
1
[PATCH 1/2] device/nvf1: add support for 0xf1 (gk110b)
Signed-off-by: John Rowley <john.rowley08 at gmail.com>
---
nvkm/engine/device/nve0.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/nvkm/engine/device/nve0.c b/nvkm/engine/device/nve0.c
index 964c183..6e72f9c 100644
--- a/nvkm/engine/device/nve0.c
+++ b/nvkm/engine/device/nve0.c
@@ -208,6 +208,41 @@ nve0_identify(struct nouveau_device *device)
2014 Jul 10
3
[PATCH 3/3] drm/gk20a: reclocking support
Hey Alex,
Thanks. I have a couple of questions and remarks, but really, those
should be treated as discussion points rather than anything else.
Besides some inline comments, I was curious whether it is not necessary
to pause PFIFO and the engines like done with at least NVA3-NVAF? Or is
the transition smooth enough?
op 10-07-14 09:34, Alexandre Courbot schreef:
> Add support for
2012 Dec 05
2
[RFC PATCH] drm/nouveau: report channel owner in error messages
Full piglit run with this patch:
http://people.freedesktop.org/~mslusarz/chan_owners.txt
This patch covers only a small subset of all error messages, so:
Not-yet-signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com>
Comments? Ideas?
(This commit depends on this one:
http://people.freedesktop.org/~mslusarz/0001-drm-nouveau-split-fifo-interrupt-handler.patch )
---
2015 Jan 29
28
[Bug 88868] New: PowerPC e5500, kernel crash, GT520, GT610
https://bugs.freedesktop.org/show_bug.cgi?id=88868
Bug ID: 88868
Summary: PowerPC e5500, kernel crash, GT520, GT610
Product: xorg
Version: unspecified
Hardware: PowerPC
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Driver/nouveau
Assignee: nouveau at
2016 Apr 01
0
[PATCH] devinit/gf100: make devinit on resume safer
In case of successful suspend, devinit will have to be run and this is
the behavior currently hardcoded. However, as FD bug 94725 suggests,
there might be cases where runtime suspend leaves the GPU powered, and
in such cases devinit should not be run on resume.
On GF100+ we have a reliable way to know whether we need to run devinit.
Use it instead of blindly trusting the flag set by