From patchwork Tue Jun 9 10:05:21 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?b?RWRkaWUgSHVhbmcgKOm7g+aZuuWCkSk=?= X-Patchwork-Id: 6570951 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 40698C0020 for ; Tue, 9 Jun 2015 10:08:13 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4E4FA20495 for ; Tue, 9 Jun 2015 10:08:12 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7624E203DF for ; Tue, 9 Jun 2015 10:08:11 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Z2GPv-0006tZ-3B; Tue, 09 Jun 2015 10:05:59 +0000 Received: from [210.61.82.184] (helo=mailgw02.mediatek.com) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Z2GPp-0006mg-Cj; Tue, 09 Jun 2015 10:05:55 +0000 X-Listener-Flag: 11101 Received: from mtkhts07.mediatek.inc [(172.21.101.69)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 31953377; Tue, 09 Jun 2015 18:05:23 +0800 Received: from [172.21.77.4] (172.21.77.4) by mtkhts07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 14.3.181.6; Tue, 9 Jun 2015 18:05:21 +0800 Message-ID: <1433844321.16178.6.camel@mtksdaap41> Subject: Re: [PATCH 2/3] spi: mediatek: Add spi bus for Mediatek MT8173 From: Eddie Huang To: Mark Brown Date: Tue, 9 Jun 2015 18:05:21 +0800 In-Reply-To: <20150608175927.GO14071@sirena.org.uk> References: <1431075343-7887-1-git-send-email-leilk.liu@mediatek.com> <1431075343-7887-3-git-send-email-leilk.liu@mediatek.com> <20150508175306.GG2761@sirena.org.uk> <1431434356.2128.9.camel@mhfsdcap03> <20150512160540.GB3066@sirena.org.uk> <1431675522.2128.13.camel@mhfsdcap03> <20150515092543.GY2761@sirena.org.uk> <1433758546.19786.16.camel@mtksdaap41> <20150608175927.GO14071@sirena.org.uk> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150609_030553_888516_34C026F2 X-CRM114-Status: GOOD ( 19.17 ) X-Spam-Score: 1.3 (+) Cc: Mark Rutland , "devicetree@vger.kernel.org" , srv_heupstream , Pawel Moll , Ian Campbell , Leilk Liu =?UTF-8?Q?=28=E5=88=98=E7=A3=8A=29?= , Catalin Marinas , Sascha Hauer , Will Deacon , "linux-kernel@vger.kernel.org" , "linux-spi@vger.kernel.org" , HongZhou Yang , Rob Herring , "linux-mediatek@lists.infradead.org" , Sascha Hauer , Kumar Gala , Matthias Brugger , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Mark, On Mon, 2015-06-08 at 18:59 +0100, Mark Brown wrote: > On Mon, Jun 08, 2015 at 06:15:46PM +0800, Eddie Huang wrote: > > On Fri, 2015-05-15 at 17:25 +0800, Mark Brown wrote: > > > > That's how a very large proportion of devices that work with DMA are > > > done - why would this be complicated? All can_dma() does is report if > > > DMA is possible. > > > In include/linux/spi/spi.h, it describes if can_dma() exists and returns > > true, dma_tx and dma_rx must be set.But Medaitek SPI controller has its > > own dma hardware, which means this dma resides in the same base address > > range with SPI controller, and only used by SPI, so we don't implement > > generic DMA driver, such that can't provide dma channel and assign to > > dmx_tx, dmx_rx parameter. We think it's strange to implement generic dma > > driver for dma that only used by specific hardware.Can we just provide > > can_dma() function and return false ? But I think it's a little odd that > > there actually has dma. So can we just skip can_dma() function let it be > > NULL ? > > If it's simply the unavailbility of a struct dma_chan we must be able to > get a better solution than just open coding all the DMA mapping and > unmapping in the driver. The only thing we actually use the channel for > is to get the device we need to use to do the mapping and unmapping, > either we need a way for devices to provide their own channels easily or > a way for SPI drivers to specify a device here instead of a channel. > The latter seems easier if a bit clunky (with having to work with both). I list two ways you mention. Pesudo code of your first suggestion: static int mtk_spi_probe(struct platform_device *pdev) { struct dma_chan *tx_chan; struct dma_device *tx_dma; tx_chan = devm_kzalloc(&pdev->dev, sizeof(*tx_chan), GFP_KERNEL); tx_dma = devm_kzalloc(&pdev->dev, sizeof(*tx_dma), GFP_KERNEL); tx_dma->dev = &pdev->dev; tx_chan->device = tx_dma; master->dma_tx = tx_chan; ... } Modification of your second suggestion: Is this what you want ? Actually, I don't like first one at all. Eddie Thanks --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -539,8 +539,8 @@ static int __spi_map_msg(struct spi_master *master, struct spi_message *msg) if (!master->can_dma) return 0; - tx_dev = master->dma_tx->device->dev; - rx_dev = master->dma_rx->device->dev; + tx_dev = master->dma_tx ? master->dma_tx->device->dev : master->dev; + rx_dev = master->dma_rx ? master->dma_rx->device->dev : master-