Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp11154734imu; Thu, 6 Dec 2018 12:27:27 -0800 (PST) X-Google-Smtp-Source: AFSGD/U7Ry0wKlENbgbQwhxlpbt5kr7jpBe1pwWn8DbuDCmoKeRBzxg9L/59/LCtm5+t5F+oVGrt X-Received: by 2002:a63:d818:: with SMTP id b24mr24801778pgh.174.1544128047850; Thu, 06 Dec 2018 12:27:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544128047; cv=none; d=google.com; s=arc-20160816; b=kl3shHyCz4XQWbOpywhFOfJow0Bk9AF+ysTxlUv2+qT4nw6fnFFanQ2cnEktQR6sw6 gQyb29AGNC4ViDqN/Pha5FuWt2CjxNtlJ4oWi+gUjAmWlQsPZby3pH5zrpw9VB8pnOnv 8S+YqCh4u/idEwS/JAmK3CUQnpz8tdasbHmwQ9OKf7JXX4OzahEwc51RR3dCvPQP4Bwd xbE0/iImmfXVaEDeDOO14VDw4wml2qyGo7/zQWdh/mgwbmJUc48hvn1bLsaByE9BafJS wCQlZ1L9Lx2+CT0f1nGQ5Te3lQlT9xV1RE47dN/0fprjWfeuWsbL390pCwtehRVc5PbE 04TA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:message-id:in-reply-to:subject:cc:to :from:dkim-signature; bh=7Dpa3fEkZkb7TktocD6arHERMVCyxx1R12xaOFEbhqs=; b=WXmc+09NieQbJRQ306/rhpMeMrcW/b0ovI5o0o55njlpOfQA0dEemQjYlqL9Ya89I5 hzBa3hOLKWk6ZWqBpicW5H9qSWCqzxn5Gv0sWMc7CToVCKRaiwb+rzrettNDhr6siqFD 9ZOKeGQoHdZkc8LoiN7cy/aICKNBUc54W2rry6plAqeO5z41Ub2hSlPhfxPK7sDQVmZY QiDEXzZQxARtaYweWN0ho4HvRp8Tun1dmTp/v3P3dy7pIJHF72JMOlPdVC3ZP0rUEup7 J5FzTkrhuJ9lZdSQq/ePqeERcPE4jNqFUwcW+tH7GgqWGVskx/p2nciK+uN3kLqUeQ5f U6Ug== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=CmSivIzw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l24si949929pgb.489.2018.12.06.12.27.12; Thu, 06 Dec 2018 12:27:27 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=CmSivIzw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726098AbeLFU0P (ORCPT + 99 others); Thu, 6 Dec 2018 15:26:15 -0500 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:37110 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725993AbeLFU0P (ORCPT ); Thu, 6 Dec 2018 15:26:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=Date:Message-Id:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner: List-Archive; bh=7Dpa3fEkZkb7TktocD6arHERMVCyxx1R12xaOFEbhqs=; b=CmSivIzw9UQ2 0fLev91UngYmKptuD1uSujZ7tb76WbT3zqpiwA0710zFTls0oFR4gkj8JaQGtBHGinSxfQpIlfJ6p Fnmr1TiYL2rO/cuIeTcVahb0YWO9tzIUZcbsrA495bbT/0IIN83CfpKtsQuUR3O+xEMacAdwVWpge ILxUI=; Received: from cpc102320-sgyl38-2-0-cust46.18-2.cable.virginm.net ([82.37.168.47] helo=debutante.sirena.org.uk) by heliosphere.sirena.org.uk with esmtpa (Exim 4.89) (envelope-from ) id 1gV0Dk-0001hS-HK; Thu, 06 Dec 2018 20:26:04 +0000 Received: by debutante.sirena.org.uk (Postfix, from userid 1000) id 3B4DD11252F7; Thu, 6 Dec 2018 20:26:04 +0000 (GMT) From: Mark Brown To: Yu Zhao Cc: Mark Brown , Liam Girdwood , Mark Brown , aroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, Daniel Kurtz , Akshu Agrawal , Vijendar Mukunda , Alex Deucher , alsa-devel@alsa-project.org Subject: Applied "ASoC: use dma_ops of parent device for acp_audio_dma" to the asoc tree In-Reply-To: <20181204224253.216075-2-yuzhao@google.com> X-Patchwork-Hint: ignore Message-Id: <20181206202604.3B4DD11252F7@debutante.sirena.org.uk> Date: Thu, 6 Dec 2018 20:26:04 +0000 (GMT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The patch ASoC: use dma_ops of parent device for acp_audio_dma has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark From 23aa128bb28d9da69bb1bdb2b70e50128857884a Mon Sep 17 00:00:00 2001 From: Yu Zhao Date: Tue, 4 Dec 2018 15:42:53 -0700 Subject: [PATCH] ASoC: use dma_ops of parent device for acp_audio_dma AMD platform device acp_audio_dma can only be created by parent PCI device driver (drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c). Pass struct device of the parent to snd_pcm_lib_preallocate_pages() so dma_alloc_coherent() can use correct dma_ops. Otherwise, it will use default dma_ops which is nommu_dma_ops on x86_64 even when IOMMU is enabled and set to non passthrough mode. Though platform device inherits some dma related fields during its creation in mfd_add_device(), we can't simply pass its struct device to snd_pcm_lib_preallocate_pages() because dma_ops is not among the inherited fields. Even it were, drivers/iommu/amd_iommu.c would ignore it because get_device_id() doesn't handle platform device. This change shouldn't give us any trouble even struct device of the parent becomes null or represents some non PCI device in the future, because get_dma_ops() correctly handles null struct device or uses the default dma_ops if struct device doesn't have it set. Signed-off-by: Yu Zhao Signed-off-by: Mark Brown --- sound/soc/amd/acp-pcm-dma.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c index fd3db4c37882..f4011bebc7ec 100644 --- a/sound/soc/amd/acp-pcm-dma.c +++ b/sound/soc/amd/acp-pcm-dma.c @@ -1146,18 +1146,21 @@ static int acp_dma_new(struct snd_soc_pcm_runtime *rtd) struct snd_soc_component *component = snd_soc_rtdcom_lookup(rtd, DRV_NAME); struct audio_drv_data *adata = dev_get_drvdata(component->dev); + struct device *parent = component->dev->parent; switch (adata->asic_type) { case CHIP_STONEY: ret = snd_pcm_lib_preallocate_pages_for_all(rtd->pcm, SNDRV_DMA_TYPE_DEV, - NULL, ST_MIN_BUFFER, + parent, + ST_MIN_BUFFER, ST_MAX_BUFFER); break; default: ret = snd_pcm_lib_preallocate_pages_for_all(rtd->pcm, SNDRV_DMA_TYPE_DEV, - NULL, MIN_BUFFER, + parent, + MIN_BUFFER, MAX_BUFFER); break; } -- 2.19.0.rc2