[Nouveau] [PATCH V4 09/26] drm/nouveau: deprecate pci_get_bus_and_slot()
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot()
and extract the domain number from
1. struct pci_dev
2. struct pci_dev through drm_device->pdev
3. struct pci_dev through fb->subdev->drm_device->pdev
Signed-off-by: Sinan Kaya
---
drivers/gpu/drm/nouveau/dispnv04/arb.c | 4 +++-
drivers/gpu/drm/nouveau/dispnv04/hw.c| 10 +++---
drivers/gpu/drm/nouveau/nouveau_drm.c| 3 ++-
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c | 10 +-
4 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c
b/drivers/gpu/drm/nouveau/dispnv04/arb.c
index 90075b6..c79160c 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
@@ -213,8 +213,10 @@ struct nv_sim_state {
if ((dev->pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
(dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
uint32_t type;
+ int domain = pci_domain_nr(dev->pdev->bus);
- pci_read_config_dword(pci_get_bus_and_slot(0, 1), 0x7c, &type);
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
+ 0x7c, &type);
sim_data.memory_type = (type >> 12) & 1;
sim_data.memory_width = 64;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c
b/drivers/gpu/drm/nouveau/dispnv04/hw.c
index b985990..0c9bdf0 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
@@ -216,12 +216,15 @@
{
struct nvkm_pll_vals pllvals;
int ret;
+ int domain;
+
+ domain = pci_domain_nr(dev->pdev->bus);
if (plltype == PLL_MEMORY &&
(dev->pdev->device & 0x0ff0) == CHIPSET_NFORCE) {
uint32_t mpllP;
-
- pci_read_config_dword(pci_get_bus_and_slot(0, 3), 0x6c, &mpllP);
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 3),
+ 0x6c, &mpllP);
mpllP = (mpllP >> 8) & 0xf;
if (!mpllP)
mpllP = 4;
@@ -232,7 +235,8 @@
(dev->pdev->device & 0xff0) == CHIPSET_NFORCE2) {
uint32_t clock;
- pci_read_config_dword(pci_get_bus_and_slot(0, 5), 0x4c, &clock);
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 5),
+ 0x4c, &clock);
return clock / 1000;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 8d4a5be..33b6139 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -524,7 +524,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
}
/* subfunction one is a hdmi audio device? */
- drm->hdmi_device = pci_get_bus_and_slot((unsigned int)pdev->bus->number,
+ drm->hdmi_device = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
+ (unsigned int)pdev->bus->number,
PCI_DEVFN(PCI_SLOT(pdev->devfn), 1));
if (!drm->hdmi_device) {
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
index 4c07d10..18241c6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
@@ -28,8 +28,16 @@
{
struct pci_dev *bridge;
u32 mem, mib;
+ int domain = 0;
+ struct pci_dev *pdev = NULL;
- bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 1));
+ if (dev_is_pci(fb->subdev.device->dev))
+ pdev = to_pci_dev(fb->subdev.device->dev);
+
+ if (pdev)
+ domain = pci_domain_nr(pdev->bus);
+
+ bridge = pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 1));
if (!bridge) {
nvkm_error(&fb->subdev, "no bridge device\n");
return -ENODEV;
--
1.9.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152
On Mon, 2017-12-18 at 20:01 +0100, Tobias Klausmann wrote: > On 12/18/17 7:06 PM, Mike Galbraith wrote: > > Greetings, > > > > Kernel bound workloads seem to trigger the below for whatever reason. > > I only see this when beating up NFS. There was a kworker wakeup > > latency issue, but with a bandaid applied to fix that up, I can still > > trigger this. > > > Hi, > > i have seen this one as well with my system, but i could not find an > easy way to trigger it for bisecting purpose. If you can trigger it > conveniently, a bisect would be nice! Workload permitting. To reproduce, mount your box NFS, cd to somewhere the NFS mount, and just do bonnie -s . There, maybe you'll beat me to it. I hope so, I have multiple kernels doing the annoying "baby birds in a nest" thing at me literally endlessly :) -Mike ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152
On 12/18/17 7:06 PM, Mike Galbraith wrote: Greetings, Kernel bound workloads seem to trigger the below for whatever reason. I only see this when beating up NFS. There was a kworker wakeup latency issue, but with a bandaid applied to fix that up, I can still trigger this. Hi, i have seen this one as well with my system, but i could not find an easy way to trigger it for bisecting purpose. If you can trigger it conveniently, a bisect would be nice! Greetings, Tobias [ 1313.811031] nouveau :01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [ 1313.811035] swiotlb: coherent allocation failed for device :01:00.0 size=2097152 [ 1313.811038] CPU: 6 PID: 3026 Comm: Xorg Tainted: GE 4.15.0.g1291a0d5-master #355 [ 1313.811040] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 09/23/2013 [ 1313.811041] Call Trace: [ 1313.811049] dump_stack+0x7c/0xb6 [ 1313.811053] swiotlb_alloc_coherent+0x13f/0x150 [ 1313.811060] ttm_dma_pool_alloc_new_pages+0x106/0x3c0 [ttm] [ 1313.811066] ttm_dma_pool_get_pages+0x10a/0x1e0 [ttm] [ 1313.811070] ttm_dma_populate+0x21f/0x2f0 [ttm] [ 1313.811075] ttm_tt_bind+0x2f/0x60 [ttm] [ 1313.811079] ttm_bo_handle_move_mem+0x51f/0x580 [ttm] [ 1313.811084] ? ttm_bo_handle_move_mem+0x5/0x580 [ttm] [ 1313.811088] ttm_bo_validate+0x10c/0x120 [ttm] [ 1313.811092] ? ttm_bo_validate+0x5/0x120 [ttm] [ 1313.811106] ? drm_mode_setcrtc+0x20e/0x540 [drm] [ 1313.811109] ttm_bo_init_reserved+0x290/0x490 [ttm] [ 1313.84] ttm_bo_init+0x52/0xb0 [ttm] [ 1313.811141] ? nv10_bo_put_tile_region+0x60/0x60 [nouveau] [ 1313.811163] nouveau_bo_new+0x465/0x5e0 [nouveau] [ 1313.811184] ? nv10_bo_put_tile_region+0x60/0x60 [nouveau] [ 1313.811203] nouveau_gem_new+0x66/0x110 [nouveau] [ 1313.811223] ? nouveau_gem_new+0x110/0x110 [nouveau] [ 1313.811241] nouveau_gem_ioctl_new+0x48/0xc0 [nouveau] [ 1313.811249] drm_ioctl_kernel+0x64/0xb0 [drm] [ 1313.811257] drm_ioctl+0x2a4/0x360 [drm] [ 1313.811276] ? nouveau_gem_new+0x110/0x110 [nouveau] [ 1313.811285] ? drm_ioctl+0x5/0x360 [drm] [ 1313.811304] nouveau_drm_ioctl+0x50/0xb0 [nouveau] [ 1313.811308] do_vfs_ioctl+0x90/0x690 [ 1313.811311] ? do_vfs_ioctl+0x5/0x690 [ 1313.811313] SyS_ioctl+0x3b/0x70 [ 1313.811316] entry_SYSCALL_64_fastpath+0x1f/0x91 [ 1313.811320] RIP: 0033:0x7f3234746227 [ 1313.811321] RSP: 002b:7ffc3ace0408 EFLAGS: 3246 ORIG_RAX: 0010 [ 1313.811324] RAX: ffda RBX: 025515d0 RCX: 7f3234746227 [ 1313.811325] RDX: 7ffc3ace0460 RSI: c0306480 RDI: 000b [ 1313.811326] RBP: 00824120 R08: 02548f80 R09: 025490d0 [ 1313.811328] R10: R11: 3246 R12: 093d [ 1313.811329] R13: 02aff74c R14: 00824150 R15: ___ 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 #7 from mbazzino...@gmail.com --- Created attachment 136255 --> https://bugs.freedesktop.org/attachment.cgi?id=136255&action=edit Bazz `xrandr` output -- 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 #6 from mbazzino...@gmail.com --- Created attachment 136254 --> https://bugs.freedesktop.org/attachment.cgi?id=136254&action=edit Bazz vbios -- 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 mbazzino...@gmail.com changed: What|Removed |Added CC||mbazzino...@gmail.com --- Comment #5 from mbazzino...@gmail.com --- Created attachment 136253 --> https://bugs.freedesktop.org/attachment.cgi?id=136253&action=edit Bazz dmesg On similar hardware, I am experiencing this display flicker with nouveau. Macbook Pro 5,4 15" mid-2009 Nvidia GeForce 9400m mini DisplayPort -> "Gigaware" DVI/HDMI/Displayport adapter -> using DVI port on the monitor. Software| Gentoo Linux 4.9.49 and 4.12.12. I recall this issue dating back to my use of 3.18.11. x11-base/xorg-server-1.19.5 x11-drivers/xf86-video-nouveau-1.0.15 No compositor I've tested under XFCE4 or i3, the problem is the same. kernel command line: ro root=PARTUUID= net.ifnames=0 --- Attachments| --- bazz-dmesg.txt (dmesg command dump) bazz-xrandr.txt (xrandr output) bazz-vbios.rom -- Issues| -- 1) intermittent flickering on the 2nd monitor. 2) If unplugging the mDP cable, the LVDS may flicker and the system appears locked up (I cannot "blind" navigate to VT to reboot, like I usually do in other circumstances). However, replugging the mDP cable will cease LVDS flicker, although the system is still apparently rendered inoperable. These problems do not occur when using the legacy nvidia-drivers (340.104). Issue 1 is also experienced when booting to Virtual Terminal (VT) without starting X. I have not experimented for Issue 2 on VT-only yet. The DVI monitor is "usable" but experiences mild flicker and other times frequent flickering. It can appear stable for 30 seconds to a couple minutes at a time, only to have flickering return. Commandline / Module Parameters | I played around with the following parameters. drm_kms_helper.poll=0 noveau atomic, mst, runpm. Playing with those settings have not made visible changes to the problem. -- pstate| -- `cat /sys/kernel/debug/dri/0/pstate` 03: core 125 MHz shader 250 MHz vdec 125 MHz 05: core 150 MHz shader 300 MHz vdec 150 MHz 0e: core 350 MHz shader 800 MHz vdec 350 MHz AC DC * 0f: core 450 MHz shader 1100 MHz vdec 450 MHz AC: core 350 MHz shader 800 MHz vdec 350 MHz pstate 03, 05 produce incredible constant flicker on the 2nd monitor. pstate 0e, 0f produce intermittent flickering I've always been experiencing. -- 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] nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152
Greetings, Kernel bound workloads seem to trigger the below for whatever reason. I only see this when beating up NFS. There was a kworker wakeup latency issue, but with a bandaid applied to fix that up, I can still trigger this. [ 1313.811031] nouveau :01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [ 1313.811035] swiotlb: coherent allocation failed for device :01:00.0 size=2097152 [ 1313.811038] CPU: 6 PID: 3026 Comm: Xorg Tainted: GE 4.15.0.g1291a0d5-master #355 [ 1313.811040] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 09/23/2013 [ 1313.811041] Call Trace: [ 1313.811049] dump_stack+0x7c/0xb6 [ 1313.811053] swiotlb_alloc_coherent+0x13f/0x150 [ 1313.811060] ttm_dma_pool_alloc_new_pages+0x106/0x3c0 [ttm] [ 1313.811066] ttm_dma_pool_get_pages+0x10a/0x1e0 [ttm] [ 1313.811070] ttm_dma_populate+0x21f/0x2f0 [ttm] [ 1313.811075] ttm_tt_bind+0x2f/0x60 [ttm] [ 1313.811079] ttm_bo_handle_move_mem+0x51f/0x580 [ttm] [ 1313.811084] ? ttm_bo_handle_move_mem+0x5/0x580 [ttm] [ 1313.811088] ttm_bo_validate+0x10c/0x120 [ttm] [ 1313.811092] ? ttm_bo_validate+0x5/0x120 [ttm] [ 1313.811106] ? drm_mode_setcrtc+0x20e/0x540 [drm] [ 1313.811109] ttm_bo_init_reserved+0x290/0x490 [ttm] [ 1313.84] ttm_bo_init+0x52/0xb0 [ttm] [ 1313.811141] ? nv10_bo_put_tile_region+0x60/0x60 [nouveau] [ 1313.811163] nouveau_bo_new+0x465/0x5e0 [nouveau] [ 1313.811184] ? nv10_bo_put_tile_region+0x60/0x60 [nouveau] [ 1313.811203] nouveau_gem_new+0x66/0x110 [nouveau] [ 1313.811223] ? nouveau_gem_new+0x110/0x110 [nouveau] [ 1313.811241] nouveau_gem_ioctl_new+0x48/0xc0 [nouveau] [ 1313.811249] drm_ioctl_kernel+0x64/0xb0 [drm] [ 1313.811257] drm_ioctl+0x2a4/0x360 [drm] [ 1313.811276] ? nouveau_gem_new+0x110/0x110 [nouveau] [ 1313.811285] ? drm_ioctl+0x5/0x360 [drm] [ 1313.811304] nouveau_drm_ioctl+0x50/0xb0 [nouveau] [ 1313.811308] do_vfs_ioctl+0x90/0x690 [ 1313.811311] ? do_vfs_ioctl+0x5/0x690 [ 1313.811313] SyS_ioctl+0x3b/0x70 [ 1313.811316] entry_SYSCALL_64_fastpath+0x1f/0x91 [ 1313.811320] RIP: 0033:0x7f3234746227 [ 1313.811321] RSP: 002b:7ffc3ace0408 EFLAGS: 3246 ORIG_RAX: 0010 [ 1313.811324] RAX: ffda RBX: 025515d0 RCX: 7f3234746227 [ 1313.811325] RDX: 7ffc3ace0460 RSI: c0306480 RDI: 000b [ 1313.811326] RBP: 00824120 R08: 02548f80 R09: 025490d0 [ 1313.811328] R10: R11: 3246 R12: 093d [ 1313.811329] R13: 02aff74c R14: 00824150 R15: ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] Accept 3d controllers and not only VGA controllers.
Sounds good to me, if we remove or modify the PCI_CLASS check in nouveau_fbcon.c as well :). On 2017-12-18 18:36, Karol Herbst wrote: > I've discussed it with Ben and we actually found a better solution. > There are just some calls inside those functions which should get NULL > checks, nv50_mstm_register_connector and nv50_mstm_destroy_connector. > Or at least something similiar so that the code doesn't depent on the > fbcon object being there. > > On Mon, Dec 18, 2017 at 6:30 PM, Josef Larsson wrote: >> Without a NULL pointer safe-guard patch, I get a kernel oops when I plug >> in external displays in my docking station, (exactly the same issue as >> https://bugs.freedesktop.org/show_bug.cgi?id=101778) and without >> removing or modifying the check (accepting PCI_CLASS_DISPLAY_3D in the >> if-condition), I cannot use external displays through my docking >> station. This is on an optimus system where I use reverse PRIME to be >> able to use the connectors at all. Having some kind of safe-guard makes >> sense to me, and that is available in the i915-driver of the >> corresponding functions. >> >> If there are better patches to fix my two problems, I am willing to try >> them out, because I really think this should be handled somehow. >> >> One note though: These patches do not make the docking station >> experience perfect. They only make it not quite as bad. For example, >> undocking when using external displays forces Xorg to restart, and when >> docking without a patch for xf86-video-nouveau DDX by Ilia Mirkin >> (https://people.freedesktop.org/~imirkin/patches/0001-drmmode-update-logic-for-dynamic-connectors-paths-an.patch), >> the external docking station displays are not detected. >> >> >> On 2017-12-14 23:59, Karol Herbst wrote: >>> On 14 December 2017 11:55:35 p.m. GMT+01:00, Ben Skeggs >>> wrote: On 14 December 2017 at 23:45, Tobias Klausmann wrote: > On 12/3/17 8:56 PM, Josef Larsson wrote: >> Sure, I can easily split it into two commits, but I would like to have >> an OK on the actual code changes before splitting the patch. I'm not actually sure this is a good idea still. As I recall, part of the purpose of that check is to prevent nouveau taking over as the primary fbcon when it's the secondary display in the system. ie. Optimus system with Intel driving the display, NVIDIA GPU has no displays attached. If nouveau loads first, at some point in history, you'd have ended up with a blank console. I'm not sure if this is still the case, but it warrants checking before making this change. I'm more interested in what this actually solves, and why not having fbcon prevents external displays from being used. Ben. >>> I think the issue is we can't really put any trust in this. my kepler GPU >>> on my laptop is a VGA device, not a 3D accelerator, even though everything >>> is wird to intel, it is a MXM card though, so in theory it is able to drive >>> displays. >>> >>> We need something else to detect if the GPU is the main one or not. >>> >> Best regards, >> >> Josef Larsson >> >> >> On 2017-11-11 01:05, Tobias Klausmann wrote: >>> On 11/10/17 7:49 PM, Josef Larsson wrote: Accept 3d controllers and not only VGA controllers. According to Ilia Mirkin, the VGA controller check should be removed. This makes it possible to use external connectors on a docking station (40A5) for a Thinkpad P51. (See Bug 101778). lspci example: 01:00.0 3D controller: NVIDIA Corporation GM107GLM [Quadro M1200 Mobile] (rev a2) Also include safe-guards to avoid NULL dereferencing of fbcon, which is how this bug was found. --- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 +-- drivers/gpu/drm/nouveau/nv50_display.c | 13 + 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 2b12d82aac15..6b4d374a9d82 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -498,8 +498,7 @@ nouveau_fbcon_init(struct drm_device *dev) int preferred_bpp; int ret; -if (!dev->mode_config.num_crtc || -(dev->pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA) +if (!dev->mode_config.num_crtc) return 0; fbcon = kzalloc(sizeof(struct nouveau_fbdev), GFP_KERNEL); diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c index fb47d46050ec..061daf036407 100644 --- a/drivers/gpu/drm/nouveau/nv50_display.c +++ b/drivers/gpu/drm/nouvea
Re: [Nouveau] [PATCH] Accept 3d controllers and not only VGA controllers.
I've discussed it with Ben and we actually found a better solution. There are just some calls inside those functions which should get NULL checks, nv50_mstm_register_connector and nv50_mstm_destroy_connector. Or at least something similiar so that the code doesn't depent on the fbcon object being there. On Mon, Dec 18, 2017 at 6:30 PM, Josef Larsson wrote: > Without a NULL pointer safe-guard patch, I get a kernel oops when I plug > in external displays in my docking station, (exactly the same issue as > https://bugs.freedesktop.org/show_bug.cgi?id=101778) and without > removing or modifying the check (accepting PCI_CLASS_DISPLAY_3D in the > if-condition), I cannot use external displays through my docking > station. This is on an optimus system where I use reverse PRIME to be > able to use the connectors at all. Having some kind of safe-guard makes > sense to me, and that is available in the i915-driver of the > corresponding functions. > > If there are better patches to fix my two problems, I am willing to try > them out, because I really think this should be handled somehow. > > One note though: These patches do not make the docking station > experience perfect. They only make it not quite as bad. For example, > undocking when using external displays forces Xorg to restart, and when > docking without a patch for xf86-video-nouveau DDX by Ilia Mirkin > (https://people.freedesktop.org/~imirkin/patches/0001-drmmode-update-logic-for-dynamic-connectors-paths-an.patch), > the external docking station displays are not detected. > > > On 2017-12-14 23:59, Karol Herbst wrote: >> >> On 14 December 2017 11:55:35 p.m. GMT+01:00, Ben Skeggs >> wrote: >>> On 14 December 2017 at 23:45, Tobias Klausmann >>> wrote: On 12/3/17 8:56 PM, Josef Larsson wrote: > Sure, I can easily split it into two commits, but I would like to >>> have > an OK on the actual code changes before splitting the patch. >>> I'm not actually sure this is a good idea still. As I recall, part of >>> the purpose of that check is to prevent nouveau taking over as the >>> primary fbcon when it's the secondary display in the system. ie. >>> Optimus system with Intel driving the display, NVIDIA GPU has no >>> displays attached. If nouveau loads first, at some point in history, >>> you'd have ended up with a blank console. >>> >>> I'm not sure if this is still the case, but it warrants checking >>> before making this change. >>> >>> I'm more interested in what this actually solves, and why not having >>> fbcon prevents external displays from being used. >>> >>> Ben. >>> >> I think the issue is we can't really put any trust in this. my kepler GPU on >> my laptop is a VGA device, not a 3D accelerator, even though everything is >> wird to intel, it is a MXM card though, so in theory it is able to drive >> displays. >> >> We need something else to detect if the GPU is the main one or not. >> > Best regards, > > Josef Larsson > > > On 2017-11-11 01:05, Tobias Klausmann wrote: >> On 11/10/17 7:49 PM, Josef Larsson wrote: >>> Accept 3d controllers and not only VGA controllers. According to >>> Ilia >>> Mirkin, >>> the VGA controller check should be removed. This makes it possible >>> to use external connectors on a docking station (40A5) for a >>> Thinkpad >>> P51. >>> (See Bug 101778). >>> >>> lspci example: >>> >>> 01:00.0 3D controller: NVIDIA Corporation GM107GLM [Quadro M1200 >>> Mobile] >>> (rev a2) >>> >>> Also include safe-guards to avoid NULL dereferencing of fbcon, >>> which is >>> how this bug was found. >>> --- >>>drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 +-- >>>drivers/gpu/drm/nouveau/nv50_display.c | 13 + >>>2 files changed, 14 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c >>> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c >>> index 2b12d82aac15..6b4d374a9d82 100644 >>> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c >>> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c >>> @@ -498,8 +498,7 @@ nouveau_fbcon_init(struct drm_device *dev) >>>int preferred_bpp; >>>int ret; >>>-if (!dev->mode_config.num_crtc || >>> -(dev->pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA) >>> +if (!dev->mode_config.num_crtc) >>>return 0; >>> fbcon = kzalloc(sizeof(struct nouveau_fbdev), >>> GFP_KERNEL); >>> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c >>> b/drivers/gpu/drm/nouveau/nv50_display.c >>> index fb47d46050ec..061daf036407 100644 >>> --- a/drivers/gpu/drm/nouveau/nv50_display.c >>> +++ b/drivers/gpu/drm/nouveau/nv50_display.c >>> @@ -3214,6 +3214,13 @@ nv50_mstm_destroy_connector(struct >>> drm_dp_mst_topology_mgr *mgr, >>>struct nouveau_drm *drm = nouveau_drm(connector->dev); >>>struct nv50_mstc *mstc = nv50_mstc(conne
Re: [Nouveau] [PATCH] Accept 3d controllers and not only VGA controllers.
Without a NULL pointer safe-guard patch, I get a kernel oops when I plug
in external displays in my docking station, (exactly the same issue as
https://bugs.freedesktop.org/show_bug.cgi?id=101778) and without
removing or modifying the check (accepting PCI_CLASS_DISPLAY_3D in the
if-condition), I cannot use external displays through my docking
station. This is on an optimus system where I use reverse PRIME to be
able to use the connectors at all. Having some kind of safe-guard makes
sense to me, and that is available in the i915-driver of the
corresponding functions.
If there are better patches to fix my two problems, I am willing to try
them out, because I really think this should be handled somehow.
One note though: These patches do not make the docking station
experience perfect. They only make it not quite as bad. For example,
undocking when using external displays forces Xorg to restart, and when
docking without a patch for xf86-video-nouveau DDX by Ilia Mirkin
(https://people.freedesktop.org/~imirkin/patches/0001-drmmode-update-logic-for-dynamic-connectors-paths-an.patch),
the external docking station displays are not detected.
On 2017-12-14 23:59, Karol Herbst wrote:
>
> On 14 December 2017 11:55:35 p.m. GMT+01:00, Ben Skeggs
> wrote:
>> On 14 December 2017 at 23:45, Tobias Klausmann
>> wrote:
>>> On 12/3/17 8:56 PM, Josef Larsson wrote:
Sure, I can easily split it into two commits, but I would like to
>> have
an OK on the actual code changes before splitting the patch.
>> I'm not actually sure this is a good idea still. As I recall, part of
>> the purpose of that check is to prevent nouveau taking over as the
>> primary fbcon when it's the secondary display in the system. ie.
>> Optimus system with Intel driving the display, NVIDIA GPU has no
>> displays attached. If nouveau loads first, at some point in history,
>> you'd have ended up with a blank console.
>>
>> I'm not sure if this is still the case, but it warrants checking
>> before making this change.
>>
>> I'm more interested in what this actually solves, and why not having
>> fbcon prevents external displays from being used.
>>
>> Ben.
>>
> I think the issue is we can't really put any trust in this. my kepler GPU on
> my laptop is a VGA device, not a 3D accelerator, even though everything is
> wird to intel, it is a MXM card though, so in theory it is able to drive
> displays.
>
> We need something else to detect if the GPU is the main one or not.
>
Best regards,
Josef Larsson
On 2017-11-11 01:05, Tobias Klausmann wrote:
> On 11/10/17 7:49 PM, Josef Larsson wrote:
>> Accept 3d controllers and not only VGA controllers. According to
>> Ilia
>> Mirkin,
>> the VGA controller check should be removed. This makes it possible
>> to use external connectors on a docking station (40A5) for a
>> Thinkpad
>> P51.
>> (See Bug 101778).
>>
>> lspci example:
>>
>> 01:00.0 3D controller: NVIDIA Corporation GM107GLM [Quadro M1200
>> Mobile]
>> (rev a2)
>>
>> Also include safe-guards to avoid NULL dereferencing of fbcon,
>> which is
>> how this bug was found.
>> ---
>>drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 +--
>>drivers/gpu/drm/nouveau/nv50_display.c | 13 +
>>2 files changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
>> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
>> index 2b12d82aac15..6b4d374a9d82 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
>> @@ -498,8 +498,7 @@ nouveau_fbcon_init(struct drm_device *dev)
>>int preferred_bpp;
>>int ret;
>>-if (!dev->mode_config.num_crtc ||
>> -(dev->pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
>> +if (!dev->mode_config.num_crtc)
>>return 0;
>> fbcon = kzalloc(sizeof(struct nouveau_fbdev),
>> GFP_KERNEL);
>> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
>> b/drivers/gpu/drm/nouveau/nv50_display.c
>> index fb47d46050ec..061daf036407 100644
>> --- a/drivers/gpu/drm/nouveau/nv50_display.c
>> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
>> @@ -3214,6 +3214,13 @@ nv50_mstm_destroy_connector(struct
>> drm_dp_mst_topology_mgr *mgr,
>>struct nouveau_drm *drm = nouveau_drm(connector->dev);
>>struct nv50_mstc *mstc = nv50_mstc(connector);
>>+if (!drm->fbcon)
>> +{
>> +NV_WARN(drm, "drm->fbcon of %s point to NULL. Will not
>> destroy
>> connector\n",
>> +connector->name);
>> +return;
>> +}
>> +
>>drm_connector_unregister(&mstc->connector);
>> drm_modeset_lock_all(drm->dev);
>> @@ -3229,6 +3236,12 @@ nv50_mstm_register_connector(struct
>> drm_connector
>> *connector)
>>{
>>struct nou
[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan
https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #21 from Daniel Drake --- I checked the behaviour under Windows and it appears that Windows is doing the above-mentioned PCI config space write when a HDMI cable is plugged in. I'm fairly sure that this is done "natively" by the windows driver (not in ACPI stuff). More info: https://devtalk.nvidia.com/default/topic/1024022/linux/gtx-1060-no-audio-over-hdmi-only-hda-intel-detected-azalia/post/5227504/#5227504 What would be the best way to implement this in nouveau? I'm unsure about the conditions we would want to do this under. Maybe something like: 1. nouveau is driving the HDMI output using its own display controller, and 2. HDMI cable is connected? (or maybe we enable HDMI audio all the time like other platforms?) 3. Only on GTX1060/GTX1070 which are the only cards where the 0x448 register write has been confirmed to work? -- 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] [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API
On 18 December 2017 at 13:16, Pierre Moreau wrote:
> Hey Ard,
>
> It seems that Ben already committed a similar patch to his tree (see [0]). I
> do
> not know whether he is planning to have it part of a pull request of fixes for
> 4.15.
>
Hi Pierre,
Thanks for the reply. If a fix has been queued, I don't mind leaving
it up to Ben to decide when it gets sent onwards.
--
Ard.
> [0]:
> https://github.com/skeggsb/nouveau/commit/9068f1df2394f0e4ab2b2a28cac06b462fe0a0aa
>
> On 2017-12-18 — 09:27, Ard Biesheuvel wrote:
>> On 8 December 2017 at 19:30, Ard Biesheuvel
>> wrote:
>> > Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly
>> > into nv04_instobj") introduced some new calls to the refcount api to
>> > the nv50 mapping code. In one particular instance, it does the
>> > following:
>> >
>> > if (!refcount_inc_not_zero(&iobj->maps)) {
>> > ...
>> > refcount_inc(&iobj->maps);
>> > }
>> >
>> > i.e., it calls refcount_inc() to increment the refcount when it is known
>> > to be zero, which is explicitly forbidden by the API. Instead, use
>> > refcount_set() to set it to 1.
>> >
>> > Signed-off-by: Ard Biesheuvel
>> > ---
>> >
>> > Apologies if this was already found and fixed. I don't usually follow
>> > the DRM or nouveau mailing lists.
>> >
>> > drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
>> > b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
>> > index 1ba7289684aa..db48a1daca0c 100644
>> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
>> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
>> > @@ -249,7 +249,7 @@ nv50_instobj_acquire(struct nvkm_memory *memory)
>> > iobj->base.memory.ptrs = &nv50_instobj_fast;
>> > else
>> > iobj->base.memory.ptrs = &nv50_instobj_slow;
>> > - refcount_inc(&iobj->maps);
>> > + refcount_set(&iobj->maps, 1);
>> > }
>> >
>> > mutex_unlock(&imem->subdev.mutex);
>> > --
>> > 2.11.0
>> >
>>
>> Ping?
>> ___
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API
Hey Ard,
It seems that Ben already committed a similar patch to his tree (see [0]). I do
not know whether he is planning to have it part of a pull request of fixes for
4.15.
Best regards,
Pierre
[0]:
https://github.com/skeggsb/nouveau/commit/9068f1df2394f0e4ab2b2a28cac06b462fe0a0aa
On 2017-12-18 — 09:27, Ard Biesheuvel wrote:
> On 8 December 2017 at 19:30, Ard Biesheuvel wrote:
> > Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly
> > into nv04_instobj") introduced some new calls to the refcount api to
> > the nv50 mapping code. In one particular instance, it does the
> > following:
> >
> > if (!refcount_inc_not_zero(&iobj->maps)) {
> > ...
> > refcount_inc(&iobj->maps);
> > }
> >
> > i.e., it calls refcount_inc() to increment the refcount when it is known
> > to be zero, which is explicitly forbidden by the API. Instead, use
> > refcount_set() to set it to 1.
> >
> > Signed-off-by: Ard Biesheuvel
> > ---
> >
> > Apologies if this was already found and fixed. I don't usually follow
> > the DRM or nouveau mailing lists.
> >
> > drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> > index 1ba7289684aa..db48a1daca0c 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> > @@ -249,7 +249,7 @@ nv50_instobj_acquire(struct nvkm_memory *memory)
> > iobj->base.memory.ptrs = &nv50_instobj_fast;
> > else
> > iobj->base.memory.ptrs = &nv50_instobj_slow;
> > - refcount_inc(&iobj->maps);
> > + refcount_set(&iobj->maps, 1);
> > }
> >
> > mutex_unlock(&imem->subdev.mutex);
> > --
> > 2.11.0
> >
>
> Ping?
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
signature.asc
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API
On 8 December 2017 at 19:30, Ard Biesheuvel wrote:
> Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly
> into nv04_instobj") introduced some new calls to the refcount api to
> the nv50 mapping code. In one particular instance, it does the
> following:
>
> if (!refcount_inc_not_zero(&iobj->maps)) {
> ...
> refcount_inc(&iobj->maps);
> }
>
> i.e., it calls refcount_inc() to increment the refcount when it is known
> to be zero, which is explicitly forbidden by the API. Instead, use
> refcount_set() to set it to 1.
>
> Signed-off-by: Ard Biesheuvel
> ---
>
> Apologies if this was already found and fixed. I don't usually follow
> the DRM or nouveau mailing lists.
>
> drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> index 1ba7289684aa..db48a1daca0c 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> @@ -249,7 +249,7 @@ nv50_instobj_acquire(struct nvkm_memory *memory)
> iobj->base.memory.ptrs = &nv50_instobj_fast;
> else
> iobj->base.memory.ptrs = &nv50_instobj_slow;
> - refcount_inc(&iobj->maps);
> + refcount_set(&iobj->maps, 1);
> }
>
> mutex_unlock(&imem->subdev.mutex);
> --
> 2.11.0
>
Ping?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
