similar to: [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,

On Sun, Jan 19, 2014 at 4:18 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > 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

That's great -- can you just confirm that this is what you did (every so often things work for the wrong reasons): (a) grabbed the ~darktama repo (b) took the MXM patch, futzed with the paths (since it was against the linux tree), applied it (c) took the patch off the mailing list, applied it (paths should have been fine) (d) DID NOT apply the vbios-pq1 patch in any form And then you built

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.

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()

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,

Hello everyone, The code is at /core/subdev/bios/init.c. When the executable is 0,these functions that parse the VBIOS init table seems to do nothing except the parsing. And in my opinion,init_exec_force does nothing,too! Then I tried to test it on my computer,when the VBIOS parser tries to change a MMIO register or call a function of struct nouveau_devinit (such as devinit->pll_set,etc.),it

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

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.

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

https://bugs.freedesktop.org/show_bug.cgi?id=60680 Priority: medium Bug ID: 60680 Assignee: nouveau at lists.freedesktop.org Summary: HDMI is connected and has mode, TV says "no signal" QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter:

Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/core/include/subdev/fb/regsnv04.h | 1 + nvkm/include/subdev/fb/regsnv04.h | 21 +++++++++++++++++++++ nvkm/subdev/devinit/fbmem.h | 18 ++---------------- nvkm/subdev/fb/ramnv04.c | 17 +---------------- 4 files changed, 25 insertions(+), 32 deletions(-) create mode 120000

https://bugs.freedesktop.org/show_bug.cgi?id=97620 Bug ID: 97620 Summary: [REGRESSION] KMS having issues after kernel upgrade (4.5.1-1 to 4.6.4-1) Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium

On Thu, Jan 25, 2018 at 10:35 PM, Lyude Paul <lyude at redhat.com> wrote: > Same as the previous patch, but for Kepler2 now > > Signed-off-by: Lyude Paul <lyude at redhat.com> > --- > drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 + > drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +-- > drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c | 62

Hi again, I got a new dmesg log with the debug parameters, but I guess I could not isolate VESA. I blacklisted it at /etc/modprobe.d/blacklist.conf but comparing those logs I see no difference... Is it possible to isolate VESA somehow without removing it? The new logs are here, I'm posting full content because I'm not sure what information is more relevant...

in RHOME/src/ : grep DevInit */*.[ch] reveals only a few calls such as if(!DevInit) error("No graphics device is active\n"); (in graphics/graphics.c and main/par.c). Couldn't we startup a default device instead of having the error message? The Default device would be Unix, interactive: x11 Unix, batch: postscript Win, interactive: windows Win, batch: postscript ??

The INA3221 is usually found on mid and high end kepler+ gpus Marins Patch implements the new iccsense subdev and all needed bits for the INA3221 power sensor. My Patch implements the hwmon power1 interface to expose the current power consumption through hwmon (and can be read out via sysfs or the sensors tool) Please test these patches for Fermi+ GPUs, that nothing gets messed up and works as

This is a complete rework from the first version I sent out. Now the implementation is more centered around the power_rails we find in the SENSE table instead of extdev centered. This makes the implementation a lot easier and straightforward. I've added support for the INA219, INA209 and INA3221 sensors found on multiple Fermi and Kepler cards. The power consumption is also exported via

This is a complete rework from the last version I sent out. Now the implementation is more centered around the power_rails we find in the SENSE table instead of extdev centered. This makes the implementation a lot easier and straightforward. I've added support for the INA219, INA209 and INA3221 sensors found on multiple Fermi and Kepler cards, but only the INA3221 bits are tested so far.

CCing linux-pci and Bjorn Helgaas. Maybe we could get better insights on how a reasonable fix would look like. Anyway, to me this entire issue looks like something which has to be fixed on a PCI level instead of inside a driver, so it makes sense to ask the pci folks if they have any better suggestions. Original cover letter: While investigating the runpm issues on my GP107 I noticed that