Received: by 10.192.165.156 with SMTP id m28csp348346imm; Thu, 12 Apr 2018 23:44:26 -0700 (PDT) X-Google-Smtp-Source: AIpwx48b+TjFV76/mRPzf+tzFOfuEDev8eF8GXOE1HH61dShKl6bRzUbiHCVAcAHvZno0PDPSSls X-Received: by 10.98.144.205 with SMTP id q74mr10317135pfk.55.1523601866373; Thu, 12 Apr 2018 23:44:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523601866; cv=none; d=google.com; s=arc-20160816; b=nF68dDrIe7VhKposStFSCkoN1fxiV+jDbkjYqlMs2U47diRT6k9/0vYe2vDJTx2cTY zBkYMlFIL6yZ8POWvNmzzltg2diKKanr0tZryq0UTNvO+kdhK6ky34zg8IUrptqqiP+6 G1C93oSK+Lh2SAAhhwwnrX3WEEEO1P0Z4Pf2z0qZ4QREbYB29QDyr3wltoLc0sJVui/V KKLFb0pSNswZq5aATwO3e/C87wvrmElZ1CB8BpSv3FOvTzNieRlTXdZJ+uMasOLJb7RI 95+7uEDBIYgIK14TYjTTlb52OsDP4JznTBG8VcMyhj/8+LdL4+GntvV6KFxYE1fdYkqc ITtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=+pX/AXeOsmr7N3lM/n7D2eP84tATK3cJ1ImIzMMBjUM=; b=r0X63ibvGZonSEVfmAzNqe9rJEr7ZY2sYf52xvyu8MbYAdZWffBeQSBKnpYJHjEFK3 TJoQY3QC8J0eo4mnRRkN3yx4ifpXBkI6oO8YYC14s8h3l/6/GDPdYZ04pU577ltOGSZK NYc0irJ7TqdHZDvFHfEi51s+jQK0RhDJZlzx5YRQLBNwgcGj3NGKH9PAwLkhJ89fo19G eUPFuCDXTDDGbuSxQKYb+jPPN4XxNbyMNNWrd7mqnmco1qKGqUo1MeIcWHi5dwBJVG8B nNXalPW9tPnYI924mkPitIQyiIU9Fq87Zeu2GjC2eJtzNqd0taXgTNupHARIsXW4pFkV GcPg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h13si3838981pfi.192.2018.04.12.23.44.12; Thu, 12 Apr 2018 23:44:26 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753300AbeDMGcP (ORCPT + 99 others); Fri, 13 Apr 2018 02:32:15 -0400 Received: from mga01.intel.com ([192.55.52.88]:33912 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752005AbeDMGcO (ORCPT ); Fri, 13 Apr 2018 02:32:14 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2018 23:32:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,444,1517904000"; d="scan'208";a="191174992" Received: from vkoul-udesk7.iind.intel.com (HELO localhost) ([10.223.84.143]) by orsmga004.jf.intel.com with ESMTP; 12 Apr 2018 23:32:11 -0700 Date: Fri, 13 Apr 2018 12:06:42 +0530 From: Vinod Koul To: Baolin Wang Cc: Dan Williams , Eric Long , Mark Brown , dmaengine@vger.kernel.org, LKML Subject: Re: [PATCH 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration Message-ID: <20180413063641.GL6014@localhost> References: <0c2b76aba6a49e583f920ae582d6815fa9cc4361.1523346135.git.baolin.wang@linaro.org> <20180411093634.GC6014@localhost> <20180412093735.GF6014@localhost> <20180413034332.GI6014@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 13, 2018 at 02:17:34PM +0800, Baolin Wang wrote: > > Agreed, users only care about grabbing a channel, setting a descriptor and > > submitting that. > > > > I think you need to go back and think about this a bit, please do go thru > > dmaengine documentation and see other driver examples. > > > > We don't typically expose these to users, they give us a transfer and we set > > that up in hardware for efficient. Its DMA so people expect us to use fastest > > mechanism available. > > But there are some configuration are really special for Spreadtrum > DMA, and must need user to specify how to configure, especially some > scenarios of audio. So I wander if we can add one pointer for > 'dma_slave_config' to expand some special DMA configuration > requirements, like: > > struct dma_slave_config { > ...... > unsigned int slave_id; > void *platform_data; > }; > > So if some DMA has some special configuration (such as Spreadtrum > DMA), they can user this platform_data pointer. Like xilinx DMA, they > also have some special configuration. Well we all think our HW is special and needs some additional stuff, most of the cases turns out not to be the case. Can you explain how audio in this case additional configuration... -- ~Vinod