Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752682AbbKYXFQ (ORCPT ); Wed, 25 Nov 2015 18:05:16 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:48963 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752434AbbKYXFN (ORCPT ); Wed, 25 Nov 2015 18:05:13 -0500 Date: Wed, 25 Nov 2015 23:05:09 +0000 From: Luis Henriques To: Ben Hutchings Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, akpm@linux-foundation.org, Takashi Iwai Subject: Re: [PATCH 3.2 22/52] ALSA: hda - Disable 64bit address for Creative HDA controllers Message-ID: <20151125230509.GB21715@charon> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2448 Lines: 62 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 > > 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 > [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 > --- > --- 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/