Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On 09/30/2013 01:27 PM, Peter Hurley wrote: On 09/03/2013 09:45 PM, Ben Skeggs wrote: Well, we can't just go around breaking stuff deliberately for the people still using them! I've blacklisted them myself and merged the patch. Ben, This patch causes my dual-head Quadro FX570 (G84) to fail to idle when dragging a window around. It loops for the full timeout (15 sec.) in nouveau_gem_ioctl_cpu_prep() -- ie., never reaches required fence sequence #. FWIW, I can get the binary 319.32 driver to run this hardware with MSIs on [1] and not crash in similar circumstances. But repeating the testing on 3.12.0-rc2/3 has proved challenging. Although I have the binary driver running on 3.12.0-rc2, the userspace won't fully come up and I haven't figured out why (it's an old userspace that I don't use regularly, so it could be some other problem). Regards, Peter Hurley [1] lspci -vvv -nn on 3.2.x 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84GL [Quadro FX 570] [10de:040e] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation Device [10de:0474] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 94 Region 0: Memory at de00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at c000 (64-bit, prefetchable) [size=256M] Region 3: Memory at dc00 (64-bit, non-prefetchable) [size=32M] Region 5: I/O ports at cc80 [size=128] [virtual] Expansion ROM at dfc0 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: fee1100c Data: 41c9 Capabilities: [78] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 512ns, L1 4us ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #8, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 512ns, L1 4us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis+ DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb:Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0:Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status: NegoPending- InProgress- Capabilities: [128 v1] Power Budgeting ? Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 ? Kernel driver in use: nvidia Kernel modules: nvidia_319_updates, nouveau, nvidiafb ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On 09/03/2013 09:45 PM, Ben Skeggs wrote:
On Fri, Aug 30, 2013 at 5:11 PM, Lucas Stach d...@lynxeye.de wrote:
Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs:
On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs skeg...@gmail.com wrote:
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?
Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC),
Cases like the nv34 here (i think there's some nv4x that aren't native
pcie too) are what I'm wondering about primarily.
And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
with AutoAddGPU disabled the NV18 and NV42 seem fine. However merely
starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
it (with no clients connecting to said X), causes a failed to idle
channel message in dmesg, which apparently never rectifies itself, so
X is hung forever. FTR, there were no displays connected either, but I
tried the exact same procedure without the MSI patch and it worked
fine. Here is the init sequence with the MSI patch:
I don't suppose bashing 0x1868 instead of 0x88068 works here? If not,
Should that work on the NV42 as well?
I believe so. NV4x has both the 0x18xx and 0x88xxx apertures I believe.
next thing would be to mmiotrace the binary driver and see if you can
make it enable+use MSI on it. I doubt the current legacy driver does
it by default, but there was some magic to enable it that you can
probably find if you google around.
I've yet to set up the legacy driver... I bet it doesn't compile on
3.11, so I'll have to patch it to nuke procfs/i2c...
[ 307.049812] nouveau [ DEVICE][:04:00.0] BOOT0 : 0x034a00b1
[ 307.049815] nouveau [ DEVICE][:04:00.0] Chipset: NV34 (NV34)
[ 307.049819] nouveau [ DEVICE][:04:00.0] Family : NV30
[ 307.050648] nouveau [ VBIOS][:04:00.0] checking PRAMIN for image...
[ 307.050652] nouveau [ VBIOS][:04:00.0] ... signature not found
[ 307.050653] nouveau [ VBIOS][:04:00.0] checking PROM for image...
[ 307.195201] nouveau [ VBIOS][:04:00.0] ... appears to be valid
[ 307.195205] nouveau [ VBIOS][:04:00.0] using image from PROM
[ 307.195209] nouveau [ VBIOS][:04:00.0] BMP version
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On Fri, Aug 30, 2013 at 5:11 PM, Lucas Stach d...@lynxeye.de wrote:
Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs:
On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs skeg...@gmail.com wrote:
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com
wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin
imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de
wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de
wrote:
MSIs were only problematic on some old, broken chipsets. But
now that we
already see systems where PCI legacy interrupts are somewhat
flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17
+
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068,
0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on
the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only
cases
where this should fail is plain PCI/AGP devices. I don't really
have a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so
maybe he
could test this patch and see how it goes?
Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC),
Cases like the nv34 here (i think there's some nv4x that aren't
native
pcie too) are what I'm wondering about primarily.
And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
with AutoAddGPU disabled the NV18 and NV42 seem fine. However
merely
starting X (not xinit, not startx, not [gkx]dm) on the NV34 and
^C'ing
it (with no clients connecting to said X), causes a failed to idle
channel message in dmesg, which apparently never rectifies itself,
so
X is hung forever. FTR, there were no displays connected either, but
I
tried the exact same procedure without the MSI patch and it worked
fine. Here is the init sequence with the MSI patch:
I don't suppose bashing 0x1868 instead of 0x88068 works here? If not,
Should that work on the NV42 as well?
I believe so. NV4x has both the 0x18xx and 0x88xxx apertures I believe.
next thing would be to mmiotrace the binary driver and see if you can
make it enable+use MSI on it. I doubt the current legacy driver does
it by default, but there was some magic to enable it that you can
probably find if you google around.
I've yet to set up the legacy driver... I bet it doesn't compile on
3.11, so I'll have to patch it to nuke procfs/i2c...
[ 307.049812] nouveau [ DEVICE][:04:00.0] BOOT0 : 0x034a00b1
[ 307.049815] nouveau [ DEVICE][:04:00.0] Chipset: NV34 (NV34)
[ 307.049819] nouveau [ DEVICE][:04:00.0] Family : NV30
[ 307.050648] nouveau [ VBIOS][:04:00.0] checking PRAMIN for
image...
[ 307.050652] nouveau [ VBIOS][:04:00.0] ... signature not
found
[ 307.050653] nouveau [ VBIOS][:04:00.0] checking PROM for
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs:
On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs skeg...@gmail.com wrote:
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de
wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de
wrote:
MSIs were only problematic on some old, broken chipsets. But
now that we
already see systems where PCI legacy interrupts are somewhat
flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17
+
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068,
0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only
cases
where this should fail is plain PCI/AGP devices. I don't really
have a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so maybe
he
could test this patch and see how it goes?
Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC),
Cases like the nv34 here (i think there's some nv4x that aren't
native
pcie too) are what I'm wondering about primarily.
And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
with AutoAddGPU disabled the NV18 and NV42 seem fine. However merely
starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
it (with no clients connecting to said X), causes a failed to idle
channel message in dmesg, which apparently never rectifies itself, so
X is hung forever. FTR, there were no displays connected either, but I
tried the exact same procedure without the MSI patch and it worked
fine. Here is the init sequence with the MSI patch:
I don't suppose bashing 0x1868 instead of 0x88068 works here? If not,
Should that work on the NV42 as well?
I believe so. NV4x has both the 0x18xx and 0x88xxx apertures I believe.
next thing would be to mmiotrace the binary driver and see if you can
make it enable+use MSI on it. I doubt the current legacy driver does
it by default, but there was some magic to enable it that you can
probably find if you google around.
I've yet to set up the legacy driver... I bet it doesn't compile on
3.11, so I'll have to patch it to nuke procfs/i2c...
[ 307.049812] nouveau [ DEVICE][:04:00.0] BOOT0 : 0x034a00b1
[ 307.049815] nouveau [ DEVICE][:04:00.0] Chipset: NV34 (NV34)
[ 307.049819] nouveau [ DEVICE][:04:00.0] Family : NV30
[ 307.050648] nouveau [ VBIOS][:04:00.0] checking PRAMIN for
image...
[ 307.050652] nouveau [ VBIOS][:04:00.0] ... signature not
found
[ 307.050653] nouveau [ VBIOS][:04:00.0] checking PROM for
image...
[ 307.195201] nouveau [ VBIOS][:04:00.0] ... appears to be
valid
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?
Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC),
Cases like the nv34 here (i think there's some nv4x that aren't native
pcie too) are what I'm wondering about primarily.
And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
with AutoAddGPU disabled the NV18 and NV42 seem fine. However merely
starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
it (with no clients connecting to said X), causes a failed to idle
channel message in dmesg, which apparently never rectifies itself, so
X is hung forever. FTR, there were no displays connected either, but I
tried the exact same procedure without the MSI patch and it worked
fine. Here is the init sequence with the MSI patch:
I don't suppose bashing 0x1868 instead of 0x88068 works here? If not,
next thing would be to mmiotrace the binary driver and see if you can
make it enable+use MSI on it. I doubt the current legacy driver does
it by default, but there was some magic to enable it that you can
probably find if you google around.
[ 307.049812] nouveau [ DEVICE][:04:00.0] BOOT0 : 0x034a00b1
[ 307.049815] nouveau [ DEVICE][:04:00.0] Chipset: NV34 (NV34)
[ 307.049819] nouveau [ DEVICE][:04:00.0] Family : NV30
[ 307.050648] nouveau [ VBIOS][:04:00.0] checking PRAMIN for image...
[ 307.050652] nouveau [ VBIOS][:04:00.0] ... signature not found
[ 307.050653] nouveau [ VBIOS][:04:00.0] checking PROM for image...
[ 307.195201] nouveau [ VBIOS][:04:00.0] ... appears to be valid
[ 307.195205] nouveau [ VBIOS][:04:00.0] using image from PROM
[ 307.195209] nouveau [ VBIOS][:04:00.0] BMP version 5.29
[ 307.195429] nouveau [ VBIOS][:04:00.0] version 04.34.20.79.00
[ 307.195971] nouveau [ DEVINIT][:04:00.0] adaptor not initialised
[ 307.195979] nouveau [ VBIOS][:04:00.0] running init tables
[ 307.209253] nouveau :04:00.0: irq 47 for MSI/MSI-X
[ 307.209266] nouveau [ PMC][:04:00.0] MSI interrupts enabled
[ 307.209281] nouveau W[ PTIMER][:04:00.0] unknown input clock freq
[ 307.209288] nouveau [ PFB][:04:00.0] RAM type: DDR1
[ 307.209290] nouveau [ PFB][:04:00.0] RAM size: 64 MiB
[ 307.209292] nouveau [ PFB][:04:00.0]ZCOMP: 0 tags
[ 307.215653] nouveau [ DRM] VRAM: 63 MiB
[ 307.215656] nouveau [ DRM] GART: 128 MiB
[ 307.215659] nouveau [ DRM] BMP
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now that
we
already see systems where PCI legacy interrupts are somewhat flaky,
it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17
+
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?
Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC),
Cases like the nv34 here (i think there's some nv4x that aren't native
pcie too) are what I'm wondering about primarily.
And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
with AutoAddGPU disabled the NV18 and NV42 seem fine. However merely
starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
it (with no clients connecting to said X), causes a failed to idle
channel message in dmesg, which apparently never rectifies itself, so
X is hung forever. FTR, there were no displays connected either, but I
tried the exact same procedure without the MSI patch and it worked
fine. Here is the init sequence with the MSI patch:
I don't suppose bashing 0x1868 instead of 0x88068 works here? If not,
Should that work on the NV42 as well?
next thing would be to mmiotrace the binary driver and see if you can
make it enable+use MSI on it. I doubt the current legacy driver does
it by default, but there was some magic to enable it that you can
probably find if you google around.
I've yet to set up the legacy driver... I bet it doesn't compile on
3.11, so I'll have to patch it to nuke procfs/i2c...
[ 307.049812] nouveau [ DEVICE][:04:00.0] BOOT0 : 0x034a00b1
[ 307.049815] nouveau [ DEVICE][:04:00.0] Chipset: NV34 (NV34)
[ 307.049819] nouveau [ DEVICE][:04:00.0] Family : NV30
[ 307.050648] nouveau [ VBIOS][:04:00.0] checking PRAMIN for image...
[ 307.050652] nouveau [ VBIOS][:04:00.0] ... signature not found
[ 307.050653] nouveau [ VBIOS][:04:00.0] checking PROM for image...
[ 307.195201] nouveau [ VBIOS][:04:00.0] ... appears to be valid
[ 307.195205] nouveau [ VBIOS][:04:00.0] using image from PROM
[ 307.195209] nouveau [ VBIOS][:04:00.0] BMP version 5.29
[ 307.195429] nouveau [ VBIOS][:04:00.0] version 04.34.20.79.00
[ 307.195971] nouveau [ DEVINIT][:04:00.0] adaptor not initialised
[ 307.195979] nouveau [ VBIOS][:04:00.0] running init tables
[ 307.209253] nouveau :04:00.0: irq 47 for MSI/MSI-X
[ 307.209266] nouveau [ PMC][:04:00.0] MSI interrupts enabled
[ 307.209281] nouveau W[ PTIMER][:04:00.0] unknown input clock freq
[ 307.209288] nouveau [ PFB][:04:00.0] RAM type: DDR1
[ 307.209290] nouveau
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now
that we
already see systems where PCI legacy interrupts are somewhat flaky,
it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17
+
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?
Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC),
Cases like the nv34 here (i think there's some nv4x that aren't native
pcie too) are what I'm wondering about primarily.
And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
with AutoAddGPU disabled the NV18 and NV42 seem fine. However merely
starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
it (with no clients connecting to said X), causes a failed to idle
channel message in dmesg, which apparently never rectifies itself, so
X is hung forever. FTR, there were no displays connected either, but I
tried the exact same procedure without the MSI patch and it worked
fine. Here is the init sequence with the MSI patch:
I don't suppose bashing 0x1868 instead of 0x88068 works here? If not,
Should that work on the NV42 as well?
I believe so. NV4x has both the 0x18xx and 0x88xxx apertures I believe.
next thing would be to mmiotrace the binary driver and see if you can
make it enable+use MSI on it. I doubt the current legacy driver does
it by default, but there was some magic to enable it that you can
probably find if you google around.
I've yet to set up the legacy driver... I bet it doesn't compile on
3.11, so I'll have to patch it to nuke procfs/i2c...
[ 307.049812] nouveau [ DEVICE][:04:00.0] BOOT0 : 0x034a00b1
[ 307.049815] nouveau [ DEVICE][:04:00.0] Chipset: NV34 (NV34)
[ 307.049819] nouveau [ DEVICE][:04:00.0] Family : NV30
[ 307.050648] nouveau [ VBIOS][:04:00.0] checking PRAMIN for
image...
[ 307.050652] nouveau [ VBIOS][:04:00.0] ... signature not found
[ 307.050653] nouveau [ VBIOS][:04:00.0] checking PROM for image...
[ 307.195201] nouveau [ VBIOS][:04:00.0] ... appears to be valid
[ 307.195205] nouveau [ VBIOS][:04:00.0] using image from PROM
[ 307.195209] nouveau [ VBIOS][:04:00.0] BMP version 5.29
[ 307.195429] nouveau [ VBIOS][:04:00.0] version 04.34.20.79.00
[ 307.195971] nouveau [ DEVINIT][:04:00.0] adaptor not initialised
[ 307.195979] nouveau [ VBIOS][:04:00.0] running init tables
[ 307.209253] nouveau :04:00.0: irq 47 for MSI/MSI-X
[
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now
that we
already see systems where PCI legacy interrupts are somewhat flaky,
it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17
+
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?
Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC),
Cases like the nv34 here (i think there's some nv4x that aren't native
pcie too) are what I'm wondering about primarily.
And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
with AutoAddGPU disabled the NV18 and NV42 seem fine. However merely
starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
it (with no clients connecting to said X), causes a failed to idle
channel message in dmesg, which apparently never rectifies itself, so
X is hung forever. FTR, there were no displays connected either, but I
tried the exact same procedure without the MSI patch and it worked
fine. Here is the init sequence with the MSI patch:
I don't suppose bashing 0x1868 instead of 0x88068 works here? If not,
Should that work on the NV42 as well?
I believe so. NV4x has both the 0x18xx and 0x88xxx apertures I believe.
next thing would be to mmiotrace the binary driver and see if you can
make it enable+use MSI on it. I doubt the current legacy driver does
it by default, but there was some magic to enable it that you can
probably find if you google around.
I've yet to set up the legacy driver... I bet it doesn't compile on
3.11, so I'll have to patch it to nuke procfs/i2c...
[ 307.049812] nouveau [ DEVICE][:04:00.0] BOOT0 : 0x034a00b1
[ 307.049815] nouveau [ DEVICE][:04:00.0] Chipset: NV34 (NV34)
[ 307.049819] nouveau [ DEVICE][:04:00.0] Family : NV30
[ 307.050648] nouveau [ VBIOS][:04:00.0] checking PRAMIN for
image...
[ 307.050652] nouveau [ VBIOS][:04:00.0] ... signature not found
[ 307.050653] nouveau [ VBIOS][:04:00.0] checking PROM for
image...
[ 307.195201] nouveau [ VBIOS][:04:00.0] ... appears to be valid
[ 307.195205] nouveau [ VBIOS][:04:00.0] using image from PROM
[ 307.195209] nouveau [ VBIOS][:04:00.0] BMP version 5.29
[ 307.195429] nouveau [ VBIOS][:04:00.0] version 04.34.20.79.00
[ 307.195971] nouveau [ DEVINIT][:04:00.0] adaptor not initialised
[ 307.195979] nouveau [ VBIOS][:04:00.0] running init
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On Fri, Aug 30, 2013 at 11:58 AM, Ben Skeggs skeg...@gmail.com wrote:
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de
wrote:
MSIs were only problematic on some old, broken chipsets. But now
that we
already see systems where PCI legacy interrupts are somewhat
flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17
+
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only
cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?
Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC),
Cases like the nv34 here (i think there's some nv4x that aren't native
pcie too) are what I'm wondering about primarily.
And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
with AutoAddGPU disabled the NV18 and NV42 seem fine. However merely
starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
it (with no clients connecting to said X), causes a failed to idle
channel message in dmesg, which apparently never rectifies itself, so
X is hung forever. FTR, there were no displays connected either, but I
tried the exact same procedure without the MSI patch and it worked
fine. Here is the init sequence with the MSI patch:
I don't suppose bashing 0x1868 instead of 0x88068 works here? If not,
Should that work on the NV42 as well?
I believe so. NV4x has both the 0x18xx and 0x88xxx apertures I believe.
next thing would be to mmiotrace the binary driver and see if you can
make it enable+use MSI on it. I doubt the current legacy driver does
it by default, but there was some magic to enable it that you can
probably find if you google around.
I've yet to set up the legacy driver... I bet it doesn't compile on
3.11, so I'll have to patch it to nuke procfs/i2c...
[ 307.049812] nouveau [ DEVICE][:04:00.0] BOOT0 : 0x034a00b1
[ 307.049815] nouveau [ DEVICE][:04:00.0] Chipset: NV34 (NV34)
[ 307.049819] nouveau [ DEVICE][:04:00.0] Family : NV30
[ 307.050648] nouveau [ VBIOS][:04:00.0] checking PRAMIN for
image...
[ 307.050652] nouveau [ VBIOS][:04:00.0] ... signature not found
[ 307.050653] nouveau [ VBIOS][:04:00.0] checking PROM for
image...
[ 307.195201] nouveau [ VBIOS][:04:00.0] ... appears to be valid
[ 307.195205] nouveau [ VBIOS][:04:00.0] using image from PROM
[ 307.195209] nouveau [ VBIOS][:04:00.0] BMP version 5.29
[ 307.195429] nouveau [ VBIOS][:04:00.0] version 04.34.20.79.00
[ 307.195971] nouveau [ DEVINIT][:04:00.0] adaptor not
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs skeg...@gmail.com wrote:
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de
wrote:
MSIs were only problematic on some old, broken chipsets. But now
that we
already see systems where PCI legacy interrupts are somewhat
flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17
+
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only
cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?
Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC),
Cases like the nv34 here (i think there's some nv4x that aren't native
pcie too) are what I'm wondering about primarily.
And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
with AutoAddGPU disabled the NV18 and NV42 seem fine. However merely
starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
it (with no clients connecting to said X), causes a failed to idle
channel message in dmesg, which apparently never rectifies itself, so
X is hung forever. FTR, there were no displays connected either, but I
tried the exact same procedure without the MSI patch and it worked
fine. Here is the init sequence with the MSI patch:
I don't suppose bashing 0x1868 instead of 0x88068 works here? If not,
Should that work on the NV42 as well?
I believe so. NV4x has both the 0x18xx and 0x88xxx apertures I believe.
next thing would be to mmiotrace the binary driver and see if you can
make it enable+use MSI on it. I doubt the current legacy driver does
it by default, but there was some magic to enable it that you can
probably find if you google around.
I've yet to set up the legacy driver... I bet it doesn't compile on
3.11, so I'll have to patch it to nuke procfs/i2c...
[ 307.049812] nouveau [ DEVICE][:04:00.0] BOOT0 : 0x034a00b1
[ 307.049815] nouveau [ DEVICE][:04:00.0] Chipset: NV34 (NV34)
[ 307.049819] nouveau [ DEVICE][:04:00.0] Family : NV30
[ 307.050648] nouveau [ VBIOS][:04:00.0] checking PRAMIN for
image...
[ 307.050652] nouveau [ VBIOS][:04:00.0] ... signature not found
[ 307.050653] nouveau [ VBIOS][:04:00.0] checking PROM for
image...
[ 307.195201] nouveau [ VBIOS][:04:00.0] ... appears to be valid
[ 307.195205] nouveau [ VBIOS][:04:00.0] using image from PROM
[ 307.195209] nouveau [ VBIOS][:04:00.0] BMP version 5.29
[ 307.195429] nouveau [ VBIOS][:04:00.0] version 04.34.20.79.00
[ 307.195971] nouveau [ DEVINIT][:04:00.0] adaptor not
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs skeg...@gmail.com wrote:
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de
wrote:
MSIs were only problematic on some old, broken chipsets. But now
that we
already see systems where PCI legacy interrupts are somewhat
flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17
+
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only
cases
where this should fail is plain PCI/AGP devices. I don't really have
a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?
Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC),
Cases like the nv34 here (i think there's some nv4x that aren't native
pcie too) are what I'm wondering about primarily.
And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
with AutoAddGPU disabled the NV18 and NV42 seem fine. However merely
starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
it (with no clients connecting to said X), causes a failed to idle
channel message in dmesg, which apparently never rectifies itself, so
X is hung forever. FTR, there were no displays connected either, but I
tried the exact same procedure without the MSI patch and it worked
fine. Here is the init sequence with the MSI patch:
I don't suppose bashing 0x1868 instead of 0x88068 works here? If not,
Should that work on the NV42 as well?
I believe so. NV4x has both the 0x18xx and 0x88xxx apertures I believe.
next thing would be to mmiotrace the binary driver and see if you can
make it enable+use MSI on it. I doubt the current legacy driver does
it by default, but there was some magic to enable it that you can
probably find if you google around.
I've yet to set up the legacy driver... I bet it doesn't compile on
3.11, so I'll have to patch it to nuke procfs/i2c...
[ 307.049812] nouveau [ DEVICE][:04:00.0] BOOT0 : 0x034a00b1
[ 307.049815] nouveau [ DEVICE][:04:00.0] Chipset: NV34 (NV34)
[ 307.049819] nouveau [ DEVICE][:04:00.0] Family : NV30
[ 307.050648] nouveau [ VBIOS][:04:00.0] checking PRAMIN for
image...
[ 307.050652] nouveau [ VBIOS][:04:00.0] ... signature not found
[ 307.050653] nouveau [ VBIOS][:04:00.0] checking PROM for
image...
[ 307.195201] nouveau [ VBIOS][:04:00.0] ... appears to be valid
[ 307.195205] nouveau [ VBIOS][:04:00.0] using image from PROM
[ 307.195209] nouveau [ VBIOS][:04:00.0] BMP version 5.29
[ 307.195429] nouveau [ VBIOS][:04:00.0] version
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
+
if (intr) {
nv_error(pmc, unknown intr 0x%08x\n, stat);
}
@@ -75,6 +79,8 @@ _nouveau_mc_dtor(struct nouveau_object *object)
struct nouveau_device *device = nv_device(object);
struct nouveau_mc *pmc = (void *)object;
free_irq(device-pdev-irq, pmc);
+ if (pmc-use_msi)
+ pci_disable_msi(device-pdev);
nouveau_subdev_destroy(pmc-base);
}
@@ -96,6 +102,17 @@ nouveau_mc_create_(struct nouveau_object *parent, struct
nouveau_object *engine,
pmc-intr_map = intr_map;
+ pmc-use_msi = nouveau_boolopt(device-cfgopt, NvMSI, true);
+ if (pmc-use_msi) {
+ ret = pci_enable_msi(device-pdev);
+ if (ret) {
+ pmc-use_msi = false;
+ } else {
+ nv_wr08(device, 0x00088068, 0xff);
+ nv_info(pmc, MSI interrupts enabled\n);
+ }
+ }
+
ret = request_irq(device-pdev-irq, nouveau_mc_intr,
IRQF_SHARED, nouveau, pmc);
if (ret 0)
--
1.8.3.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?
+
if (intr) {
nv_error(pmc, unknown intr 0x%08x\n, stat);
}
@@ -75,6 +79,8 @@ _nouveau_mc_dtor(struct nouveau_object *object)
struct nouveau_device *device = nv_device(object);
struct nouveau_mc *pmc = (void *)object;
free_irq(device-pdev-irq, pmc);
+ if (pmc-use_msi)
+ pci_disable_msi(device-pdev);
nouveau_subdev_destroy(pmc-base);
}
@@ -96,6 +102,17 @@ nouveau_mc_create_(struct nouveau_object *parent,
struct nouveau_object *engine,
pmc-intr_map = intr_map;
+ pmc-use_msi = nouveau_boolopt(device-cfgopt, NvMSI, true);
+ if (pmc-use_msi) {
+ ret = pci_enable_msi(device-pdev);
+ if (ret) {
+ pmc-use_msi = false;
+ } else {
+ nv_wr08(device, 0x00088068, 0xff);
+ nv_info(pmc, MSI interrupts enabled\n);
+ }
+ }
+
ret = request_irq(device-pdev-irq, nouveau_mc_intr,
IRQF_SHARED, nouveau, pmc);
if (ret 0)
--
1.8.3.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?
Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC), nv42
PCIe, nv44 PCIe, nv96 PCIe.
Can I just apply this patch, or do I need to do the whole series? What
constitutes a success?
-ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On Wed, Aug 28, 2013 at 09:28:57AM +0200, Lucas Stach wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.
That is not true. You can boot a machine with pci=nomsi that has PCIe and
it will work. Legacy interrupts still work on PCIe
But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?
+
if (intr) {
nv_error(pmc, unknown intr 0x%08x\n, stat);
}
@@ -75,6 +79,8 @@ _nouveau_mc_dtor(struct nouveau_object *object)
struct nouveau_device *device = nv_device(object);
struct nouveau_mc *pmc = (void *)object;
free_irq(device-pdev-irq, pmc);
+ if (pmc-use_msi)
+ pci_disable_msi(device-pdev);
nouveau_subdev_destroy(pmc-base);
}
@@ -96,6 +102,17 @@ nouveau_mc_create_(struct nouveau_object *parent,
struct nouveau_object *engine,
pmc-intr_map = intr_map;
+ pmc-use_msi = nouveau_boolopt(device-cfgopt, NvMSI, true);
+ if (pmc-use_msi) {
+ ret = pci_enable_msi(device-pdev);
+ if (ret) {
+ pmc-use_msi = false;
+ } else {
+ nv_wr08(device, 0x00088068, 0xff);
+ nv_info(pmc, MSI interrupts enabled\n);
+ }
+ }
+
ret = request_irq(device-pdev-irq, nouveau_mc_intr,
IRQF_SHARED, nouveau, pmc);
if (ret 0)
--
1.8.3.1
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?
Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC),
Cases like the nv34 here (i think there's some nv4x that aren't native
pcie too) are what I'm wondering about primarily.
nv42
PCIe, nv44 PCIe, nv96 PCIe.
Can I just apply this patch, or do I need to do the whole series? What
constitutes a success?
-ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include subdev/mc.h
+#include core/option.h
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc-use_msi)
+ nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?
Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC),
Cases like the nv34 here (i think there's some nv4x that aren't native
pcie too) are what I'm wondering about primarily.
And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
with AutoAddGPU disabled the NV18 and NV42 seem fine. However merely
starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
it (with no clients connecting to said X), causes a failed to idle
channel message in dmesg, which apparently never rectifies itself, so
X is hung forever. FTR, there were no displays connected either, but I
tried the exact same procedure without the MSI patch and it worked
fine. Here is the init sequence with the MSI patch:
[ 307.049812] nouveau [ DEVICE][:04:00.0] BOOT0 : 0x034a00b1
[ 307.049815] nouveau [ DEVICE][:04:00.0] Chipset: NV34 (NV34)
[ 307.049819] nouveau [ DEVICE][:04:00.0] Family : NV30
[ 307.050648] nouveau [ VBIOS][:04:00.0] checking PRAMIN for image...
[ 307.050652] nouveau [ VBIOS][:04:00.0] ... signature not found
[ 307.050653] nouveau [ VBIOS][:04:00.0] checking PROM for image...
[ 307.195201] nouveau [ VBIOS][:04:00.0] ... appears to be valid
[ 307.195205] nouveau [ VBIOS][:04:00.0] using image from PROM
[ 307.195209] nouveau [ VBIOS][:04:00.0] BMP version 5.29
[ 307.195429] nouveau [ VBIOS][:04:00.0] version 04.34.20.79.00
[ 307.195971] nouveau [ DEVINIT][:04:00.0] adaptor not initialised
[ 307.195979] nouveau [ VBIOS][:04:00.0] running init tables
[ 307.209253] nouveau :04:00.0: irq 47 for MSI/MSI-X
[ 307.209266] nouveau [ PMC][:04:00.0] MSI interrupts enabled
[ 307.209281] nouveau W[ PTIMER][:04:00.0] unknown input clock freq
[ 307.209288] nouveau [ PFB][:04:00.0] RAM type: DDR1
[ 307.209290] nouveau [ PFB][:04:00.0] RAM size: 64 MiB
[ 307.209292] nouveau [ PFB][:04:00.0]ZCOMP: 0 tags
[ 307.215653] nouveau [ DRM] VRAM: 63 MiB
[ 307.215656] nouveau [ DRM] GART: 128 MiB
[ 307.215659] nouveau [ DRM] BMP version 5.41
[ 307.215662] nouveau [ DRM] DCB version 2.2
[ 307.215666] nouveau [ DRM] DCB outp 00: 01000300 88b8
[ 307.215669] nouveau [ DRM] DCB outp 01: 02010310 88b8
[ 307.215672] nouveau [ DRM] DCB outp 02: 01000302
[ 307.215676] nouveau [ DRM] DCB outp 03: 04010312
[ 307.215686] nouveau [ DRM] Adaptor not initialised, running
VBIOS init tables.
[
