Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1276875 > unrolled thread

[PATCH 3.2 22/52] ALSA: hda - Disable 64bit address for Creative HDA controllers

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 3.2 22/52] ALSA: hda - Disable 64bit address for Creative  HDA controllers Ben Hutchings <ben@decadent.org.uk> - 2015-11-24 23:50 +0100
    Re: [PATCH 3.2 22/52] ALSA: hda - Disable 64bit address for Creative  HDA controllers Luis Henriques <luis.henriques@canonical.com> - 2015-11-26 00:10 +0100
      Re: [PATCH 3.2 22/52] ALSA: hda - Disable 64bit address for  Creative HDA controllers Ben Hutchings <ben@decadent.org.uk> - 2015-11-26 01:40 +0100
        Re: [PATCH 3.2 22/52] ALSA: hda - Disable 64bit address for Creative  HDA controllers Luis Henriques <luis.henriques@canonical.com> - 2015-11-26 11:40 +0100

#1276875 — [PATCH 3.2 22/52] ALSA: hda - Disable 64bit address for Creative HDA controllers

3.2.74-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Takashi Iwai <tiwai@suse.de>

commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream.

We've had many reports that some Creative sound cards with CA0132
don't work well.  Some reported that it starts working after reloading
the module, while some reported it starts working when a 32bit kernel
is used.  All these facts seem implying that the chip fails to
communicate when the buffer is located in 64bit address.

This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT
flag to the corresponding PCI entries.  I casually had a chance to
test an SB Recon3D board, and indeed this seems helping.

Although this hasn't been tested on all Creative devices, it's safer
to assume that this restriction applies to the rest of them, too.  So
the flag is applied to all Creative entries.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
[bwh: Backported to 3.2: drop the change to AZX_DCAPS_PRESET_CTHDA]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -3099,11 +3099,13 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids)
 	  .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8,
 	  .class_mask = 0xffffff,
 	  .driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
+	  AZX_DCAPS_NO_64BIT |
 	  AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
 #else
 	/* this entry seems still valid -- i.e. without emu20kx chip */
 	{ PCI_DEVICE(0x1102, 0x0009),
 	  .driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
+	  AZX_DCAPS_NO_64BIT |
 	  AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
 #endif
 	/* Vortex86MX */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1277869

On Tue, Nov 24, 2015 at 10:33:59PM +0000, Ben Hutchings wrote:
> 3.2.74-rc1 review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Takashi Iwai <tiwai@suse.de>
> 
> commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream.
> 
> We've had many reports that some Creative sound cards with CA0132
> don't work well.  Some reported that it starts working after reloading
> the module, while some reported it starts working when a 32bit kernel
> is used.  All these facts seem implying that the chip fails to
> communicate when the buffer is located in 64bit address.
> 
> This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT
> flag to the corresponding PCI entries.  I casually had a chance to
> test an SB Recon3D board, and indeed this seems helping.
> 
> Although this hasn't been tested on all Creative devices, it's safer
> to assume that this restriction applies to the rest of them, too.  So
> the flag is applied to all Creative entries.
> 
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> [bwh: Backported to 3.2: drop the change to AZX_DCAPS_PRESET_CTHDA]

Is there a reason for dropping this change?  Adding the
AZX_DCAPS_NO_64BIT flag to the AZX_DCAPS_PRESET_CTHDA definition does
seem to make sense.

Cheers,
--
Luís

> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -3099,11 +3099,13 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids)
>  	  .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8,
>  	  .class_mask = 0xffffff,
>  	  .driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
> +	  AZX_DCAPS_NO_64BIT |
>  	  AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
>  #else
>  	/* this entry seems still valid -- i.e. without emu20kx chip */
>  	{ PCI_DEVICE(0x1102, 0x0009),
>  	  .driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
> +	  AZX_DCAPS_NO_64BIT |
>  	  AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
>  #endif
>  	/* Vortex86MX */
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277914 — Re: [PATCH 3.2 22/52] ALSA: hda - Disable 64bit address for Creative HDA controllers

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2015-11-25 at 23:05 +0000, Luis Henriques wrote:
> On Tue, Nov 24, 2015 at 10:33:59PM +0000, Ben Hutchings wrote:
> > 3.2.74-rc1 review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Takashi Iwai <tiwai@suse.de>
> > 
> > commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream.
> > 
> > We've had many reports that some Creative sound cards with CA0132
> > don't work well.  Some reported that it starts working after reloading
> > the module, while some reported it starts working when a 32bit kernel
> > is used.  All these facts seem implying that the chip fails to
> > communicate when the buffer is located in 64bit address.
> > 
> > This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT
> > flag to the corresponding PCI entries.  I casually had a chance to
> > test an SB Recon3D board, and indeed this seems helping.
> > 
> > Although this hasn't been tested on all Creative devices, it's safer
> > to assume that this restriction applies to the rest of them, too.  So
> > the flag is applied to all Creative entries.
> > 
> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > [bwh: Backported to 3.2: drop the change to AZX_DCAPS_PRESET_CTHDA]
> 
> Is there a reason for dropping this change?  Adding the
> AZX_DCAPS_NO_64BIT flag to the AZX_DCAPS_PRESET_CTHDA definition does
> seem to make sense.
[...]

The AZX_DCAPS_PRESET_CTHDA macro was introduced in 3.5.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

[toc] | [prev] | [next] | [standalone]

#1278140

On Thu, Nov 26, 2015 at 12:34:33AM +0000, Ben Hutchings wrote:
> On Wed, 2015-11-25 at 23:05 +0000, Luis Henriques wrote:
> > On Tue, Nov 24, 2015 at 10:33:59PM +0000, Ben Hutchings wrote:
> > > 3.2.74-rc1 review patch.  If anyone has any objections, please let me know.
> > > 
> > > ------------------
> > > 
> > > From: Takashi Iwai <tiwai@suse.de>
> > > 
> > > commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream.
> > > 
> > > We've had many reports that some Creative sound cards with CA0132
> > > don't work well.  Some reported that it starts working after reloading
> > > the module, while some reported it starts working when a 32bit kernel
> > > is used.  All these facts seem implying that the chip fails to
> > > communicate when the buffer is located in 64bit address.
> > > 
> > > This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT
> > > flag to the corresponding PCI entries.  I casually had a chance to
> > > test an SB Recon3D board, and indeed this seems helping.
> > > 
> > > Although this hasn't been tested on all Creative devices, it's safer
> > > to assume that this restriction applies to the rest of them, too.  So
> > > the flag is applied to all Creative entries.
> > > 
> > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > [bwh: Backported to 3.2: drop the change to AZX_DCAPS_PRESET_CTHDA]
> > 
> > Is there a reason for dropping this change?  Adding the
> > AZX_DCAPS_NO_64BIT flag to the AZX_DCAPS_PRESET_CTHDA definition does
> > seem to make sense.
> [...]
> 
> The AZX_DCAPS_PRESET_CTHDA macro was introduced in 3.5.
>

Doh, you're right.  I was probably looking at the wrong branch.  Sorry for
the noise.

Cheers,
--
Luís


> Ben.
> 
> -- 
> Ben Hutchings
> Unix is many things to many people,
> but it's never been everything to anybody.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web