similar to: [REGRESSION] drm/g94/i2c: add aux channel interrupt driver

Hello Ben, commit (mini) [~/work/linux-2.6] git bisect bad 8777c5c11764d8336d8270f96778158c34c92108 is the first bad commit commit 8777c5c11764d8336d8270f96778158c34c92108 Author: Ben Skeggs <bskeggs at redhat.com> Date: Fri Jun 6 18:09:55 2014 +1000 drm/nouveau/dp: probe dpcd to determine connectedness Signed-off-by: Ben Skeggs <bskeggs at redhat.com> introduces a

This series does some refactoring in the GK20A's volt and clk drivers (fixing a few things while we are at it) to let GM20B benefit from the GK20A's logic with which it is compatible. GM20B is capable of more sophisticated (and power-efficient) reclocking which will follow later. Even after this more fancy reclocking is merged, the present logic will remain used in the lowest speedo of

Hello, [ 4.762826] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [ 5.025098] udevd[441]: starting version 175 [ 5.134411] i2c i2c-0: nForce2 SMBus adapter at 0x2140 [ 5.134585] i2c i2c-1: nForce2 SMBus adapter at 0x2100 [ 5.137320] ACPI: bus type USB registered [ 5.137444] usbcore: registered new interface driver usbfs [ 5.137535] usbcore: registered

On Fri, Jun 13, 2014 at 7:58 PM, Thomas Glanzmann <thomas at glanzmann.de> wrote: > Hello Ben, > commit Hey Thomas, Are you able to double-check that bisect? I'm not at all sure how that particular commit could trigger the issue you're seeing. Some of the others, certainly. It might be worth trying a couple of times before marking something as "good", in case

This series adds support for GM20B PLL's Maxwell features, namely glitchless switch and (more importantly) DFS support. DFS lets the PLL lower its output speed according to input current variations, making the clock more stable and allowing it to run safely at lower voltage. All GM20B additions are done in the last patch, which consequently ends up being considerably big ; fortunately, it

Hello everyone, the current git HEAD of Linus Torvalds tree breaks Nouveau on my Mac Mini Model 2010. I get variation of the following kernel panic when booting. (gateway) [~] nc -u -l -p 6666 [ 3.796018] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 3.796100] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 3.796304] ata1.00: ATA-7: INTEL SSDSA2M160G2GC, 2CV102HA, max

this is my first patch on the list through git send-mail and I hope everything is set up right, sorry for the noise here, but I don't want to try with an empty mail :) as the subject already says, this patch fixes one of the more serious issues while reclocking gddr5 on kepler cards. It works for me and for a bunch of others I met on IRC. Karol Herbst (1): pll/gk104: fix PLL instability

some chipset have working engine reclocking, but broken memory reclocking like Fermi. We should for now, add the functionality to allow partly reclocking for those. Allthough this doesn't give as much performance as one might wish, it is till noticeable and may improve performance enough to be noted. Karol Herbst (2): clk: seperate engine and memory reclock toggles clk: allow engine

Following a series of patches to improve nouveaus clock tree parsing. Reclocking these engines (all but memory) is pretty stable on the cards I've tested. Please review and merge when approved. These patches do not solve the problem that core/shader engine doesn't like to be clocked up too far without fb following, with visible corruption as a result. I suspect this problem is unrelated

Hi Ladies and Gentlemans. I'd like to report a possible bug and ask for help in solving it. I have a Mid 2010 Macbook Pro running Debian Jessie. The bug seems to happen at random, but mainly when using a 3D application with other apps running, such as Chromium (Chrome) and Iceweasel (Firefox). It happens when watching videos with VLC and mplayer2. I hope someone will manage to help. Thanks.

Is that an error that prevents anything from working? It's probably expected... On Thu, Jul 7, 2016 at 2:07 PM, abcd <abcdeluxe at web.de> wrote: > Thanks for the quick help! > > Indeed a kernel update resolved the issue, there one problem left > though: I get an error: > > Xorg.0.log: Couldn't load sub module "fb". > > I can't find out what

For some reason it seems to fail somewhere in either nouveau_display_create or nouveau_display_init. Kernel 3.16 is nearly 2 years old though, and countless changes and fixes have gone into the nouveau kernel driver since then. Does this still happen with a recent kernel? You can try a livecd from https://nouveau.pmoreau.org/ which has all the very latest nouveau-related software. On Wed, Jul 6,

Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c | 73 +++++++++++++++--------- drivers/gpu/drm/nouveau/core/subdev/clock/nva3.h | 2 +- drivers/gpu/drm/nouveau/core/subdev/fb/ramnva3.c | 2 +- 3 files changed, 48 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c

Hi, I am changing from proprietary nvidia drivers to Nouveau drivers in my mediacenter. I run a Gentoo linux in this hardware and I am facing an out of signal screen just after the boot (when the nouveau module is loaded). If I blacklist this module and modprobe it in the prompt, the screen gets out of signal in my 1080p TV in this moment. I tried recompile the kernel enabling and disabling a

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

Hello everyone, This set will switch the users of pm_runtime_put_autosuspend() to __pm_runtime_put_autosuspend() while the former will soon be re-purposed to include a call to pm_runtime_mark_last_busy(). The two are almost always used together, apart from bugs which are likely common. Going forward, most new users should be using pm_runtime_put_autosuspend(). Once this conversion is done and

dmesg output: --------------------------------------------------------------------------------------------------------- [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.16.0-38-generic (buildd at allspice) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #52~14.04.1-Ubuntu

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

This may not be the proper place to raise this question but I've had little luck elsewhere. After trying again, unsuccessfully this time, to install the proprietary NVIDIA driver, I've decided to focus my efforts on the open source Nouveau driver. I've seen video drivers blamed for varying degrees of "freeze on resume" but I'm not certain that's what I'm up

Hm, well you can see the messages about failure to set plls, which is why you don't see anything. The only odd thing I see is that you're using vesa, which can definitely mess things up. Try not using that. Also try booting with nouveau.debug=debug drm.debug=0xe which might provide more relevant info. On Jun 12, 2015 8:34 AM, "Andre Campos Rodovalho" <andre.rodovalho at