[Nouveau] [PATCH V4 09/26] drm/nouveau: deprecate pci_get_bus_and_slot()

2017-12-18 Thread Sinan Kaya 
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, );
+   pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
+ 0x7c, );
 
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, );
+   pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 3),
+ 0x6c, );
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, );
+   pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 5),
+ 0x4c, );
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(>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

2017-12-18 Thread Mike Galbraith 
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

2017-12-18 Thread Tobias Klausmann 


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

2017-12-18 Thread bugzilla-daemon 
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=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

2017-12-18 Thread bugzilla-daemon 
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=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

2017-12-18 Thread bugzilla-daemon 
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=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

2017-12-18 Thread Mike Galbraith 
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.

2017-12-18 Thread Josef Larsson 
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
 ---

Re: [Nouveau] [PATCH] Accept 3d controllers and not only VGA controllers.

2017-12-18 Thread Karol Herbst 
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 =

Re: [Nouveau] [PATCH] Accept 3d controllers and not only VGA controllers.

2017-12-18 Thread Josef Larsson 
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(>connector);
>>  drm_modeset_lock_all(drm->dev);
>> @@ -3229,6 +3236,12 @@ nv50_mstm_register_connector(struct
>> drm_connector

[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan

2017-12-18 Thread bugzilla-daemon 
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

2017-12-18 Thread Ard Biesheuvel 
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(>maps)) {
>> > ...
>> > refcount_inc(>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 = _instobj_fast;
>> > else
>> > iobj->base.memory.ptrs = _instobj_slow;
>> > -   refcount_inc(>maps);
>> > +   refcount_set(>maps, 1);
>> > }
>> >
>> > mutex_unlock(>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

2017-12-18 Thread Pierre Moreau 
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(>maps)) {
> > ...
> > refcount_inc(>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 = _instobj_fast;
> > else
> > iobj->base.memory.ptrs = _instobj_slow;
> > -   refcount_inc(>maps);
> > +   refcount_set(>maps, 1);
> > }
> >
> > mutex_unlock(>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

2017-12-18 Thread Ard Biesheuvel 
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(>maps)) {
> ...
> refcount_inc(>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 = _instobj_fast;
> else
> iobj->base.memory.ptrs = _instobj_slow;
> -   refcount_inc(>maps);
> +   refcount_set(>maps, 1);
> }
>
> mutex_unlock(>subdev.mutex);
> --
> 2.11.0
>

Ping?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau