similar to: [PATCH] drm/nouveau: fix unknown chipset for GTX 1060

From: Chris Chiu <chiu at endlessm.com> This new graphics card was failing to initialize with nouveau due to an "unknown chipset" error. Copy the GP106 configuration and rename for GP107/NV137. We don't know for certain that this is fully correct, but brief desktop testing suggests this is working fine. Signed-off-by: Chris Chiu <chiu at endlessm.com> Signed-off-by:

On 12/12/2016 09:26 PM, Chris Chiu wrote: > Nouveau driver shows unknown chipset (136000a1) for GTX 1060, so it > only gives VGA resolution on screen. Use the same chipset as nv134 > then it shows FullHD. This commit copies fields from nv134_chipset > to nv136_chipset for GTX 1060. I have one of these sitting on my desk, but won't be merging support for it until it's been

I believe what's missing at this point is a mmiotrace of the NVIDIA driver to make sure that there's nothing different about this GPU. If you can make one (see https://wiki.ubuntu.com/X/MMIOTracing for a guide - should end up ~100MB uncompressed), please send a compressed one to mmio.dumps at gmail.com or make available some other way. On Tue, Feb 14, 2017 at 2:34 PM, Daniel Drake

Signed-off-by: Rhys Kidd <rhyskidd at gmail.com> --- .../gpu/drm/nouveau/include/nvkm/subdev/therm.h | 1 + drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 6 +++ drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 3 +- drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 57 ++++++++++++++++++++++ 5 files changed, 67

Forked from GP107 implementation. Secboot/gr left out as we don't have signed blobs from NVIDIA in linux-firmware. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101601 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drm/nouveau/nvkm/engine/device/base.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git

v2: - add nv138 and drop nv13b chipsets (Ilia Mirkin) - refactor out status variable and instead mask tsensor (Ilia Mirkin) - switch SHADOWed state message away from nvkm_error() (Ilia Mirkin) - rename internal temperature variable (Karol Herbst) Signed-off-by: Rhys Kidd <rhyskidd at gmail.com> --- .../gpu/drm/nouveau/include/nvkm/subdev/therm.h | 1 +

Hello everyone, I would like to submit a simple patch to let nouveau able to detect GTX 1050 / 1050ti cards. TESTED and WORKING on my computer with my GPU (Gigabyte GTX 1050ti OC edition). drivers/gpu/drm/nouveau/nvkm/engine/device/ base.c gpu_nouveau_gp107.patch 2272a2273,2301 > static const struct nvkm_device_chip > nv137_chipset = { > .name = "GP107", > .bar =

From: Jérôme Glisse <jglisse at redhat.com> (mm is cced just to allow exposure of device driver work without ccing a long list of peoples. I do not think there is anything usefull to discuss from mm point of view but i might be wrong, so just for the curious :)). git://people.freedesktop.org/~glisse/linux branch: nouveau-hmm-v00

GP10B is the chip used in Tegra X2 SoCs. This patchset adds support for its base engines after reworking secboot a bit to accomodate its calling convention better. This patchset has been tested rendering simple off-screen buffers using Mesa and yielded the expected result. Alexandre Courbot (15): secboot: allow to boot multiple falcons secboot: pass instance to LS firmware loaders secboot:

Following a series of three patches, two of which have been sitting in my tree for a while, the third is the result of some inspection of an NV134 BIOS that seems to use the 0xaf upcode to upload training patterns. Please test! Roy Ps. Sorry they come from yet another e-mail address. My previous provider, eclipso, actively blocks users of git send-email. Inquiries fall on deaf ears, hence I

As seen in at least one NV134 VBIOS (... that I obviously don't own myself). Signed-off-by: Roy Spliet <nouveau at spliet.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 27 +++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c index 38ed09f..a18f8b4 100644

https://bugs.freedesktop.org/show_bug.cgi?id=99900 --- Comment #27 from aaron.hamid at gmail.com --- I am encountering the same "kernel rejected pushbuf: Device or resource busy" crash/lock cited here and in https://bugs.freedesktop.org/show_bug.cgi?id=100567 I'm posting here as I don't see SCHED_ERROR in my systemd journal, and I can reliably trigger it by running qemu android

After observing random crashes on Tegra devices when patch "fb/gf100: defer DMA mapping of scratch page to oneinit() hook" was applied, I noticed that moving the 100c10 page allocation to the oneinit() hook resulted in that page being now allocated for Tegra as well, and accesses be made to members of gf100_fb which were not accessible because gk20a_fb_new() called nvkm_fb_new_()

gm20b's FB has the same capabilities as gm200, minus the ability to allocate RAM. Create a device that reflects this instead of re-using the gk20a device which may be incorrect. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/include/nvkm/subdev/fb.h | 1 + drm/nouveau/nvkm/engine/device/base.c | 2 +- drm/nouveau/nvkm/subdev/fb/Kbuild | 1 +

Hi, For the following case, $ cat bad1.ll target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32-S64" define internal void @test(i32 %v) { entry: %tmp = alloca i32, align 4 store i32 %v, i32* %tmp, align 4 %0 = bitcast i32* %tmp to <2 x i8>* %1 = load <2 x i8>* %0, align 4 ret void } I

Just wanted to post updated versions of my last series/patches. Reviews welcomed. It would be also nice if we agree on features I should focus upstreaming, so that this work can be better splitted or reordered. Sadly most of my patches depend on the rather big clk subdev rework and I think those patches shows best, why I think this rework is actually needed and makes things much easier to add

I've splitted my big series between the part which actually fixes the engine reclocking bits and the part handling voltage/clock updates on temperature change, so that the more reviewed parts can be merged in faster. This series fixes a lot of Engine reclocking issues found on Fermi, Kepler and all Maxwell generation GPUs. It does _not_ fix memory reclocking on Fermi. It mostly contains of