[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan
https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #23 from Maik Freudenberg --- @Daniel Drake: that's coherent with my investigations, even on a 740M without any outputs setting the bit at 0x488 changes the pci header type to 0x80, multifunction. My idea would be to use the pci_scan_single_device function to add the sub-function device. The really old fakephp driver available in kernels <2.29 would have been useful for general testing, but that's gone AWOL. The later one is useless, tested it. I also want to use the holyday break to do some development on this. What have you been thinking about? -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan
https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #22 from Daniel Drake --- Created attachment 136369 --> https://bugs.freedesktop.org/attachment.cgi?id=136369&action=edit GP104: enable HDMI audio device function On Asus GL502VS I investigated why the gfx device must be removed before rescan in the above workarounds. The reason is that when Linux first probes the device (before you attempt the workaround), pci_setup_device() notes that the device is not multifunction capable. This causes pci_scan_slot() to not bother scanning the non-zero functions (per the behaviour inside next_fn()). I checked and I found that when the 0x488 magic bit is not set, the gfx device advertises as non-multifunction. After the bit is set, the device advertises as multi-function. So, after setting the magic bit, removing the device will cause Linux to re-probe it during the next rescan, taking note at that point that it is a multi-function device, and proceeding to scan the functions, finding the audio device at function 1. Based on that I have a first attempt at a fix. It's not working though, audio output is silent (but I did have it working with the previous workarounds). I'll look closer next week. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 88272] [NVAC] Flickering screen on 1920x1080 monitor with 9400M in MacbookPro 5, 5
https://bugs.freedesktop.org/show_bug.cgi?id=88272 --- Comment #12 from mbazzino...@gmail.com --- I've got great news! I believe certain members of #nouveau and I have found a fix! `config=NvForcePost=1` append appropriately to your modprobe statement or use `nouveau.config=NvForcePost=1` in your kernel cmdline! I will use this setting longer and report back on its effectiveness at a later date. == Background Story == I noticed that screen flicker problems disappeared after waking from a `pm-suspend`. After reporting this to #nouveau, some more light was shed. see the following IRC snippet (more @ https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&date=2017-12-22) -- snip -- (regarding why pm-suspend solves the flicker bug) 15:58 imirkin: on resume we run the vbios scripts 15:58 imirkin: on boot, we probably don't because the vbios already has 16:02 imirkin: but it could be that the interpreter skimps on DP support and so some bits don't run 16:02 imirkin: or it could be something else entirely -- end -- == Tests == I have tested this new config option under the following scenarios 1) Boot with mDP adapter plugged in. OK 2) Boot without mDP adapter plugged in. Then, plug in after X has started. OK Because it works without the mDP adapter being plugged in on boot, it's safe to say that no "mDP hint" at bootup is required to get some "optional" vbios code to run. force POSTing is solving the problem, but we don't know why yet. What is happening differently from normal bootup by this force post? Perhaps another 2 mmiotrace bootup logs would shed light on this, or someone more familiar with gpu. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [bug report] null ptr deref in nouveau_platform_probe (tegra186-p2771-0000)
On Thu, Dec 21, 2017 at 02:37:59PM -0500, Anthony Eden wrote: > I applied the changes manually. This time, Xorg is actually starting... > > [ 16.862744] WARNING: CPU: 3 PID: 381 at > drivers/gpu/drm/nouveau/nouveau_bo.c:280 nouveau_bo_new+0x450/0x4d0 > [nouveau] > [ 16.87] Modules linked in: nouveau i2c_algo_bit ttm tegra_drm > gpio_keys drm_kms_helper drm drm_panel_orientation_quirks(P) host1x > dwmac_dwc_qos_eth stmmac_platform stmmac ptp pps_core > syscopyarea sysfillrect sysimgblt fb_sys_fops > [ 16.894001] CPU: 3 PID: 381 Comm: Xorg Tainted: P S > 4.15.0-rc3-next-20171214-ARCH-AEDEN+ #3 > [ 16.903546] Hardware name: NVIDIA Tegra186 P2771- Development Board > (DT) > [ 16.910578] pstate: 6005 (nZCv daif -PAN -UAO) > [ 16.915527] pc : nouveau_bo_new+0x450/0x4d0 [nouveau] > [ 16.920729] lr : nouveau_bo_new+0x78/0x4d0 [nouveau] > [ 16.925678] sp : 0a34bb40 > [ 16.928980] x29: 0a34bb60 x28: 8001f67f0598 > [ 16.934280] x27: x26: 8001c8858c00 > [ 16.939579] x25: 0002 x24: 0004 > [ 16.944878] x23: 0002 x22: > [ 16.950176] x21: x20: > [ 16.955475] x19: 8001c891d000 x18: 0080 > [ 16.960773] x17: ba6a7bc0 x16: 08294300 > [ 16.966072] x15: 0001 x14: 002f > [ 16.971370] x13: x12: bac20030 > [ 16.976667] x11: 0009 x10: 8001c8b7ce80 > [ 16.981964] x9 : 0004 x8 : 0001 > [ 16.987263] x7 : 0006 x6 : 000a > [ 16.992562] x5 : x4 : > [ 16.997860] x3 : 0004 x2 : 0005 > [ 17.003157] x1 : 0006 x0 : 8001c8b7ce8c > [ 17.008456] Call trace: > [ 17.011066] nouveau_bo_new+0x450/0x4d0 [nouveau] > [ 17.015924] nouveau_gem_new+0xa4/0x148 [nouveau] > [ 17.020771] nouveau_gem_ioctl_new+0x48/0xd8 [nouveau] > [ 17.025953] drm_ioctl_kernel+0x70/0xd8 [drm] > [ 17.030343] drm_ioctl+0x180/0x3e0 [drm] > [ 17.034424] nouveau_drm_ioctl+0x6c/0xc8 [nouveau] > [ 17.039207] do_vfs_ioctl+0xb0/0x730 > [ 17.042771] SyS_ioctl+0x8c/0xa8 > [ 17.045991] el0_svc_naked+0x20/0x24 > [ 17.049555] ---[ end trace d0b542d40499d1bb ]--- > [ 17.252701] nouveau 1700.gpu: fifo: read fault at 011000 > engine 06 [HOST0] client 06 [GPC0/L1_2] reason 02 [PTE] on channel 1 > [00f206d000 Xorg[381]] > [ 17.266694] nouveau 1700.gpu: fifo: channel 1: killed > [ 17.272090] nouveau 1700.gpu: fifo: runlist 0: scheduled for recovery > [ 17.278901] nouveau 1700.gpu: Xorg[381]: channel 1 killed! > > In case this is useful, I put the diff on my linux-next 2017-12-14 tree here: > https://github.com/aleden/scratch/blob/c16f5dcee60971b1fbdc6b9e6059fecbda27bf55/linux-next-2017-12-14.1.diff Looks like Ben updated his branch sometime between our mails, since the top three patches you seem to have ended up applying aren't the ones that I had in mind. Sorry about that. Specifically I think you need these three patches: https://github.com/skeggsb/nouveau/commit/46ae630592a9082eea0ba513f588faac1014b7ab https://github.com/skeggsb/nouveau/commit/56bd00148306b14ae7b7d683c755992f47539fcc https://github.com/skeggsb/nouveau/commit/0fbb2f642a1714626c945ec14c892dbf64bb4f22 The first of those you already have. I'm fairly certain that the second patch will fix the "fifo: read fault" errors. I'm curious, though, how you manage to X to get the GPU involved at all on a Jetson TX2. Are you setting up DRI_PRIME? Or using Mesa patches to enable a "renderonly" setup? Thanks, Thierry signature.asc Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
