Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752871AbYAWNSn (ORCPT ); Wed, 23 Jan 2008 08:18:43 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751536AbYAWNSe (ORCPT ); Wed, 23 Jan 2008 08:18:34 -0500 Received: from mail.hevs.ch ([153.109.23.15]:45539 "EHLO mail.hevs.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751009AbYAWNSd (ORCPT ); Wed, 23 Jan 2008 08:18:33 -0500 From: Marc Pignat Organization: HEVs To: Haavard Skinnemoen Subject: Re: [PATCH 6/6] atmel_serial: Add DMA support Date: Wed, 23 Jan 2008 14:18:38 +0100 User-Agent: KMail/1.9.7 Cc: Andrew Victor , kernel@avr32linux.org, linux-kernel@vger.kernel.org, Remy Bohmer , Chip Coldwell References: <1201013444-30370-1-git-send-email-hskinnemoen@atmel.com> <200801231330.32777.marc.pignat@hevs.ch> <20080123134553.144ca487@dhcp-252-066.norway.atmel.com> In-Reply-To: <20080123134553.144ca487@dhcp-252-066.norway.atmel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801231418.38997.marc.pignat@hevs.ch> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1306 Lines: 43 Hi! On Wednesday 23 January 2008, Haavard Skinnemoen wrote: > On Wed, 23 Jan 2008 13:30:32 +0100 > Marc Pignat wrote: > > On Wednesday 23 January 2008, Haavard Skinnemoen wrote: ... > > Ok, but then any power of two larger than the cache line size should be > fine, assuming kmalloc() returns a properly aligned buffer. Yes. The memory should be allocated using GFP_KERNEL | GFP_DMA flags, but this is probably a nop on at91 and avr32. I prepare a patch using the generic dma api (allocation + dma mapping in one call = simpler code). > > Other than that, I can't see any reason why a platform with 64 byte > cache lines should need larger buffers than one with 32 byte cache > lines. If the memory at the end of the cacheline is used by the cpu, it will be corrupted while you call dma_sync_single_for_cpu(..., DMA_FROM_DEVICE); ... > There are still issues with the DMA code that the PIO code doesn't > have. So I think it should be selectable until we can sort out the > error/break handling. ok > > Haavard > Regards Marc -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/