[Nouveau] [PATCH] platform: disable probe of GM20B
On 4.6, probing GM20B will freeze the system because of a missing clock that Nouveau must also enable. Since the DT bindings for this clock did not make it in time for 4.6, disable it for now. Signed-off-by: Alexandre Courbot --- Ben, sorry for that, but could you take this for one of the next -rc? I will re-enable GM20B once the DT bindings have landed. Thanks! drm/nouveau/nouveau_platform.c | 4 1 file changed, 4 deletions(-) diff --git a/drm/nouveau/nouveau_platform.c b/drm/nouveau/nouveau_platform.c index 2dfe58af12e4..af9ee2de4c4d 100644 --- a/drm/nouveau/nouveau_platform.c +++ b/drm/nouveau/nouveau_platform.c @@ -60,10 +60,6 @@ static const struct of_device_id nouveau_platform_match[] = { .compatible = "nvidia,gk20a", .data = &gk20a_platform_data, }, - { - .compatible = "nvidia,gm20b", - .data = &gk20a_platform_data, - }, { } }; -- 2.7.3 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GM108GLM?
Hello, Acceleration support for GM107 was merged in kernel 4.1, and modesetting support was added to 3.15. Which kernel version did you try? The GM108 chipset seems to be recognised since at least 2015/08/20. Regards, Pierre Moreau On 02:55 PM - Mar 29 2016, Sune Mølgaard wrote: > Hiya, > > Is there any change for Quadro K620M support at some point in time, and > what can I do to help, apart from the info below? > > Best regards, > > Sune Mølgaard > > dmesg |grep -i nouveau > [1.164919] nouveau :08:00.0: unknown chipset (1183a0a2) > [1.164943] nouveau: probe of :08:00.0 failed with error -12 > > lspci|grep -i nvidi > 08:00.0 3D controller: NVIDIA Corporation GM108GLM [Quadro K620M] (rev a2) > ___ > 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] GM108GLM?
Actually GM108 is not one of the recognized chips. Someone needs to go through and check that its goldens didn't change. Nobody's done that. See https://bugs.freedesktop.org/show_bug.cgi?id=89558 On Thu, Mar 31, 2016 at 4:57 PM, Pierre Moreau wrote: > Hello, > > Acceleration support for GM107 was merged in kernel 4.1, and modesetting > support was added to 3.15. Which kernel version did you try? The GM108 chipset > seems to be recognised since at least 2015/08/20. > > Regards, > > Pierre Moreau > > > On 02:55 PM - Mar 29 2016, Sune Mølgaard wrote: >> Hiya, >> >> Is there any change for Quadro K620M support at some point in time, and >> what can I do to help, apart from the info below? >> >> Best regards, >> >> Sune Mølgaard >> >> dmesg |grep -i nouveau >> [1.164919] nouveau :08:00.0: unknown chipset (1183a0a2) >> [1.164943] nouveau: probe of :08:00.0 failed with error -12 >> >> lspci|grep -i nvidi >> 08:00.0 3D controller: NVIDIA Corporation GM108GLM [Quadro K620M] (rev a2) >> ___ >> 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 > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GM108GLM?
Oh, hum, GM108 is NV118 and not NV108 which is Gk208… My bad! SMF from the bug report seemed to have some working setup, and since he didn't pinged back, I guess it's working nicely. But some more checking might still be needed? On 04:59 PM - Mar 31 2016, Ilia Mirkin wrote: > Actually GM108 is not one of the recognized chips. Someone needs to go > through and check that its goldens didn't change. Nobody's done that. > > See https://bugs.freedesktop.org/show_bug.cgi?id=89558 > > On Thu, Mar 31, 2016 at 4:57 PM, Pierre Moreau wrote: > > Hello, > > > > Acceleration support for GM107 was merged in kernel 4.1, and modesetting > > support was added to 3.15. Which kernel version did you try? The GM108 > > chipset > > seems to be recognised since at least 2015/08/20. > > > > Regards, > > > > Pierre Moreau > > > > > > On 02:55 PM - Mar 29 2016, Sune Mølgaard wrote: > >> Hiya, > >> > >> Is there any change for Quadro K620M support at some point in time, and > >> what can I do to help, apart from the info below? > >> > >> Best regards, > >> > >> Sune Mølgaard > >> > >> dmesg |grep -i nouveau > >> [1.164919] nouveau :08:00.0: unknown chipset (1183a0a2) > >> [1.164943] nouveau: probe of :08:00.0 failed with error -12 > >> > >> lspci|grep -i nvidi > >> 08:00.0 3D controller: NVIDIA Corporation GM108GLM [Quadro K620M] (rev a2) > >> ___ > >> 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 > > > ___ > 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] platform: disable probe of GM20B
Mmm actually I think we can get the same result if we just try and probe the clock in question - it will fail for 4.6, but at least it will not crash. Withdrawing this patch. On Thu, Mar 31, 2016 at 6:03 PM, Alexandre Courbot wrote: > On 4.6, probing GM20B will freeze the system because of a missing clock > that Nouveau must also enable. Since the DT bindings for this clock > did not make it in time for 4.6, disable it for now. > > Signed-off-by: Alexandre Courbot > --- > Ben, sorry for that, but could you take this for one of the next -rc? I > will re-enable GM20B once the DT bindings have landed. Thanks! > > drm/nouveau/nouveau_platform.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drm/nouveau/nouveau_platform.c b/drm/nouveau/nouveau_platform.c > index 2dfe58af12e4..af9ee2de4c4d 100644 > --- a/drm/nouveau/nouveau_platform.c > +++ b/drm/nouveau/nouveau_platform.c > @@ -60,10 +60,6 @@ static const struct of_device_id nouveau_platform_match[] > = { > .compatible = "nvidia,gk20a", > .data = &gk20a_platform_data, > }, > - { > - .compatible = "nvidia,gm20b", > - .data = &gk20a_platform_data, > - }, > { } > }; > > -- > 2.7.3 > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] tegra: acquire and enable reference clock if needed
GM20B requires an extra clock compared to GK20A. Add that information into the platform data and acquire and enable this clock if necessary. Signed-off-by: Alexandre Courbot --- Hi Ben, The DT bindings for this have been approved but not merged yet. This means that for 4.6 GM20B will fail to probe unless the DT is patched - but this is better than the current situation where it silently freezes. Can you take this for the next -rc? Thanks! drm/nouveau/include/nvkm/core/tegra.h | 5 + drm/nouveau/nouveau_platform.c | 7 ++- drm/nouveau/nvkm/engine/device/tegra.c | 17 + 3 files changed, 28 insertions(+), 1 deletion(-) diff --git a/drm/nouveau/include/nvkm/core/tegra.h b/drm/nouveau/include/nvkm/core/tegra.h index 16641cec18a2..b5370cb56e3c 100644 --- a/drm/nouveau/include/nvkm/core/tegra.h +++ b/drm/nouveau/include/nvkm/core/tegra.h @@ -11,6 +11,7 @@ struct nvkm_device_tegra { struct reset_control *rst; struct clk *clk; + struct clk *clk_ref; struct clk *clk_pwr; struct regulator *vdd; @@ -36,6 +37,10 @@ struct nvkm_device_tegra_func { * bypassed). A value of 0 means an IOMMU is never used. */ u8 iommu_bit; + /* +* Whether the chip requires a reference clock +*/ + bool require_ref_clk; }; int nvkm_device_tegra_new(const struct nvkm_device_tegra_func *, diff --git a/drm/nouveau/nouveau_platform.c b/drm/nouveau/nouveau_platform.c index 2dfe58af12e4..4c4cc2260257 100644 --- a/drm/nouveau/nouveau_platform.c +++ b/drm/nouveau/nouveau_platform.c @@ -55,6 +55,11 @@ static const struct nvkm_device_tegra_func gk20a_platform_data = { .iommu_bit = 34, }; +static const struct nvkm_device_tegra_func gm20b_platform_data = { + .iommu_bit = 34, + .require_ref_clk = true, +}; + static const struct of_device_id nouveau_platform_match[] = { { .compatible = "nvidia,gk20a", @@ -62,7 +67,7 @@ static const struct of_device_id nouveau_platform_match[] = { }, { .compatible = "nvidia,gm20b", - .data = &gk20a_platform_data, + .data = &gm20b_platform_data, }, { } }; diff --git a/drm/nouveau/nvkm/engine/device/tegra.c b/drm/nouveau/nvkm/engine/device/tegra.c index 9afa5f3e3c1c..ec12efb4689a 100644 --- a/drm/nouveau/nvkm/engine/device/tegra.c +++ b/drm/nouveau/nvkm/engine/device/tegra.c @@ -35,6 +35,11 @@ nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev) ret = clk_prepare_enable(tdev->clk); if (ret) goto err_clk; + if (tdev->clk_ref) { + ret = clk_prepare_enable(tdev->clk_ref); + if (ret) + goto err_clk_ref; + } ret = clk_prepare_enable(tdev->clk_pwr); if (ret) goto err_clk_pwr; @@ -57,6 +62,9 @@ nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev) err_clamp: clk_disable_unprepare(tdev->clk_pwr); err_clk_pwr: + if (tdev->clk_ref) + clk_disable_unprepare(tdev->clk_ref); +err_clk_ref: clk_disable_unprepare(tdev->clk); err_clk: regulator_disable(tdev->vdd); @@ -71,6 +79,8 @@ nvkm_device_tegra_power_down(struct nvkm_device_tegra *tdev) udelay(10); clk_disable_unprepare(tdev->clk_pwr); + if (tdev->clk_ref) + clk_disable_unprepare(tdev->clk_ref); clk_disable_unprepare(tdev->clk); udelay(10); @@ -274,6 +284,13 @@ nvkm_device_tegra_new(const struct nvkm_device_tegra_func *func, goto free; } + if (func->require_ref_clk) + tdev->clk_ref = devm_clk_get(&pdev->dev, "ref"); + if (IS_ERR(tdev->clk_ref)) { + ret = PTR_ERR(tdev->clk_ref); + goto free; + } + tdev->clk_pwr = devm_clk_get(&pdev->dev, "pwr"); if (IS_ERR(tdev->clk_pwr)) { ret = PTR_ERR(tdev->clk_pwr); -- 2.7.3 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] secboot: print status message on success
Ourput an info message when secure boot has been successfully performed. This is useful when troubleshooting issues that may be caused by firmware loading being delayed - without an explicit message we have no way to know whether secure boot has been performed or not. Signed-off-by: Alexandre Courbot --- This has been inspired by Ilia's comment on FD bug 94725. Will be useful to have for future cases like this one. drm/nouveau/nvkm/subdev/secboot/base.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/secboot/base.c b/drm/nouveau/nvkm/subdev/secboot/base.c index 520facf9bc07..a4f314803137 100644 --- a/drm/nouveau/nvkm/subdev/secboot/base.c +++ b/drm/nouveau/nvkm/subdev/secboot/base.c @@ -135,7 +135,8 @@ nvkm_secboot_falcon_reset(struct nvkm_secboot *sb) int nvkm_secboot_falcon_run(struct nvkm_secboot *sb) { - struct nvkm_device *device = sb->subdev.device; + struct nvkm_subdev *subdev = &sb->subdev; + struct nvkm_device *device = subdev->device; int ret; /* Start falcon */ @@ -149,11 +150,13 @@ nvkm_secboot_falcon_run(struct nvkm_secboot *sb) /* If mailbox register contains an error code, then ACR has failed */ ret = nvkm_rd32(device, sb->base + 0x040); if (ret) { - nvkm_error(&sb->subdev, "ACR boot failed, ret 0x%08x", ret); + nvkm_error(subdev, "ACR boot failed, ret 0x%08x", ret); falcon_clear_halt_interrupt(device, sb->base); return -EINVAL; } + nvkm_info(subdev, "signed firmware successfully loaded\n"); + return 0; } -- 2.7.3 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 94725] Nouveau driver fails to poweron GPU on GM204 after dynamic poweroff
https://bugs.freedesktop.org/show_bug.cgi?id=94725 --- Comment #6 from Alexandre Courbot --- Maybe these messages are pointing to the root of the problem: [ 51.608479] nouveau :01:00.0: Refused to change power state, currently in D3 [ 51.683924] nouveau :01:00.0: Refused to change power state, currently in D3 [ 51.700020] nouveau :01:00.0: Refused to change power state, currently in D3 If the device is still in D3 when we resume it, then accessing registers would understandably result in a freeze. Devinit comes early enough in the resume chain to make this plausible. FWIW I can successfully suspend/resume (echo mem >/sys/power/state) a GTX 960, but runtime PM works slightly differently. I would like to enable runtime PM on my desktop GTX960 to repro this, but for some reason I am failing - despite loading nouveau with "modeset=2 runpm=1", I cannot see runtime PM kicking in and /sys/class/drm/card0/power/runtime_status says "unsupported". What am I doing wrong? -- 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 94725] Nouveau driver fails to poweron GPU on GM204 after dynamic poweroff
https://bugs.freedesktop.org/show_bug.cgi?id=94725 --- Comment #7 from Dave Airlie --- can you try booting with acpi_osi="!Windows 2013" on the kernel command line. -- 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] [PATCH] devinit/gf100: make devinit on resume safer
In case of successful suspend, devinit will have to be run and this is the behavior currently hardcoded. However, as FD bug 94725 suggests, there might be cases where runtime suspend leaves the GPU powered, and in such cases devinit should not be run on resume. On GF100+ we have a reliable way to know whether we need to run devinit. Use it instead of blindly trusting the flag set by nvkm_devinit_fini(). The code around the NvForcePost also needs to be slightly reworked in order to keep working. Signed-off-by: Alexandre Courbot Suggested-by: Dave Airlie Suggested-by: Karol Herbst --- drm/nouveau/include/nvkm/subdev/devinit.h | 1 + drm/nouveau/nvkm/subdev/devinit/base.c| 8 +++- drm/nouveau/nvkm/subdev/devinit/gf100.c | 8 +--- 3 files changed, 13 insertions(+), 4 deletions(-) diff --git a/drm/nouveau/include/nvkm/subdev/devinit.h b/drm/nouveau/include/nvkm/subdev/devinit.h index 193626c69517..709d786f1808 100644 --- a/drm/nouveau/include/nvkm/subdev/devinit.h +++ b/drm/nouveau/include/nvkm/subdev/devinit.h @@ -7,6 +7,7 @@ struct nvkm_devinit { const struct nvkm_devinit_func *func; struct nvkm_subdev subdev; bool post; + bool force_post; }; u32 nvkm_devinit_mmio(struct nvkm_devinit *, u32 addr); diff --git a/drm/nouveau/nvkm/subdev/devinit/base.c b/drm/nouveau/nvkm/subdev/devinit/base.c index 5f25402f6b09..9edd53773a19 100644 --- a/drm/nouveau/nvkm/subdev/devinit/base.c +++ b/drm/nouveau/nvkm/subdev/devinit/base.c @@ -83,6 +83,12 @@ nvkm_devinit_preinit(struct nvkm_subdev *subdev) if (init->func->preinit) init->func->preinit(init); + /* Override the post flag during the first call if NvForcePost is set */ + if (init->force_post) { + init->post = init->force_post; + init->force_post = false; + } + /* unlock the extended vga crtc regs */ nvkm_lockvgac(subdev->device, false); return 0; @@ -126,5 +132,5 @@ nvkm_devinit_ctor(const struct nvkm_devinit_func *func, { nvkm_subdev_ctor(&nvkm_devinit, device, index, 0, &init->subdev); init->func = func; - init->post = nvkm_boolopt(device->cfgopt, "NvForcePost", false); + init->force_post = nvkm_boolopt(device->cfgopt, "NvForcePost", false); } diff --git a/drm/nouveau/nvkm/subdev/devinit/gf100.c b/drm/nouveau/nvkm/subdev/devinit/gf100.c index 2923598b5fe9..8b1b34c3ad26 100644 --- a/drm/nouveau/nvkm/subdev/devinit/gf100.c +++ b/drm/nouveau/nvkm/subdev/devinit/gf100.c @@ -97,9 +97,11 @@ gf100_devinit_preinit(struct nvkm_devinit *base) struct nvkm_subdev *subdev = &init->base.subdev; struct nvkm_device *device = subdev->device; - /* This bit is set by devinit, and flips back to 0 on suspend */ - if (!base->post) - base->post = ((nvkm_rd32(device, 0x2240c) & BIT(1)) == 0); + /* +* This bit is set by devinit, and flips back to 0 on suspend. We +* can use it as a reliable way to know whether we should run devinit. +*/ + base->post = ((nvkm_rd32(device, 0x2240c) & BIT(1)) == 0); } static const struct nvkm_devinit_func -- 2.7.3 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 94725] Nouveau driver fails to poweron GPU on GM204 after dynamic poweroff
https://bugs.freedesktop.org/show_bug.cgi?id=94725 Alexandre Courbot changed: What|Removed |Added CC||gnu...@gmail.com --- Comment #8 from Alexandre Courbot --- Created attachment 122653 --> https://bugs.freedesktop.org/attachment.cgi?id=122653&action=edit Tentative fix The attached patch *might* help with this issue, but I have no way to test it. Rashed, Efrem, can one of you give it a try and tell us if it helps? -- 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 94725] Nouveau driver fails to poweron GPU on GM204 after dynamic poweroff
https://bugs.freedesktop.org/show_bug.cgi?id=94725 --- Comment #9 from Alexandre Courbot --- Dave, I tried adding the option you suggested, but it did not allow me to enable runtime PM, sadly. /sys/class/drm/card0/power/runtime_status still "unsupported" despite nouveau.ko being loaded with "modeset=2 runpm=1". -- 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