[Nouveau] [Bug 92013] [NVA0] 4.3-rc1 fan set to full speed after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=92013 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Peres --- Let's close this bug then. Thanks for reporting the issue and testing the patch! -- 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 92192] New: nouveau does not detect monitor native resolution
https://bugs.freedesktop.org/show_bug.cgi?id=92192 Bug ID: 92192 Summary: nouveau does not detect monitor native resolution Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: germano.massu...@gmail.com QA Contact: xorg-t...@lists.x.org Created attachment 118534 --> https://bugs.freedesktop.org/attachment.cgi?id=118534&action=edit Xorg.0.log I am writing from a machine with a monitor that uses VGA cable. xrandr shows only 1024x768 as max resolution but the monitor supports 1680x1050 # xrandr Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192 VGA-1 disconnected (normal left inverted right x axis y axis) VGA-2 connected primary 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.00* 800x600 60.3256.25 848x480 60.00 640x480 59.94 HDMI-1 disconnected (normal left inverted right x axis y axis # lspci | grep VGA 01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [GeForce GT 240] (rev a2) -- 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 92192] nouveau does not detect monitor native resolution
https://bugs.freedesktop.org/show_bug.cgi?id=92192 --- Comment #1 from Germano Massullo --- Created attachment 118535 --> https://bugs.freedesktop.org/attachment.cgi?id=118535&action=edit dmesg -- 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 92192] nouveau does not detect monitor native resolution
https://bugs.freedesktop.org/show_bug.cgi?id=92192 --- Comment #2 from Germano Massullo --- Created attachment 118536 --> https://bugs.freedesktop.org/attachment.cgi?id=118536&action=edit vbios.rom -- 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 92192] nouveau does not detect monitor native resolution (Geforce GT240 / GT215)
https://bugs.freedesktop.org/show_bug.cgi?id=92192 Germano Massullo changed: What|Removed |Added Summary|nouveau does not detect |nouveau does not detect |monitor native resolution |monitor native resolution ||(Geforce GT240 / GT215) -- 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 92192] nouveau does not detect monitor native resolution (Geforce GT240 / GT215)
https://bugs.freedesktop.org/show_bug.cgi?id=92192 --- Comment #3 from Germano Massullo --- I could not reboot with log_buf_len=1M kernel flag, but let me know if you think it is needed to get a better dmesg log. -- 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] [PATCH] [resend] nouveau: Disable AGP for SiS 761
SiS 761 chipset does not support AGP cards but has AGP capability (for
the onboard video). At least PC Chips A31G board using this chipset has
an AGP-like AGPro slot that's wired to the PCI bus. Enabling AGP will
fail (GPU lockup and software fbcon, X11 hangs).
Add support for matching just the host bridge in nvkm_device_agp_quirks
and add entry for SiS 761 with mode 0 (AGP disabled).
Signed-off-by: Ondrej Zary
---
drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
index 814cb51..385a90f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
@@ -35,6 +35,8 @@ static const struct nvkm_device_agp_quirk
nvkm_device_agp_quirks[] = {
/* VIA Apollo PRO133x / GeForce FX 5600 Ultra - fdo#20341 */
{ PCI_VENDOR_ID_VIA, 0x0691, PCI_VENDOR_ID_NVIDIA, 0x0311, 2 },
+ /* SiS 761 does not support AGP cards, use PCI mode */
+ { PCI_VENDOR_ID_SI, 0x0761, PCI_ANY_ID, PCI_ANY_ID, 0 },
{},
};
@@ -137,8 +139,10 @@ nvkm_agp_ctor(struct nvkm_pci *pci)
while (quirk->hostbridge_vendor) {
if (info.device->vendor == quirk->hostbridge_vendor &&
info.device->device == quirk->hostbridge_device &&
- pci->pdev->vendor == quirk->chip_vendor &&
- pci->pdev->device == quirk->chip_device) {
+ (quirk->chip_vendor == (u16)PCI_ANY_ID ||
+ pci->pdev->vendor == quirk->chip_vendor) &&
+ (quirk->chip_device == (u16)PCI_ANY_ID ||
+ pci->pdev->device == quirk->chip_device)) {
nvkm_info(subdev, "forcing default agp mode to %dX, "
"use NvAGP= to override\n",
quirk->mode);
--
Ondrej Zary
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] [resend] nouveau: Disable AGP for SiS 761
This patch has been merged by Ben yesterday.
http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=8c713f90a63ffca10d122af09d439f3409c933ed
Why do you send a new version ? Is the previous patch wrong?
On 09/30/2015 01:48 PM, Ondrej Zary wrote:
SiS 761 chipset does not support AGP cards but has AGP capability (for
the onboard video). At least PC Chips A31G board using this chipset has
an AGP-like AGPro slot that's wired to the PCI bus. Enabling AGP will
fail (GPU lockup and software fbcon, X11 hangs).
Add support for matching just the host bridge in nvkm_device_agp_quirks
and add entry for SiS 761 with mode 0 (AGP disabled).
Signed-off-by: Ondrej Zary
---
drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
index 814cb51..385a90f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
@@ -35,6 +35,8 @@ static const struct nvkm_device_agp_quirk
nvkm_device_agp_quirks[] = {
/* VIA Apollo PRO133x / GeForce FX 5600 Ultra - fdo#20341 */
{ PCI_VENDOR_ID_VIA, 0x0691, PCI_VENDOR_ID_NVIDIA, 0x0311, 2 },
+ /* SiS 761 does not support AGP cards, use PCI mode */
+ { PCI_VENDOR_ID_SI, 0x0761, PCI_ANY_ID, PCI_ANY_ID, 0 },
{},
};
@@ -137,8 +139,10 @@ nvkm_agp_ctor(struct nvkm_pci *pci)
while (quirk->hostbridge_vendor) {
if (info.device->vendor == quirk->hostbridge_vendor &&
info.device->device == quirk->hostbridge_device &&
- pci->pdev->vendor == quirk->chip_vendor &&
- pci->pdev->device == quirk->chip_device) {
+ (quirk->chip_vendor == (u16)PCI_ANY_ID ||
+ pci->pdev->vendor == quirk->chip_vendor) &&
+ (quirk->chip_device == (u16)PCI_ANY_ID ||
+ pci->pdev->device == quirk->chip_device)) {
nvkm_info(subdev, "forcing default agp mode to %dX, "
"use NvAGP= to override\n",
quirk->mode);
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] [resend] nouveau: Disable AGP for SiS 761
On Wednesday 30 September 2015, Samuel Pitoiset wrote: > This patch has been merged by Ben yesterday. > > http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=8c713f90a63ffca10d >122af09d439f3409c933ed > > Why do you send a new version ? Is the previous patch wrong? Oops, sorry. Didn't notice it was merged. -- Ondrej Zary ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 81690] nouveau GPU locks up under memory pressure
https://bugs.freedesktop.org/show_bug.cgi?id=81690 --- Comment #8 from Michal Suchanek --- Hello, do you have a test program that triggers this without much dependencies which you can upload? Comment #1 says something about uploading large texture array. -- 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 89558] [NV118] GM108 not supported by nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=89558 --- Comment #40 from Andrey Borzenkov --- Using current kernel.org git as of dd36d7393d6310b0c1adefb22fba79c3cf8a577c and adding 0x118 to select 0x117 driver I get [ 67.595247] nouveau: module verification failed: signature and/or required key missing - tainting kernel [ 67.601091] MXM: GUID detected in BIOS [ 67.601144] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95) [ 67.601182] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95) [ 67.601330] pci :03:00.0: optimus capabilities: enabled, status dynamic power, hda bios codec supported [ 67.601331] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.RP05.PEGP handle [ 67.601380] nouveau :03:00.0: enabling device (0006 -> 0007) [ 67.601421] nouveau :03:00.0: NVIDIA GM107 (118000a2) [ 67.614439] nouveau :03:00.0: bios: version 82.08.18.00.2a [ 67.698727] nouveau :03:00.0: fb: 2048 MiB DDR3 [ 67.698759] nouveau :03:00.0: priv: HUB0: 6013d4 5730 (1b408200) [ 67.698795] nouveau :03:00.0: priv: HUB0: 10ecc0 (1840822c) [ 68.975809] vga_switcheroo: enabled [ 68.975924] [TTM] Zone kernel: Available graphics memory: 4031282 kiB [ 68.975925] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 68.975936] [TTM] Initializing pool allocator [ 68.975940] [TTM] Initializing DMA pool allocator [ 68.975950] nouveau :03:00.0: DRM: VRAM: 2048 MiB [ 68.975951] nouveau :03:00.0: DRM: GART: 1048576 MiB [ 68.975953] nouveau :03:00.0: DRM: Pointer to TMDS table invalid [ 68.975955] nouveau :03:00.0: DRM: DCB version 4.0 [ 68.975956] nouveau :03:00.0: DRM: Pointer to flat panel table invalid [ 69.132692] nouveau :03:00.0: DRM: MM: using COPY for buffer copies [ 69.132701] [drm] Initialized nouveau 1.3.0 20120801 for :03:00.0 on minor 1 /dev/dri nodes are correctly created for a second card. Unfortunately attempt to actually run something on secondary GPU results in [ 184.755] (II) [drm] nouveau interface version: 1.3.0 [ 184.755] (EE) Unknown chipset: NV118 While running up to date kernel is easy, getting up to date Xorg is probably more challenging (I'm writing this on Ubuntu 14.04). But kernel side looks promising. Please let me know if you need any additional logs from nouveau or nVidia driver. -- 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] Documentation request for MP warp error 0x10
Hello, I've recently come across an error reported by the GPU and would like to know what it means and especially what causes it to be triggered. Any information would be very useful: I'm seeing MP warp error 0x10 (appears in MP register 0x48). This is what we currently have in nouveau: [Additionally it seems like 15 = UNALIGNED_MEM_ACCESS] It seems to happen whenever I try to access global memory on kepler (potentially only atomics, not sure at this point). Knowing precisely what causes the error to get triggered (and esp what we need to do in order not to trigger it) would be most useful. For reference, my shader looks something like this (for SM35): /*0018*/ LDC.64 R0, c[0xf][0x1c0]; /* 0x7ca80780e01ffc02 */ /*0020*/ ATOM.E.ADD R2, [R0], R2; /* 0x6808011c000a */ /*0028*/ LD.E.CG R0, [R0]; /* 0xcc80001c */ I know that the proprietary drivers are a lot more sophisticated and only do the atomic add from a single lane, but I was assuming that was not required. Thanks, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89558] [NV118] GM108 not supported by nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=89558 --- Comment #41 from Ilia Mirkin --- (In reply to Andrei Borzenkov from comment #40) > /dev/dri nodes are correctly created for a second card. Unfortunately > attempt to actually run something on secondary GPU results in > > [ 184.755] (II) [drm] nouveau interface version: 1.3.0 > [ 184.755] (EE) Unknown chipset: NV118 The nouveau DDX won't do anything useful for maxwell. Use the modesetting driver. Do note that there are known problems with GLAMOR. But chances are there are no outputs on the GM108 anyways, so that won't be an issue. -- 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 89558] [NV118] GM108 not supported by nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=89558 --- Comment #42 from Andrei Borzenkov --- (In reply to Ilia Mirkin from comment #41) > Use the modesetting driver. Does not work - I do not get any output (but as said, I have quite dated Xorg). Anyway, the whole point of Optimus systems is to use discrete GPU for hardware acceleration; using generic driver seems to defeat it ... -- 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 89558] [NV118] GM108 not supported by nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=89558 --- Comment #43 from Ilia Mirkin --- (In reply to Andrei Borzenkov from comment #42) > (In reply to Ilia Mirkin from comment #41) > > Use the modesetting driver. > > Does not work - I do not get any output (but as said, I have quite dated > Xorg). Anyway, the whole point of Optimus systems is to use discrete GPU for > hardware acceleration; using generic driver seems to defeat it ... How so? With a modern Xorg you should be able to do 3 things: (a) use modesetting + glamor on any hardware with libGL support to get X operation acceleration [which is not something you care about since you're not going to use the GM108 as a primary] (b) use xrandr-based gpu offloading to get DRI2 offloading with DRI_PRIME=1 (c) use DRI3-based offloading with DRI_PRIME=1 assuming your intel ddx has that enabled Note how nowhere in there is there any mention of a nouveau ddx. -- 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 7/9] fb/ramnv50: Script changes for G94 and up
Hey Ben,
--- original message ---
From: Ben Skeggs
Date: 05:05:34 30-09-2015
To: Roy Spliet , Nouveau Mailinglist
Subject: Re: [PATCH 7/9] fb/ramnv50: Script changes for G94 and up
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 09/30/2015 09:23 AM, Roy Spliet wrote:
> > 10053c is not even read on some cards, and I have no idea exactly
> > what the criteria are. Likely NVIDIA pre-scans the VBIOS and in
> > their driver disables all features that are never used. The
> > practical effect should be the same as this implementation though.
> I haven't fully reviewed the series properly yet, but wanted to put my
> two cents worth in here.
>
> If this works like it does on Kepler, you're going to get bitten here
> if you don't do this correctly.
> [snip]
> Depending on what DEVINIT did, this can leave something either enabled
> or disabled, you don't know which, you're just supposed to just not
> touch it.
Yes, this is precisely what I have observed, but thanks for restating.
I realise I have been living on the edge by ignoring this for now.
Quite honestly though, I haven't come across an example where this would
become a problem *yet*. I reckon this is something you could expect
a follow-up patch for once I have time for it.
>
> I tried to ignore this on Kepler initially, but eventually got bitten
> by it and had to implement it properly (gk104_ram_ctor_data() handles
> this for the most part).
>
> I'd *strongly* recommend you verify if the behaviour is the same on
> these boards, and implement it if it is.
Agreed, but given I am probably running out of time quite soon, I do
recommend taking the current work upstream as is or suggest minor
fixes, and not first wait for this proposed change. That's purely
from a practical stance: what I pushed to the ML are improvements.
Some people benefit from it and it'd be a shame to let that bit-rot.
Roy.
>
> Ben.
>
> >
> > Signed-off-by: Roy Spliet Tested-by: Pierre
>
> > Moreau ---
> > drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv50.c | 36
> > 1 file changed, 30 insertions(+), 6
> > deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv50.c
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv50.c index
> > 1c6ae6b..651b74a 100644 ---
> > a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv50.c +++
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv50.c @@ -302,6 +302,9
>
> > @@ nv50_ram_calc(struct nvkm_ram *base, u32 freq) return ret; }
> >
> > + if (subdev->device->chipset <= 0x96 &&
> > !next->bios.ramcfg_00_03_02) + ram_mask(hwsq, 0x100710,
> > 0x0200, 0x); + /* Always disable this bit during
> > reclock */ ram_mask(hwsq, 0x100200, 0x0800, 0x);
> >
> > @@ -353,8 +356,11 @@ nv50_ram_calc(struct nvkm_ram *base, u32
> > freq) next->bios.rammap_00_16_40 << 14); ram_mask(hwsq, 0x00400c,
>
> > 0x, (N1 << 8) | M1); ram_mask(hwsq, 0x004008, 0x91ff,
>
> > r004008); - if (subdev->device->chipset >= 0x96) + +/* XXX:
> GDDR3
> > only? */ + if (subdev->device->chipset >= 0x92) ram_wr32(hwsq,
>
> > 0x100da0, r100da0); + nv50_ram_gpio(hwsq, 0x18,
> > !next->bios.ramcfg_FBVDDQ); ram_nsec(hwsq, 64000); /*XXX*/
> > ram_nsec(hwsq, 32000); /*XXX*/ @@ -397,19 +403,33 @@
> > nv50_ram_calc(struct nvkm_ram *base, u32 freq) ram_mask(hwsq,
> > 0x100200, 0x1000, !next->bios.ramcfg_00_04_02 << 12);
> >
> > /* XXX: A lot of this could be "chipset"/"ram type"
> specific stuff
> > */ -unk710 = ram_rd32(hwsq, 0x100710) & ~0x0101; + unk710
> =
> > ram_rd32(hwsq, 0x100710) & ~0x0100; unk714 = ram_rd32(hwsq,
>
> > 0x100714) & ~0xf020; unk718 = ram_rd32(hwsq, 0x100718) &
>
> > ~0x0100; unk71c = ram_rd32(hwsq, 0x10071c) & ~0x0100; +
> if
> > (subdev->device->chipset <= 0x96) { + unk710 &= ~0x006e;
> +
> > unk714 &= ~0x0100; + + if (!next->bios.ramcfg_00_03_08)
> +
> > unk710 |= 0x0060; + if (!next->bios.ramcfg_FBVDDQ) +
> > unk714
>
> > |= 0x0100; +if ( next->bios.ramcfg_00_04_04) +
> > unk710 |=
>
> > 0x000e; + } else { + unk710 &= ~0x0001; + +
> > if
> > (!next->bios.ramcfg_00_03_08) + unk710 |= 0x0001; +
> > }
> >
> > if ( next->bios.ramcfg_00_03_01) unk71c |= 0x0100; if (
> > next->bios.ramcfg_00_03_02) unk710 |= 0x0100; - if
> > (!next->bios.ramcfg_00_03_08) { - unk710 |= 0x1; -
> > unk714 |=
> > 0x20; - } + if (!next->bios.ramcfg_00_03_08) + unk714
> > |=
> > 0x0020; if ( next->bios.ramcfg_00_04_04) unk714 |= 0x7000;
>
> > if ( next->bios.ramcfg_00_04_20) @@ -420,6 +440,8 @@
> > nv50_ram_calc(struct nvkm_ram *base, u32 freq) ram_mask(hwsq,
> > 0x100718, 0x, unk718); ram_mask(hwsq, 0x100710, 0x,
>
> > unk710);
> >
> > + /* XXX: G94 does not even test these regs
[Nouveau] [PATCH v4] pci: Handle 5-bit and 8-bit tag field
If the hardware supports extended tag field (8-bit ones), then enabled it. This
is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
In case extended tag field is not supported, 5-bit tag field is used which
limits the possible values to 32. Apparently bits 7:0 of 0x8841c stores some
number of outstanding requests, so cap it to 32 if extended tag is unsupported.
Fixes: fdo#86537
v2: Restrict changes to chipsets >= 0x84
v3:
* Add nvkm_pci_mask to pci.h
* Mask bit 8 before setting it
v4:
* Rename `add` argument of nvkm_pci_mask to `value`
* Move code from nvkm_pci_init to g84_pci_init and remove PCIe and chipset
checks
Signed-off-by: Pierre Moreau
---
drm/nouveau/include/nvkm/subdev/pci.h | 4 +++
drm/nouveau/nvkm/engine/device/base.c | 64 +--
drm/nouveau/nvkm/subdev/pci/Kbuild| 1 +
drm/nouveau/nvkm/subdev/pci/base.c| 43 ---
drm/nouveau/nvkm/subdev/pci/g84.c | 55 ++
drm/nouveau/nvkm/subdev/pci/gf100.c | 6
drm/nouveau/nvkm/subdev/pci/nv40.c| 6
drm/nouveau/nvkm/subdev/pci/nv50.c| 6
drm/nouveau/nvkm/subdev/pci/priv.h| 11 ++
9 files changed, 159 insertions(+), 37 deletions(-)
create mode 100644 drm/nouveau/nvkm/subdev/pci/g84.c
diff --git a/drm/nouveau/include/nvkm/subdev/pci.h
b/drm/nouveau/include/nvkm/subdev/pci.h
index 5b3c054..ab79fd0 100644
--- a/drm/nouveau/include/nvkm/subdev/pci.h
+++ b/drm/nouveau/include/nvkm/subdev/pci.h
@@ -24,11 +24,15 @@ struct nvkm_pci {
u32 nvkm_pci_rd32(struct nvkm_pci *, u16 addr);
void nvkm_pci_wr08(struct nvkm_pci *, u16 addr, u8 data);
void nvkm_pci_wr32(struct nvkm_pci *, u16 addr, u32 data);
+u32 nvkm_pci_mask(struct nvkm_pci *, u16 addr, u32 mask, u32 value);
void nvkm_pci_rom_shadow(struct nvkm_pci *, bool shadow);
int nv04_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
int nv40_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
+int nv40_pci_new_g84_init(struct nvkm_device *, int, struct nvkm_pci **);
int nv4c_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
int nv50_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
+int nv50_pci_new_g84_init(struct nvkm_device *, int, struct nvkm_pci **);
int gf100_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
+int gf100_pci_new_g84_init(struct nvkm_device *, int, struct nvkm_pci **);
#endif
diff --git a/drm/nouveau/nvkm/engine/device/base.c
b/drm/nouveau/nvkm/engine/device/base.c
index acc2fe9..9b19b52 100644
--- a/drm/nouveau/nvkm/engine/device/base.c
+++ b/drm/nouveau/nvkm/engine/device/base.c
@@ -929,7 +929,7 @@ nv84_chipset = {
.mc = nv50_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
- .pci = nv50_pci_new,
+ .pci = nv50_pci_new_g84_init,
.therm = g84_therm_new,
.timer = nv41_timer_new,
.volt = nv40_volt_new,
@@ -961,7 +961,7 @@ nv86_chipset = {
.mc = nv50_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
- .pci = nv50_pci_new,
+ .pci = nv50_pci_new_g84_init,
.therm = g84_therm_new,
.timer = nv41_timer_new,
.volt = nv40_volt_new,
@@ -993,7 +993,7 @@ nv92_chipset = {
.mc = nv50_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
- .pci = nv50_pci_new,
+ .pci = nv50_pci_new_g84_init,
.therm = g84_therm_new,
.timer = nv41_timer_new,
.volt = nv40_volt_new,
@@ -1025,7 +1025,7 @@ nv94_chipset = {
.mc = nv50_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
- .pci = nv40_pci_new,
+ .pci = nv40_pci_new_g84_init,
.therm = g84_therm_new,
.timer = nv41_timer_new,
.volt = nv40_volt_new,
@@ -1057,7 +1057,7 @@ nv96_chipset = {
.mc = nv50_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
- .pci = nv40_pci_new,
+ .pci = nv40_pci_new_g84_init,
.therm = g84_therm_new,
.timer = nv41_timer_new,
.volt = nv40_volt_new,
@@ -1089,7 +1089,7 @@ nv98_chipset = {
.mc = g98_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
- .pci = nv40_pci_new,
+ .pci = nv40_pci_new_g84_init,
.therm = g84_therm_new,
.timer = nv41_timer_new,
.volt = nv40_volt_new,
@@ -1121,7 +1121,7 @@ nva0_chipset = {
.mc = g98_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
- .pci = nv40_pci_new,
+ .pci = nv40_pci_new_g84_init,
.therm = g84_therm_new,
.timer = nv41_timer_new,
.volt = nv40_volt_new,
@@ -1153,7 +1153,7 @@ nva3_chipset = {
.mc = g98_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
- .pci = nv40_pci_new,
+ .pci = nv40_pci_new_g84_init,
.pmu = gt215_pmu_new,
.therm = gt215_therm_new,
.timer = nv41_timer_new,
@@ -1187,7 +1187,7 @@ nva5_chipset = {
.mc = g98_mc_new,
.mmu
[Nouveau] [Bug 70354] [NVE6, NVE7] HUB_INIT timeout on graph init, blob fw doesn't help
https://bugs.freedesktop.org/show_bug.cgi?id=70354 --- Comment #64 from Ben Skeggs --- (In reply to Bozhan Boyadzhiev from comment #63) > (In reply to Ben Skeggs from comment #62) > > (In reply to Bozhan Boyadzhiev from comment #61) > > > Created attachment 116853 [details] > > > mmiotrace for GK107 ~39MB > > > > > > mmiotrace for GK107 > > > > Heh, so much for GK107 not having PGOB... I'll ping NVIDIA on this one and > > get back to you. If I get time in the next few days, I'll hack you up a > > patch. > > i've erased the first letter on my keyboard with which begins the domain of > my webmail to check if i have message from this bug :))) My nouveau tree[1] has a couple of patches that will *hopefully* fix the issues you're seeing. [1] http://cgit.freedesktop.org/~darktama/nouveau/log/ -- 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
