From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7BB02C43334 for ; Fri, 17 Jun 2022 14:38:10 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id C0E731EEB; Fri, 17 Jun 2022 16:37:17 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz C0E731EEB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1655476687; bh=C8lLmoHiWU1WsE6Ejc0yYiERmWQdIclnm3WfOJmj7es=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=bzzSts/cRCZFFiEvxFi0S02S6j+yK0YQ6mt8GYV4uHi/eJX1f4EjZ4eYuyIGqroRB o4eRLNiZ9AXA9STEm+uNJpYRMyRJafG01RbFawyrpXSuPRO47BFR3WY0QdhoHP7hIe qXG1jlEZcShTszkbUwaxfSkxv+WmwzZQ8UFjx6js= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 57F96F8051F; Fri, 17 Jun 2022 16:37:17 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 3641FF80527; Fri, 17 Jun 2022 16:37:16 +0200 (CEST) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 11615F804BC for ; Fri, 17 Jun 2022 16:37:08 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 11615F804BC Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="WFqGf5IA"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="LgmVWSP8" Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 9956C1F897; Fri, 17 Jun 2022 14:37:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1655476627; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8tSEU3GQJk6/3e5aYU2iEVDmk5mVOGSCnyil3Bob8Os=; b=WFqGf5IAMGs8zjb6YPJqFN/LOGyh0VaspMOXmqbt5yQFU5dBKbU/fOoJK2nHjpfOYXz1R/ EWT4HIXhFMi6BwPQJlPrwlnqBrC0BEjGbLl2Y14JGVuyUeqWF8yFkox3q+h9dZ5gGgAo0d MdYN/mxpoT8sx03k84tWT0SG01ARyJM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1655476627; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8tSEU3GQJk6/3e5aYU2iEVDmk5mVOGSCnyil3Bob8Os=; b=LgmVWSP82DIMs2+6e/inzf8TGNrxYeBpbDGfPgOsyMLlS2/RZ+7ZP0fFOjdd0yqmCQrK9M 92qy2TgAtCsif9Cw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 73EF51348E; Fri, 17 Jun 2022 14:37:07 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id nd6IG5ORrGJ9MwAAMHmgww (envelope-from ); Fri, 17 Jun 2022 14:37:07 +0000 Date: Fri, 17 Jun 2022 16:37:07 +0200 Message-ID: <877d5f1hm4.wl-tiwai@suse.de> From: Takashi Iwai To: =?ISO-8859-1?Q?P=E9ter?= Ujfalusi Subject: Re: Can anyone test with AMD onboard or HDMI/DP? In-Reply-To: <0920a0b2-31be-8629-07d0-564bb49dc60d@linux.intel.com> References: <87bkur1nil.wl-tiwai@suse.de> <0920a0b2-31be-8629-07d0-564bb49dc60d@linux.intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: alsa-devel@alsa-project.org X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Fri, 17 Jun 2022 15:56:31 +0200, Péter Ujfalusi wrote: > > Hi Takashi, > > On 17/06/2022 15:29, Takashi Iwai wrote: > > Hi, > > Try #2, first mail did not made it through, I think. > > > can anyone have an AMD onboard audio device and/or AMD HDMI/DP output > > for testing a patch below with 5.18.x or 5.19-rc kernels? It's a > > pending fix (for 5.18+), but currently it can't be verified whether it > > causes a regression on the actual audio I/O (while it fixes the kernel > > crash). > > > > If the generic allocator still doesn't work as expected here, it > > should show some audio stuttering or such effect. > > But the fallback was needed for some machines using SOF to be able to > load the firmware... > like this: > https://github.com/thesofproject/linux/issues/3609 The bug isn't about the fallback of SG buffer we've already resolved, but rather about the continuous WC page allocations that happen for the CORB/RIRB or the position buffer on some devices like AMD. The Intel HD-audio doesn't hit the problem. Takashi > > > > > > > Thanks! > > > > Takashi > > > > -- 8< -- > > From: Takashi Iwai > > Subject: [PATCH] ALSA: memalloc: Drop x86-specific hack for WC allocations > > > > The recent report for a crash on Haswell machines implied that the > > x86-specific (rather hackish) implementation for write-cache memory > > buffer allocation in ALSA core is buggy with the recent kernel in some > > corner cases. This patch drops the x86-specific implementation and > > uses the standard dma_alloc_wc() & co generically for avoiding the bug > > and also for simplification. > > > > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216112 > > Signed-off-by: Takashi Iwai > > --- > > sound/core/memalloc.c | 23 +---------------------- > > 1 file changed, 1 insertion(+), 22 deletions(-) > > > > diff --git a/sound/core/memalloc.c b/sound/core/memalloc.c > > index 15dc7160ba34..8cfdaee77905 100644 > > --- a/sound/core/memalloc.c > > +++ b/sound/core/memalloc.c > > @@ -431,33 +431,17 @@ static const struct snd_malloc_ops snd_dma_iram_ops = { > > */ > > static void *snd_dma_dev_alloc(struct snd_dma_buffer *dmab, size_t size) > > { > > - void *p; > > - > > - p = dma_alloc_coherent(dmab->dev.dev, size, &dmab->addr, DEFAULT_GFP); > > -#ifdef CONFIG_X86 > > - if (p && dmab->dev.type == SNDRV_DMA_TYPE_DEV_WC) > > - set_memory_wc((unsigned long)p, PAGE_ALIGN(size) >> PAGE_SHIFT); > > -#endif > > - return p; > > + return dma_alloc_coherent(dmab->dev.dev, size, &dmab->addr, DEFAULT_GFP); > > } > > > > static void snd_dma_dev_free(struct snd_dma_buffer *dmab) > > { > > -#ifdef CONFIG_X86 > > - if (dmab->dev.type == SNDRV_DMA_TYPE_DEV_WC) > > - set_memory_wb((unsigned long)dmab->area, > > - PAGE_ALIGN(dmab->bytes) >> PAGE_SHIFT); > > -#endif > > dma_free_coherent(dmab->dev.dev, dmab->bytes, dmab->area, dmab->addr); > > } > > > > static int snd_dma_dev_mmap(struct snd_dma_buffer *dmab, > > struct vm_area_struct *area) > > { > > -#ifdef CONFIG_X86 > > - if (dmab->dev.type == SNDRV_DMA_TYPE_DEV_WC) > > - area->vm_page_prot = pgprot_writecombine(area->vm_page_prot); > > -#endif > > return dma_mmap_coherent(dmab->dev.dev, area, > > dmab->area, dmab->addr, dmab->bytes); > > } > > @@ -471,10 +455,6 @@ static const struct snd_malloc_ops snd_dma_dev_ops = { > > /* > > * Write-combined pages > > */ > > -#ifdef CONFIG_X86 > > -/* On x86, share the same ops as the standard dev ops */ > > -#define snd_dma_wc_ops snd_dma_dev_ops > > -#else /* CONFIG_X86 */ > > static void *snd_dma_wc_alloc(struct snd_dma_buffer *dmab, size_t size) > > { > > return dma_alloc_wc(dmab->dev.dev, size, &dmab->addr, DEFAULT_GFP); > > @@ -497,7 +477,6 @@ static const struct snd_malloc_ops snd_dma_wc_ops = { > > .free = snd_dma_wc_free, > > .mmap = snd_dma_wc_mmap, > > }; > > -#endif /* CONFIG_X86 */ > > > > #ifdef CONFIG_SND_DMA_SGBUF > > static void *snd_dma_sg_fallback_alloc(struct snd_dma_buffer *dmab, size_t size); > > -- > Péter >