[Nouveau] [Bug 92032] NV34: WARNING: CPU: 0 PID: 290 at lib/dma-debug.c:1205 check_sync+0x169/0x6e0()
https://bugs.freedesktop.org/show_bug.cgi?id=92032 poma changed: What|Removed |Added Summary|NV30: WARNING: CPU: 0 PID: |NV34: WARNING: CPU: 0 PID: |290 at lib/dma-debug.c:1205 |290 at lib/dma-debug.c:1205 |check_sync+0x169/0x6e0()|check_sync+0x169/0x6e0() -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 92032] NV30: WARNING: CPU: 0 PID: 290 at lib/dma-debug.c:1205 check_sync+0x169/0x6e0()
https://bugs.freedesktop.org/show_bug.cgi?id=92032 --- Comment #5 from poma --- Unfortunately cannot be tested on kernel 4.4.x https://bugzilla.redhat.com/show_bug.cgi?id=1280430 -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 92032] NV30: WARNING: CPU: 0 PID: 290 at lib/dma-debug.c:1205 check_sync+0x169/0x6e0()
https://bugs.freedesktop.org/show_bug.cgi?id=92032 --- Comment #4 from poma --- [ cut here ] WARNING: CPU: 0 PID: 313 at lib/dma-debug.c:1205 check_sync+0x169/0x6e0() nouveau :01:00.0: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0xc0bf6468] [size=4096 bytes] Modules linked in: nouveau(+) ... CPU: 0 PID: 313 Comm: systemd-udevd Not tainted 4.3.0-3.fc22.i686+debug #1 ... Call Trace: [] dump_stack+0x48/0x69 [] warn_slowpath_common+0x87/0xc0 [] ? check_sync+0x169/0x6e0 [] ? check_sync+0x169/0x6e0 [] warn_slowpath_fmt+0x3e/0x60 [] check_sync+0x169/0x6e0 [] debug_dma_sync_single_for_device+0x7d/0x90 [] ? ttm_bo_del_sub_from_lru+0x18/0x50 [ttm] [] ? text_poke_bp+0xd0/0xd0 [] nouveau_bo_sync_for_device+0x8b/0xa0 [nouveau] [] nouveau_bo_validate+0x34/0x40 [nouveau] [] nouveau_bo_pin+0x188/0x290 [nouveau] [] ? nv10_bo_put_tile_region+0x80/0x80 [nouveau] [] nouveau_channel_prep+0xfd/0x2c0 [nouveau] [] nouveau_channel_new+0x57/0x7a0 [nouveau] [] ? kfree+0xdc/0x280 [] ? nvif_object_sclass_put+0x12/0x20 [nouveau] [] nouveau_drm_load+0x596/0x8d0 [nouveau] [] ? trace_hardirqs_on_caller+0x12c/0x1d0 [] ? drm_minor_register+0x89/0x120 [drm] [] drm_dev_register+0x96/0xa0 [drm] [] drm_get_pci_dev+0x79/0x1c0 [drm] [] ? pcibios_set_master+0x4e/0xa0 [] nouveau_drm_probe+0x1ee/0x220 [nouveau] [] pci_device_probe+0x7b/0xf0 [] ? devices_kset_move_last+0x56/0xa0 [] driver_probe_device+0x204/0x490 [] ? __driver_attach+0x4c/0x90 [] ? pci_match_device+0xd2/0x100 [] __driver_attach+0x81/0x90 [] ? driver_probe_device+0x490/0x490 [] bus_for_each_dev+0x57/0xa0 [] driver_attach+0x1e/0x20 [] ? driver_probe_device+0x490/0x490 [] bus_add_driver+0x1ef/0x290 [] driver_register+0x5d/0xf0 [] __pci_register_driver+0x4a/0x50 [] drm_pci_init+0xdd/0x100 [drm] [] nouveau_drm_init+0x1f9/0x1000 [nouveau] [] ? 0xf7f21000 [] do_one_initcall+0xaa/0x200 [] ? 0xf7f21000 [] ? rcu_read_lock_sched_held+0x42/0x80 [] ? kmem_cache_alloc_trace+0x23d/0x310 [] ? do_init_module+0x21/0x1b7 [] ? do_init_module+0x21/0x1b7 [] do_init_module+0x50/0x1b7 [] load_module+0x1ebc/0x2550 [] ? _raw_spin_unlock_irq+0x27/0x40 [] ? finish_task_switch+0x8a/0x1d0 [] SyS_init_module+0x147/0x1a0 [] ? do_audit_syscall_entry.isra.9+0x44/0x50 [] ? syscall_trace_enter_phase1+0x107/0x130 [] syscall_call+0x7/0x7 ---[ end trace d3c14159641a1388 ]--- -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v3) -> v4
On 12.11.2015 14:48, Thierry Reding wrote: > On Wed, Nov 11, 2015 at 09:12:33PM +0100, poma wrote: >> On 10.11.2015 17:25, Mario Kleiner wrote: >>> On 11/10/2015 05:00 PM, Thierry Reding wrote: On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote: > From: Daniel Vetter > > Apparently pre-nv50 pageflip events happen before the actual vblank > period. Therefore that functionality got semi-disabled in > > commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28 > Author: Mario Kleiner > Date: Tue May 13 00:42:08 2014 +0200 > > drm/nouveau/kms/nv04-nv40: fix pageflip events via special case. > > Unfortunately that hack got uprooted in > > commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb > Author: Thierry Reding > Date: Wed Aug 12 17:00:31 2015 +0200 > > drm/irq: Make pipe unsigned and name consistent > > Trigering a warning when trying to sample the vblank timestamp for a > non-existing pipe. There's a few ways to fix this: > > - Open-code the old behaviour, which just enshrines this slight >breakage of the userspace ABI. > > - Revert Mario's commit and again inflict broken timestamps, again not >pretty. > > - Fix this for real by delaying the pageflip TS until the next vblank >interrupt, thereby making it accurate. > > This patch implements the third option. Since having a page flip > interrupt that happens when the pageflip gets armed and not when it > completes in the next vblank seems to be fairly common (older i915 hw > works very similarly) create a new helper to arm vblank events for > such drivers. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431 > Cc: Thierry Reding > Cc: Mario Kleiner > Cc: Ben Skeggs > Cc: Ilia Mirkin > > v2 (mario): Integrate my own review comments into Daniels patch. > - Fix function prototypes in drmP.h > - Add missing vblank_put() for pageflip completion without > pageflip event. > - Initialize sequence number for queued pageflip event to avoidng > trouble in drm_handle_vblank_events(). > - Remove dead code and spelling fix. > > v3 (mario): Add a signed-off-by and cc stable tag per Ilja's advice. > > Signed-off-by: Daniel Vetter > (v1) Reviewed-by: Mario Kleiner > (v2/v3) Signed-off-by: Mario Kleiner > > Cc: sta...@vger.kernel.org # v4.3 > --- > drivers/gpu/drm/drm_irq.c | 54 > ++- > drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++- > include/drm/drmP.h| 4 +++ > 3 files changed, 68 insertions(+), 9 deletions(-) This looks good to me. Let me clean this up a little and submit it to Dave. Thierry >>> >>> Btw., if somebody has a functional old card for testing this, it should >>> be easy to verify if it works on pre-nv50. If it would not work it would >>> deliver the pageflip event 1 frame delayed, so at least on standard >>> nouveau + default DRI2 + default double-buffering the rate for a tight >>> loop of page-flipped swaps should go down to 30 fps on a 60 Hz display, >>> quite noticeable. Afaik we also have Piglit tests for OML_sync_control >>> which would likely fail if this would be broken. >>> >>> Oh and if someone has tips on how to resurrect an old nv-40 PC (booted >>> with BIOS only) graphics card in a MacPro (EFI boot), i wouldn't mind >>> hearing them. It would be nice to still be able to use that card for >>> testing. >>> >>> thanks, >>> -mario >> >> >> [ cut here ] >> WARNING: CPU: 0 PID: 313 at lib/dma-debug.c:1205 check_sync+0x169/0x6e0() >> nouveau :01:00.0: DMA-API: device driver tries to sync DMA memory it has >> not allocated [device address=0xc0bf6468] [size=4096 bytes] >> Modules linked in: nouveau(+) ... >> CPU: 0 PID: 313 Comm: systemd-udevd Not tainted 4.3.0-3.fc22.i686+debug #1 >> ... >> Call Trace: >> [] dump_stack+0x48/0x69 >> [] warn_slowpath_common+0x87/0xc0 >> [] ? check_sync+0x169/0x6e0 >> [] ? check_sync+0x169/0x6e0 >> [] warn_slowpath_fmt+0x3e/0x60 >> [] check_sync+0x169/0x6e0 >> [] debug_dma_sync_single_for_device+0x7d/0x90 >> [] ? ttm_bo_del_sub_from_lru+0x18/0x50 [ttm] >> [] ? text_poke_bp+0xd0/0xd0 >> [] nouveau_bo_sync_for_device+0x8b/0xa0 [nouveau] >> [] nouveau_bo_validate+0x34/0x40 [nouveau] >> [] nouveau_bo_pin+0x188/0x290 [nouveau] >> [] ? nv10_bo_put_tile_region+0x80/0x80 [nouveau] >> [] nouveau_channel_prep+0xfd/0x2c0 [nouveau] >> [] nouveau_channel_new+0x57/0x7a0 [nouveau] >> [] ? kfree+0xdc/0x280 >> [] ? nvif_object_sclass_put+0x12/0x20 [nouveau] >> [] nouveau_drm_load+0x596/0x8d0 [nouveau] >> [] ? trace_hardirqs_on_caller+0x12c/0x1d0 >> [] ? drm_minor_register+0x89/0x120 [drm] >> [] drm_dev_register+0x96/0xa0 [drm] >> []
[Nouveau] [Bug 92922] [NVE6] Xorg random freeze
https://bugs.freedesktop.org/show_bug.cgi?id=92922 --- Comment #3 from Ilia Mirkin --- You can try the patch below and see if it ever triggers. Make sure to build with --enable-debug (otherwise you won't get the assert). You'll also probably want --enable-texture-float (I'd check how your distro builds it and do the same thing). Of course note that if gnome-shell is hitting this... the assert will happen in gnome-session and it will crash :) If you could run it in gdb and poke around at things when it does crash that'd be useful. diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c b/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c index 205e7dc..d7ee0763 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c @@ -150,6 +150,7 @@ nvc0_validate_fb(struct nvc0_context *nvc0) struct nv50_surface *sf = nv50_surface(fb->zsbuf); int unk = mt->base.base.target == PIPE_TEXTURE_2D; +assert(nouveau_bo_memtype(nv04_resource(fb->zsbuf->texture)->bo) < 0xd0); BEGIN_NVC0(push, NVC0_3D(ZETA_ADDRESS_HIGH), 5); PUSH_DATAh(push, mt->base.address + sf->offset); PUSH_DATA (push, mt->base.address + sf->offset); -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 92922] [NVE6] Xorg random freeze
https://bugs.freedesktop.org/show_bug.cgi?id=92922 --- Comment #2 from Antonis Karagiannis --- Installed Packages mesa-dri-drivers.x86_64 11.0.4-1.20151105.fc23 mesa-filesystem.x86_64 11.0.4-1.20151105.fc23 mesa-libEGL.i686 11.0.4-1.20151105.fc23 mesa-libEGL.x86_64 11.0.4-1.20151105.fc23 mesa-libGL.i686 11.0.4-1.20151105.fc23 mesa-libGL.x86_6411.0.4-1.20151105.fc23 mesa-libGLES.x86_64 11.0.4-1.20151105.fc23 mesa-libGLU.x86_64 9.0.0-9.fc23 mesa-libgbm.i686 11.0.4-1.20151105.fc23 mesa-libgbm.x86_64 11.0.4-1.20151105.fc23 mesa-libglapi.i686 11.0.4-1.20151105.fc23 mesa-libglapi.x86_64 11.0.4-1.20151105.fc23 mesa-libwayland-egl.x86_64 11.0.4-1.20151105.fc23 mesa-libxatracker.x86_64 11.0.4-1.20151105.fc23 I hope this clarifies the mesa versions installed. Now as for building the custom mesa lib, I haven't done that before. If it's just ./configure && make && make install, I just might give it a try ;-) -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 92922] [NVE6] Xorg random freeze
https://bugs.freedesktop.org/show_bug.cgi?id=92922 Ilia Mirkin changed: What|Removed |Added Summary|Xorg random freeze |[NVE6] Xorg random freeze --- Comment #1 from Ilia Mirkin --- Actually the version of mesa is the most relevant thing here. Looks like we're somehow feeding a color surface to a zeta endpoint? That shouldn't happen :) I'd believe the opposite... but I don't see how this happens. [ zeta = depth/stencil buffer. storage type = 0xfe == color storage type fallback ] Unfortunate that you're getting this with gnome-shell... would be nice if you could repro it with something that's easier to trace. If you're open to building your own mesa lib, I could hack up a patch that would assert that we're sticking zeta surfaces into the zeta endpoint, which would make any offenders die at the point of offence. The INVALID_OPCODE thing is unrelated -- that sounds like good ol' bad code generated by our shader compiler, or perhaps some sort of confusion in which code gets uploaded where. Not entirely unheard of, but haven't had one of those in a while. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 92922] New: Xorg random freeze
https://bugs.freedesktop.org/show_bug.cgi?id=92922 Bug ID: 92922 Summary: Xorg random freeze Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: antok...@precise.gr QA Contact: xorg-t...@lists.x.org On Fedora (Gnome) Workstation 23, with the following: xorg-x11-server-Xorg.x86_64 1.18.0-1.fc23 xorg-x11-drv-nouveau.x86_64 1:1.0.12-0.3.fc23 and NVIDIA Corporation GK106 [GeForce GTX 660] (rev a1) At random times but suspecting Google Chrome may be causing it, or at least causing it to happen more easily. The screen freezes. I have intentionally added the seconds at the Gnome Clock to see if they will keep changing during the freeze but all the times, they freeze as well. The mouse moves and usually but not always, the keyboard works as well (caps lock lights, etc.) few times I could even switch session into terminal. >From the system journal I get: kernel: nouveau E[ PGRAPH][:02:00.0] TRAP ch 9 [0x023f566000 gnome-shell[2271]] kernel: nouveau E[ PGRAPH][:02:00.0] GPC0/PROP trap: ZETA_STORAGE_TYPE_MISMATCH kernel: nouveau E[ PGRAPH][:02:00.0] x = 968, y = 136, format = 0, storage type = fe kernel: nouveau E[ PGRAPH][:02:00.0] GPC1/PROP trap: ZETA_STORAGE_TYPE_MISMATCH kernel: nouveau E[ PGRAPH][:02:00.0] x = 1016, y = 104, format = 0, storage type = fe kernel: nouveau E[ PFIFO][:02:00.0] SCHED_ERROR [ CTXSW_TIMEOUT ] kernel: nouveau E[ PFIFO][:02:00.0] PGRAPH engine fault on channel 10, recovering... or just: kernel: nouveau E[ PFIFO][:02:00.0] SCHED_ERROR [ CTXSW_TIMEOUT ] kernel: nouveau E[ PFIFO][:02:00.0] PGRAPH engine fault on channel 10, recovering... and this gets repeated allot: kernel: nouveau E[ PGRAPH][:02:00.0] TRAP ch 9 [0x023f566000 gnome-shell[2224]] kernel: nouveau E[ PGRAPH][:02:00.0] GPC1/PROP trap: ZETA_STORAGE_TYPE_MISMATCH kernel: nouveau E[ PGRAPH][:02:00.0] x = 576, y = 512, format = 0, storage type = fe tried with wayland gnome session and it also happens: kernel: nouveau E[ PGRAPH][:02:00.0] TRAP ch 10 [0x023f315000 Xwayland[5816]] kernel: nouveau E[ PGRAPH][:02:00.0] GPC2/TPC0/MP trap: INVALID_OPCODE Please keep in mind that the GPU is ok, I have been using it with Windows, without any issues... I plan to find another PC and try to SSH during the freeze, once I do, I will post an update. Until then, the above log may be of useful to you. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v3) -> v4
On Wed, Nov 11, 2015 at 09:12:33PM +0100, poma wrote: > On 10.11.2015 17:25, Mario Kleiner wrote: > > On 11/10/2015 05:00 PM, Thierry Reding wrote: > >> On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote: > >>> From: Daniel Vetter > >>> > >>> Apparently pre-nv50 pageflip events happen before the actual vblank > >>> period. Therefore that functionality got semi-disabled in > >>> > >>> commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28 > >>> Author: Mario Kleiner > >>> Date: Tue May 13 00:42:08 2014 +0200 > >>> > >>> drm/nouveau/kms/nv04-nv40: fix pageflip events via special case. > >>> > >>> Unfortunately that hack got uprooted in > >>> > >>> commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb > >>> Author: Thierry Reding > >>> Date: Wed Aug 12 17:00:31 2015 +0200 > >>> > >>> drm/irq: Make pipe unsigned and name consistent > >>> > >>> Trigering a warning when trying to sample the vblank timestamp for a > >>> non-existing pipe. There's a few ways to fix this: > >>> > >>> - Open-code the old behaviour, which just enshrines this slight > >>>breakage of the userspace ABI. > >>> > >>> - Revert Mario's commit and again inflict broken timestamps, again not > >>>pretty. > >>> > >>> - Fix this for real by delaying the pageflip TS until the next vblank > >>>interrupt, thereby making it accurate. > >>> > >>> This patch implements the third option. Since having a page flip > >>> interrupt that happens when the pageflip gets armed and not when it > >>> completes in the next vblank seems to be fairly common (older i915 hw > >>> works very similarly) create a new helper to arm vblank events for > >>> such drivers. > >>> > >>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431 > >>> Cc: Thierry Reding > >>> Cc: Mario Kleiner > >>> Cc: Ben Skeggs > >>> Cc: Ilia Mirkin > >>> > >>> v2 (mario): Integrate my own review comments into Daniels patch. > >>> - Fix function prototypes in drmP.h > >>> - Add missing vblank_put() for pageflip completion without > >>> pageflip event. > >>> - Initialize sequence number for queued pageflip event to avoidng > >>> trouble in drm_handle_vblank_events(). > >>> - Remove dead code and spelling fix. > >>> > >>> v3 (mario): Add a signed-off-by and cc stable tag per Ilja's advice. > >>> > >>> Signed-off-by: Daniel Vetter > >>> (v1) Reviewed-by: Mario Kleiner > >>> (v2/v3) Signed-off-by: Mario Kleiner > >>> > >>> Cc: sta...@vger.kernel.org # v4.3 > >>> --- > >>> drivers/gpu/drm/drm_irq.c | 54 > >>> ++- > >>> drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++- > >>> include/drm/drmP.h| 4 +++ > >>> 3 files changed, 68 insertions(+), 9 deletions(-) > >> > >> This looks good to me. Let me clean this up a little and submit it to > >> Dave. > >> > >> Thierry > >> > > > > Btw., if somebody has a functional old card for testing this, it should > > be easy to verify if it works on pre-nv50. If it would not work it would > > deliver the pageflip event 1 frame delayed, so at least on standard > > nouveau + default DRI2 + default double-buffering the rate for a tight > > loop of page-flipped swaps should go down to 30 fps on a 60 Hz display, > > quite noticeable. Afaik we also have Piglit tests for OML_sync_control > > which would likely fail if this would be broken. > > > > Oh and if someone has tips on how to resurrect an old nv-40 PC (booted > > with BIOS only) graphics card in a MacPro (EFI boot), i wouldn't mind > > hearing them. It would be nice to still be able to use that card for > > testing. > > > > thanks, > > -mario > > > [ cut here ] > WARNING: CPU: 0 PID: 313 at lib/dma-debug.c:1205 check_sync+0x169/0x6e0() > nouveau :01:00.0: DMA-API: device driver tries to sync DMA memory it has > not allocated [device address=0xc0bf6468] [size=4096 bytes] > Modules linked in: nouveau(+) ... > CPU: 0 PID: 313 Comm: systemd-udevd Not tainted 4.3.0-3.fc22.i686+debug #1 > ... > Call Trace: > [] dump_stack+0x48/0x69 > [] warn_slowpath_common+0x87/0xc0 > [] ? check_sync+0x169/0x6e0 > [] ? check_sync+0x169/0x6e0 > [] warn_slowpath_fmt+0x3e/0x60 > [] check_sync+0x169/0x6e0 > [] debug_dma_sync_single_for_device+0x7d/0x90 > [] ? ttm_bo_del_sub_from_lru+0x18/0x50 [ttm] > [] ? text_poke_bp+0xd0/0xd0 > [] nouveau_bo_sync_for_device+0x8b/0xa0 [nouveau] > [] nouveau_bo_validate+0x34/0x40 [nouveau] > [] nouveau_bo_pin+0x188/0x290 [nouveau] > [] ? nv10_bo_put_tile_region+0x80/0x80 [nouveau] > [] nouveau_channel_prep+0xfd/0x2c0 [nouveau] > [] nouveau_channel_new+0x57/0x7a0 [nouveau] > [] ? kfree+0xdc/0x280 > [] ? nvif_object_sclass_put+0x12/0x20 [nouveau] > [] nouveau_drm_load+0x596/0x8d0 [nouveau] > [] ? trace_hardirqs_on_caller+0x12c/0x1d0 > [] ? drm_minor_register+0x89/0x120 [drm] > [] drm_dev_register+0x96/0xa0 [drm] > [] drm_get_pci_dev+0x79/0x1c0 [drm] > [] ? pcibios_set_master+0x4e/0xa0 >
Re: [Nouveau] [PATCH v2] nouveau: arm: Add MODULE_FIRMWARE for gk20a
On Wed, Nov 11, 2015 at 6:29 PM, Nicolas Chauvet wrote: > 2015-09-30 6:57 GMT+02:00 Alexandre Courbot : >> >> On Tue, Sep 29, 2015 at 12:08 AM, Nicolas Chauvet >> wrote: >> > This patch is needed by initramfs tools to detect >> > the required firmware files for the module. >> > >> > This patch tests for either TEGRA_124_SOC or TEGRA_132_SOC >> > for the firmwares related to the Tegra K1 generation. >> > >> > v2: move the MODULE_FIRMWARE to the nvidia_platform.c file. >> > This will avoid to test for NOUVEAU_PLATFORM_DRIVER >> >> Nice, thanks for doing this change! >> >> Reviewed-by: Alexandre Courbot > > > Thx for the review. > FYI I've tested the patch on top of 4.3+ kernels, and the initramfs > generated with dracut works as expected. > > Is there any other concern with this patch ? > > It's certainly late for 4.4,I would expect it to hit kernel 4.3 at some > point, but I don't think everything is wired from userspace(Xorg/Wayland) > wrt dGPU support. > So It could also wait for 4.5. > What do you think ? I don't see a particular reason to hurry, however this patch has been sitting around for one month now - Ben, is there any particular reason for not merging it? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
