Re: Intel azalia(4) and MSI

2012-11-14 Thread Brad Smith 
On Fri, Sep 28, 2012 at 12:07:31AM -0400, Brad Smith wrote:
 On Fri, Sep 28, 2012 at 04:06:32AM +0200, Mark Kettenis wrote:
   Date: Mon, 24 Sep 2012 03:49:41 -0400
   From: Brad Smith b...@comstyle.com
   
   I've always wondered why this workaround was not removed once MSI
   support was added. This was added before we had MSI support to
   workaround some Intel azalia(4) being setup by the BIOS as far
   as I know to use MSI and thus interrupts on system that were
   affected by this did not work at all for azalia(4).
  
  Because there still are conditions under which we would not be able to
  use MSI.
 
 I had 6 people reply off list indicating their Intel azalia controllers
 didn't seem to have any regressions with the previous diff applied.
 
 Can you expand upon this and explain what you mean. What are these
 conditions? It would be nice to mention what those conditions are
 within the comment.
 
  Perhaps we should change the generic PCI code to explicitly disable
  MSIs if they are turned on.  But until we do that, this workaround
  needs to stay in place.
 
 Since MSI is being disabled for the Intel azalia controller and the
 datasheet does confirm that is what this code is doing shouldn't
 we be telling the PCI layer MSI is disabled too like so? It doesn't
 make sense to have MSI disabled for the controller and then the
 PCI layer still thinking MSI should be used.

ping.

 Index: azalia.c
 ===
 RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
 retrieving revision 1.201
 diff -u -p -r1.201 azalia.c
 --- azalia.c  12 Aug 2012 19:32:22 -  1.201
 +++ azalia.c  28 Sep 2012 02:17:31 -
 @@ -515,6 +515,7 @@ azalia_pci_attach(struct device *parent,
  
   /* disable MSI, use INTx instead */
   if (PCI_VENDOR(sc-pciid) == PCI_VENDOR_INTEL) {
 + pa-pa_flags = ~PCI_FLAGS_MSI_ENABLED;
   reg = azalia_pci_read(sc-pc, sc-tag, ICH_PCI_MMC);
   reg = ~(ICH_PCI_MMC_ME);
   azalia_pci_write(sc-pc, sc-tag, ICH_PCI_MMC, reg);

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Intel azalia(4) and MSI

2012-11-14 Thread Mark Kettenis 
 Date: Wed, 14 Nov 2012 22:30:48 -0500
 From: Brad Smith b...@comstyle.com
 
 On Fri, Sep 28, 2012 at 12:07:31AM -0400, Brad Smith wrote:
  On Fri, Sep 28, 2012 at 04:06:32AM +0200, Mark Kettenis wrote:
Date: Mon, 24 Sep 2012 03:49:41 -0400
From: Brad Smith b...@comstyle.com

I've always wondered why this workaround was not removed once MSI
support was added. This was added before we had MSI support to
workaround some Intel azalia(4) being setup by the BIOS as far
as I know to use MSI and thus interrupts on system that were
affected by this did not work at all for azalia(4).
   
   Because there still are conditions under which we would not be able to
   use MSI.
  
  I had 6 people reply off list indicating their Intel azalia controllers
  didn't seem to have any regressions with the previous diff applied.
  
  Can you expand upon this and explain what you mean. What are these
  conditions? It would be nice to mention what those conditions are
  within the comment.
  
   Perhaps we should change the generic PCI code to explicitly disable
   MSIs if they are turned on.  But until we do that, this workaround
   needs to stay in place.
  
  Since MSI is being disabled for the Intel azalia controller and the
  datasheet does confirm that is what this code is doing shouldn't
  we be telling the PCI layer MSI is disabled too like so? It doesn't
  make sense to have MSI disabled for the controller and then the
  PCI layer still thinking MSI should be used.

You clearly don't understand how the code works.  The flag indicates
whether MSIs are supported by the host bridge (and the device).  Not
whether MSIs are actually enabled on the device.  The PCI layer will
turn MSIs back on if it decides to use them.  We just want to make
sure MSIs aren't accidentally enabled when we decide not to use them.
Something that apparently happened on some machines with Intel HD
Audio.

Re: Intel azalia(4) and MSI

2012-09-27 Thread Mark Kettenis 
 Date: Mon, 24 Sep 2012 03:49:41 -0400
 From: Brad Smith b...@comstyle.com
 
 I've always wondered why this workaround was not removed once MSI
 support was added. This was added before we had MSI support to
 workaround some Intel azalia(4) being setup by the BIOS as far
 as I know to use MSI and thus interrupts on system that were
 affected by this did not work at all for azalia(4).

Because there still are conditions under which we would not be able to
use MSI.

Perhaps we should change the generic PCI code to explicitly disable
MSIs if they are turned on.  But until we do that, this workaround
needs to stay in place.

 Index: azalia.c
 ===
 RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
 retrieving revision 1.200
 diff -u -p -r1.200 azalia.c
 --- azalia.c  10 May 2012 22:46:48 -  1.200
 +++ azalia.c  2 Aug 2012 10:41:02 -
 @@ -488,7 +488,6 @@ azalia_pci_attach(struct device *parent,
   azalia_t *sc;
   struct pci_attach_args *pa;
   pcireg_t v;
 - uint8_t reg;
   pci_intr_handle_t ih;
   const char *interrupt_str;
  
 @@ -511,13 +510,6 @@ azalia_pci_attach(struct device *parent,
   sc-subid = pci_conf_read(pa-pa_pc, pa-pa_tag, PCI_SUBSYS_ID_REG);
  
   azalia_configure_pci(sc);
 -
 - /* disable MSI, use INTx instead */
 - if (PCI_VENDOR(sc-pciid) == PCI_VENDOR_INTEL) {
 - reg = azalia_pci_read(sc-pc, sc-tag, ICH_PCI_MMC);
 - reg = ~(ICH_PCI_MMC_ME);
 - azalia_pci_write(sc-pc, sc-tag, ICH_PCI_MMC, reg);
 - }
  
   /* interrupt */
   if (pci_intr_map_msi(pa, ih)  pci_intr_map(pa, ih)) {
 
 -- 
 This message has been scanned for viruses and
 dangerous content by MailScanner, and is
 believed to be clean.

Re: Intel azalia(4) and MSI

2012-09-27 Thread Brad Smith 
On Fri, Sep 28, 2012 at 04:06:32AM +0200, Mark Kettenis wrote:
  Date: Mon, 24 Sep 2012 03:49:41 -0400
  From: Brad Smith b...@comstyle.com
  
  I've always wondered why this workaround was not removed once MSI
  support was added. This was added before we had MSI support to
  workaround some Intel azalia(4) being setup by the BIOS as far
  as I know to use MSI and thus interrupts on system that were
  affected by this did not work at all for azalia(4).
 
 Because there still are conditions under which we would not be able to
 use MSI.

I had 6 people reply off list indicating their Intel azalia controllers
didn't seem to have any regressions with the previous diff applied.

Can you expand upon this and explain what you mean. What are these
conditions? It would be nice to mention what those conditions are
within the comment.

 Perhaps we should change the generic PCI code to explicitly disable
 MSIs if they are turned on.  But until we do that, this workaround
 needs to stay in place.

Since MSI is being disabled for the Intel azalia controller and the
datasheet does confirm that is what this code is doing shouldn't
we be telling the PCI layer MSI is disabled too like so? It doesn't
make sense to have MSI disabled for the controller and then the
PCI layer still thinking MSI should be used.


Index: azalia.c
===
RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.201
diff -u -p -r1.201 azalia.c
--- azalia.c12 Aug 2012 19:32:22 -  1.201
+++ azalia.c28 Sep 2012 02:17:31 -
@@ -515,6 +515,7 @@ azalia_pci_attach(struct device *parent,
 
/* disable MSI, use INTx instead */
if (PCI_VENDOR(sc-pciid) == PCI_VENDOR_INTEL) {
+   pa-pa_flags = ~PCI_FLAGS_MSI_ENABLED;
reg = azalia_pci_read(sc-pc, sc-tag, ICH_PCI_MMC);
reg = ~(ICH_PCI_MMC_ME);
azalia_pci_write(sc-pc, sc-tag, ICH_PCI_MMC, reg);

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Intel azalia(4) and MSI

2012-09-26 Thread Stuart Henderson 
On 2012/09/24 03:49, Brad Smith wrote:
 I've always wondered why this workaround was not removed once MSI
 support was added. This was added before we had MSI support to
 workaround some Intel azalia(4) being setup by the BIOS as far
 as I know to use MSI and thus interrupts on system that were
 affected by this did not work at all for azalia(4).
 
 If you have Intel azalia(4) could you please test this.

Seems alright on X220.

OpenBSD 5.2-current (GENERIC.MP) #0: Tue Sep 25 12:57:38 BST 2012
st...@bamboo.spacehopper.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8466853888 (8074MB)
avail mem = 8219013120 (7838MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (66 entries)
bios0: vendor LENOVO version 8DET63WW (1.33 ) date 07/19/2012
bios0: LENOVO 4287CTO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT 
SSDT UEFI UEFI UEFI
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) 
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2791.35 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2790.94 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2790.94 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2790.94 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu3: 256KB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus 5 (EXP4)
acpiprt5 at acpi0: bus 13 (EXP5)
acpiprt6 at acpi0: bus 14 (EXP7)
acpicpu0 at acpi0: C3, C1, PSS
acpicpu1 at acpi0: C3, C1, PSS
acpicpu2 at acpi0: C3, C1, PSS
acpicpu3 at acpi0: C3, C1, PSS
acpipwrres0 at acpi0: PUBS
acpitz0 at acpi0: critical temperature is 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 42T4861 serial 12519 type LION oem SANYO
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
cpu0: Enhanced SpeedStep 2791 MHz: speeds: 2801, 2800, 2600, 2400, 2200, 2000, 
1800, 1600, 1400, 1200, 1000, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel Core 2G Host rev 0x09
vga1 at pci0 dev 2 function 0 Intel HD Graphics 3000 rev 0x09
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0 at vga1: apic 2 int 16
drm0 at inteldrm0
Intel 6 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured
puc0 at pci0 dev 22 function 3 Intel 6 Series KT rev 0x04: ports: 1 com
com2 at puc0 port 0 apic 2 int 19: ns16550a, 16 byte fifo
com2: probed fifo depth: 0 bytes
em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address 
f0:de:f1:f9:a7:52
ehci0 at pci0 dev 26 function 0 Intel 6 Series USB rev 0x04: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 Intel 6 Series HD Audio rev 0x04: msi
azalia0: codecs: Conexant/0x506e, Intel/0x2805, using Conexant/0x506e
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 Intel 6 Series PCIE rev 0xb4: msi
pci1 at ppb0 bus 2
ppb1 at pci0 dev 28 function 1 Intel 6 Series PCIE rev 0xb4: msi
pci2 at ppb1 bus 3
iwn0 at pci2 dev 0 function 0 Intel Centrino

Intel azalia(4) and MSI

2012-09-24 Thread Brad Smith 
I've always wondered why this workaround was not removed once MSI
support was added. This was added before we had MSI support to
workaround some Intel azalia(4) being setup by the BIOS as far
as I know to use MSI and thus interrupts on system that were
affected by this did not work at all for azalia(4).

If you have Intel azalia(4) could you please test this.


Index: azalia.c
===
RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.200
diff -u -p -r1.200 azalia.c
--- azalia.c10 May 2012 22:46:48 -  1.200
+++ azalia.c2 Aug 2012 10:41:02 -
@@ -488,7 +488,6 @@ azalia_pci_attach(struct device *parent,
azalia_t *sc;
struct pci_attach_args *pa;
pcireg_t v;
-   uint8_t reg;
pci_intr_handle_t ih;
const char *interrupt_str;
 
@@ -511,13 +510,6 @@ azalia_pci_attach(struct device *parent,
sc-subid = pci_conf_read(pa-pa_pc, pa-pa_tag, PCI_SUBSYS_ID_REG);
 
azalia_configure_pci(sc);
-
-   /* disable MSI, use INTx instead */
-   if (PCI_VENDOR(sc-pciid) == PCI_VENDOR_INTEL) {
-   reg = azalia_pci_read(sc-pc, sc-tag, ICH_PCI_MMC);
-   reg = ~(ICH_PCI_MMC_ME);
-   azalia_pci_write(sc-pc, sc-tag, ICH_PCI_MMC, reg);
-   }
 
/* interrupt */
if (pci_intr_map_msi(pa, ih)  pci_intr_map(pa, ih)) {

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.