From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757082AbYKTV5X (ORCPT ); Thu, 20 Nov 2008 16:57:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755956AbYKTV5O (ORCPT ); Thu, 20 Nov 2008 16:57:14 -0500 Received: from an-out-0708.google.com ([209.85.132.250]:46000 "EHLO an-out-0708.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755697AbYKTV5N (ORCPT ); Thu, 20 Nov 2008 16:57:13 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=lQop0wVbSmS/IYTblfKMWn+CRGrtTQ7hACQnSMIn1+vTieJJMfRYOmM/StOqAcuWpr O3CLJizw+BxZaC+bgk4lmGT0S4UrxHXXuPsbOzR1ox+YU6OsFW3guYYJxuHmU8F7rU/G 93Zx1UYYAyaSVzYtli3NOPo9lFNmVnIlQrrdY= Message-ID: <8bd0f97a0811201357g1ffeb7d3pfad6e178fb20050e@mail.gmail.com> Date: Thu, 20 Nov 2008 16:57:12 -0500 From: "Mike Frysinger" To: "David Brownell" Subject: Re: [PATCH 01/16] Blackfin SPI Driver: ensure cache coherency before doing DMA Cc: "Bryan Wu" , spi-devel-general@lists.sourceforge.net, linux-kernel@vger.kernel.org, "Vitja Makarov" In-Reply-To: <200811201347.46355.david-b@pacbell.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1226994760-4301-1-git-send-email-cooloney@kernel.org> <200811201224.15493.david-b@pacbell.net> <8bd0f97a0811201258j14dfcf46vce1655632bb12e2@mail.gmail.com> <200811201347.46355.david-b@pacbell.net> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 20, 2008 at 16:47, David Brownell wrote: > On Thursday 20 November 2008, Mike Frysinger wrote: >> On Thu, Nov 20, 2008 at 15:24, David Brownell wrote: >> > On Monday 17 November 2008, Bryan Wu wrote: >> >> /* set transfer mode, and enable SPI */ >> >> dev_dbg(&drv_data->pdev->dev, "doing DMA in.\n"); >> >> >> >> + /* invalidate caches, if needed */ >> >> + if (bfin_addr_dcachable((unsigned long) drv_data->rx)) >> >> + invalidate_dcache_range((unsigned long) drv_data->rx, >> >> + (unsigned long) (drv_data->rx + >> >> + drv_data->len)); >> > >> > As a rule, you should use the standard kernel interfaces >> > for such stuff instead of platform-specific calls like >> > those two. There are a LOT more developers who can find >> > and fix bugs that way. >> >> could you elaborate on the common calls that would replace these ? > > See Documentation/DMA-(mapping,API}.txt ... the "mapping" > document's section on what memory may be used for DMA is > not otherwise replicated in the description of the "generic" > versions of those API calls. > > Basically, dma_map_single(), dma_unmap_single() ... and > remember that the caller may have done the mappings for > you already. these arent required to provide coherent memory right ? if that's the case, i can take a look at getting things updated. >> > Also, this patch affects the "not full duplex" branch of >> > this routine. DMA here seems unusually convoluted ... but >> > if you didn't invalidate the cache (RX path) before >> > flushing it (TX path) and instead did it the other way >> > aroound, would you actually *need* separate branches? >> >> it's convoluted because the hardware sucks. it cant do full duplex >> with DMA. full duplex only works in the non-DMA case. > > Ah, ok. Sucky hardware -- been there, done that, still doing. ;) > > It'd be nice if one of patches snuck in a comment on that > point: "Full duplex only works for non-DMA transfers." > Same rationale: you may know this hardware inside out, > but the next person won't. well, hopefully if they dont know they wont be touching the driver ;). i'll add a comment in this code chunk. thanks for the feedback. -mike From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mike Frysinger" Subject: Re: [PATCH 01/16] Blackfin SPI Driver: ensure cache coherency before doing DMA Date: Thu, 20 Nov 2008 16:57:12 -0500 Message-ID: <8bd0f97a0811201357g1ffeb7d3pfad6e178fb20050e@mail.gmail.com> References: <1226994760-4301-1-git-send-email-cooloney@kernel.org> <200811201224.15493.david-b@pacbell.net> <8bd0f97a0811201258j14dfcf46vce1655632bb12e2@mail.gmail.com> <200811201347.46355.david-b@pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Vitja Makarov , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "David Brownell" Return-path: In-Reply-To: <200811201347.46355.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org On Thu, Nov 20, 2008 at 16:47, David Brownell wrote: > On Thursday 20 November 2008, Mike Frysinger wrote: >> On Thu, Nov 20, 2008 at 15:24, David Brownell wrote: >> > On Monday 17 November 2008, Bryan Wu wrote: >> >> /* set transfer mode, and enable SPI */ >> >> dev_dbg(&drv_data->pdev->dev, "doing DMA in.\n"); >> >> >> >> + /* invalidate caches, if needed */ >> >> + if (bfin_addr_dcachable((unsigned long) drv_data->rx)) >> >> + invalidate_dcache_range((unsigned long) drv_data->rx, >> >> + (unsigned long) (drv_data->rx + >> >> + drv_data->len)); >> > >> > As a rule, you should use the standard kernel interfaces >> > for such stuff instead of platform-specific calls like >> > those two. There are a LOT more developers who can find >> > and fix bugs that way. >> >> could you elaborate on the common calls that would replace these ? > > See Documentation/DMA-(mapping,API}.txt ... the "mapping" > document's section on what memory may be used for DMA is > not otherwise replicated in the description of the "generic" > versions of those API calls. > > Basically, dma_map_single(), dma_unmap_single() ... and > remember that the caller may have done the mappings for > you already. these arent required to provide coherent memory right ? if that's the case, i can take a look at getting things updated. >> > Also, this patch affects the "not full duplex" branch of >> > this routine. DMA here seems unusually convoluted ... but >> > if you didn't invalidate the cache (RX path) before >> > flushing it (TX path) and instead did it the other way >> > aroound, would you actually *need* separate branches? >> >> it's convoluted because the hardware sucks. it cant do full duplex >> with DMA. full duplex only works in the non-DMA case. > > Ah, ok. Sucky hardware -- been there, done that, still doing. ;) > > It'd be nice if one of patches snuck in a comment on that > point: "Full duplex only works for non-DMA transfers." > Same rationale: you may know this hardware inside out, > but the next person won't. well, hopefully if they dont know they wont be touching the driver ;). i'll add a comment in this code chunk. thanks for the feedback. -mike ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/