Skip to contentSkip to conversation

hda_intel: Add Lynx Point HD Audio Controller DeviceIDs

PATCH Applied Seth Heasley 3 participants 7 messages Jan 24, 2012 – Feb 8, 2012 Sound

lore
Share & tools
lore
#0 lore raw

PATCH 1/6 hda_intel: Add Lynx Point HD Audio Controller DeviceIDs

This patch adds the HD Audio DeviceIDs for the Intel Lynx Point PCH.

---
 sound/pci/hda/hda_intel.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
sound/pci/hda/hda_intel.c +5 -0
index 0852e20..adb4fa7 100644
@@ -148,6 +148,7 @@ MODULE_SUPPORTED_DEVICE("{{Intel, ICH6},"
 			 "{Intel, PCH},"
 			 "{Intel, CPT},"
 			 "{Intel, PPT},"
+			 "{Intel, LPT},"
 			 "{Intel, PBG},"
 			 "{Intel, SCH},"
 			 "{ATI, SB450},"
@@ -2989,6 +2990,10 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = {
 	{ PCI_DEVICE(0x8086, 0x1e20),
 	  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP |
 	  AZX_DCAPS_BUFSIZE},
+	/* Lynx Point */
+	{ PCI_DEVICE(0x8086, 0x8c20),
+	  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP |
+	  AZX_DCAPS_BUFSIZE},
 	/* SCH */
 	{ PCI_DEVICE(0x8086, 0x811b),
 	  .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_SCH_SNOOP |
Signature · 1 line
1.7.4.4
#1 lore raw
Quoted 1 line · Seth Heasley

This patch adds the HD Audio DeviceIDs for the Intel Lynx Point PCH.

Thanks. As we asked for oak trail: can you confirm you prefer DMA Position buffers for detecting current playback/recording position, over using the LPIB register?

Also; these types of quirks should have a line "Cc: [email protected]" added to their commit messages, that will make it automatically be applied to some of the older kernels in due time.

Quoted 29 lines
---
  sound/pci/hda/hda_intel.c |    5 +++++
  1 files changed, 5 insertions(+), 0 deletions(-)
sound/pci/hda/hda_intel.c +5 -0
index 0852e20..adb4fa7 100644
@@ -148,6 +148,7 @@ MODULE_SUPPORTED_DEVICE("{{Intel, ICH6},"
  			 "{Intel, PCH},"
  			 "{Intel, CPT},"
  			 "{Intel, PPT},"
+			 "{Intel, LPT},"
  			 "{Intel, PBG},"
  			 "{Intel, SCH},"
  			 "{ATI, SB450},"
@@ -2989,6 +2990,10 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = {
  	{ PCI_DEVICE(0x8086, 0x1e20),
  	  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP |
  	  AZX_DCAPS_BUFSIZE},
+	/* Lynx Point */
+	{ PCI_DEVICE(0x8086, 0x8c20),
+	  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP |
+	  AZX_DCAPS_BUFSIZE},
  	/* SCH */
  	{ PCI_DEVICE(0x8086, 0x811b),
  	  .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_SCH_SNOOP |
Signature · 2 lines
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
#2 lore raw

At Tue, 24 Jan 2012 10:45:36 +0100,

Quoted 7 lines · David Henningsson
Quoted 1 line · Seth Heasley

This patch adds the HD Audio DeviceIDs for the Intel Lynx Point PCH.

Thanks. As we asked for oak trail: can you confirm you prefer DMA Position buffers for detecting current playback/recording position, over using the LPIB register?

Yes, thanks for the notice.

I guess this won't need it since it's the successor of PPT. But it's always good to check it for the new hardware, indeed.

Takashi

#3 lore raw
Quoted 11 lines
Quoted 4 lines
Quoted 1 line

This patch adds the HD Audio DeviceIDs for the Intel Lynx Point PCH.

Thanks. As we asked for oak trail: can you confirm you prefer DMA Position buffers for detecting current playback/recording position,

over

Quoted 1 line

using the LPIB register?

Yes, thanks for the notice.

I guess this won't need it since it's the successor of PPT. But it's always good to check it for the new hardware, indeed.

I'm also in favor of not rocking the boat, but I'm curious what changing this would entail, and what would be the advantage or rationale for making the change?

-Seth

#4 lore raw
Quoted 5 lines · Seth
Quoted 5 lines
Quoted 4 lines
Quoted 1 line

This patch adds the HD Audio DeviceIDs for the Intel Lynx Point PCH.

Thanks. As we asked for oak trail: can you confirm you prefer DMA Position buffers for detecting current playback/recording position,

over

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

using the LPIB register?

Yes, thanks for the notice.

I guess this won't need it since it's the successor of PPT. But it's always good to check it for the new hardware, indeed.

I'm also in favor of not rocking the boat, but I'm curious what changing this would entail, and what would be the advantage or rationale for making the change?

Reading the LPIB register, and reading the DMA position buffer, are two different methods of reading the current playback (or recording) position, i e which sample is currently being played back.

The problem is that some chipsets prefer one method over the other, i e, only one of the methods work reliably. And if the other method only breaks occasionally, this can be quite difficult to detect and track down - we will have users complaining about their audio sometimes either sounding distorted, maybe not working at all, or just once in a while glitches. All of these symptoms can have many causes, so deducing that to a broken playback position is time consuming. That's why I think it's worth the extra question, to get it right from the start.

So...thanks in advance for looking it up for us? :-)

Signature · 2 lines
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
#5 lore raw
Quoted 17 lines
Quoted 1 line

I'm also in favor of not rocking the boat, but I'm curious what

changing this would entail, and what would be the advantage or rationale for making the change?

Reading the LPIB register, and reading the DMA position buffer, are two different methods of reading the current playback (or recording) position, i e which sample is currently being played back.

The problem is that some chipsets prefer one method over the other, i e, only one of the methods work reliably. And if the other method only breaks occasionally, this can be quite difficult to detect and track down - we will have users complaining about their audio sometimes either sounding distorted, maybe not working at all, or just once in a while glitches. All of these symptoms can have many causes, so deducing that to a broken playback position is time consuming. That's why I think it's worth the extra question, to get it right from the start.

Quoted 1 line

So...thanks in advance for looking it up for us? :-)

I'm inquiring about it, but I can say that it seems to work just fine using the DMA position buffer.

-Seth

#6 lore raw

At Wed, 8 Feb 2012 00:35:33 +0000,

Quoted 18 lines · Seth
Quoted 18 lines
Quoted 2 lines

I'm also in favor of not rocking the boat, but I'm curious what

changing this would entail, and what would be the advantage or rationale for making the change?

Reading the LPIB register, and reading the DMA position buffer, are two different methods of reading the current playback (or recording) position, i e which sample is currently being played back.

The problem is that some chipsets prefer one method over the other, i e, only one of the methods work reliably. And if the other method only breaks occasionally, this can be quite difficult to detect and track down - we will have users complaining about their audio sometimes either sounding distorted, maybe not working at all, or just once in a while glitches. All of these symptoms can have many causes, so deducing that to a broken playback position is time consuming. That's why I think it's worth the extra question, to get it right from the start.

Quoted 3 lines
Quoted 1 line

So...thanks in advance for looking it up for us? :-)

I'm inquiring about it, but I can say that it seems to work just fine using the DMA position buffer.

OK, I merged the patch now as is.
Please let me know if you find a problem.

thanks,

Takashi