From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E829AFA373F for ; Sun, 23 Oct 2022 10:56:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230165AbiJWK4i (ORCPT ); Sun, 23 Oct 2022 06:56:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51846 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229973AbiJWK4h (ORCPT ); Sun, 23 Oct 2022 06:56:37 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37B635A8DB; Sun, 23 Oct 2022 03:56:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A888B60B61; Sun, 23 Oct 2022 10:56:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D14D3C433C1; Sun, 23 Oct 2022 10:56:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1666522596; bh=lyTdIKeZjwi6PoGVvjTDLmW7YJbAZtMOfj7JmOF6Gmw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=NYPN8VkGrvo19tKNOorOnl8MKQZvblC5h8iXLPadyri41aTPyDui7E+JY5laKk+DL HLXoCzTDhLStJFiOsTWS7Ncr1r0Q1BZF8UMrxr8FSNQw10fyEnSJvTK9KVZipqgMvu Pm06NM/KwM3bDnwN6EgJ5sg+pW6tCqZcRnCOZ3HBg5qOnzkoejcMbW072nABaLReYu mx60T4xZD0Lx1O0iMQEHmgnQ0Pbc4lwiMYYdl2OZ0wlBlNfEKSUk3/FlhgO4qHfiUT gdTCJn9FaCuXP6NgrgH/Q35es00kmSD38ewz/SOd9ZOWo/MCEdOnPw5IlbI+dJeBFy MqZCizIzCf3Tg== Date: Sat, 25 Jun 2022 14:32:53 +0100 From: Jonathan Cameron To: Andy Shevchenko Cc: Cosmin Tanislav , Rob Herring , Linus Walleij , linux-iio , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , devicetree , Cosmin Tanislav Subject: Re: [PATCH v5 2/2] iio: adc: ad4130: add AD4130 driver Message-ID: <20220625143253.0c022fcd@jic23-huawei> In-Reply-To: References: <20220620162059.1097264-1-cosmin.tanislav@analog.com> <20220620162059.1097264-3-cosmin.tanislav@analog.com> <2aa93eab-de6d-866b-a829-36b47ff00982@gmail.com> <54bfff70-938f-16e1-198d-47ed9ba95db4@gmail.com> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, 23 Jun 2022 19:33:45 +0200 Andy Shevchenko wrote: > On Thu, Jun 23, 2022 at 6:14 PM Cosmin Tanislav wrote: > > On 6/23/22 18:39, Andy Shevchenko wrote: > > > On Thu, Jun 23, 2022 at 5:27 PM Cosmin Tanislav wrote: > > >> On 6/20/22 21:29, Andy Shevchenko wrote: > > >>> On Mon, Jun 20, 2022 at 6:27 PM Cosmin Tanislav wrote: > > ... > > > >>>> + /* > > >>>> + * DMA (thus cache coherency maintenance) requires the > > >>>> + * transfer buffers to live in their own cache lines. > > >>>> + */ > > >>> > > >>> This is a good comment, but what fields does it apply to? > > >> > > >> Whatever is below it, grouped together. This is not hard to > > >> understand. > > > > > > It's hard to understand what exactly is DMA-aware here. I see only one > > > buffer that is aligned properly for DMA, the rest are not, except the > > > case if all of them are going in one DMA transaction. Is this the case > > > here? > > > > > >>>> + u8 reset_buf[AD4130_RESET_BUF_SIZE] __aligned(IIO_DMA_MINALIGN); > > > > > > This is aligned. > > > > > >>>> + u8 reg_write_tx_buf[4]; > > > > > > This one is aligned + offset (== AD4130_RESET_BUF_SIZE + 0). > > > > > >>>> + u8 reg_read_tx_buf[1]; > > > > > > This one is aligned + offset (== AD4130_RESET_BUF_SIZE + 0 + 4). > > > > > >>>> + u8 reg_read_rx_buf[3]; > > > > > > This one is aligned + offset (== AD4130_RESET_BUF_SIZE + 0 + 4 + 1). > > > And this is Rx. > > > > > >>>> + u8 fifo_tx_buf[2]; > > > > > > Here is Tx again which is most likely is not aligned... > > > > > >>>> + u8 fifo_rx_buf[AD4130_FIFO_SIZE * > > >>>> + AD4130_FIFO_MAX_SAMPLE_SIZE]; > > >>>> +}; > > > > > > > This has been mentioned before by Jonathan as a reply to V6 of my > > AD74413R driver. > > > > > I'm surprised I didn't mention this before but you only need to > > ensure > that any memory used for DMA is not in a cacheline with memory > > used > > > for other things that might change concurrently. > > > > To my understanding, as long as the DMA buffers will all be accessed by > > the same DMA-compatible SPI controller, you only need to align them so > > they're not in the same cacheline with memory that will not be accessed > > by the SPI controller. > > SPI is synchronous by nature, what will happen if the Tx and Rx > buffers are sharing the same cache line? Anybody to shed a light here? > > (I.o.w. I'm not sure that we don't need to split the Rx and Tx buffers > of the same transfer.) My understanding is that any device that stamps on itself is considered broken and needs to do it's own bounce buffering. We just need to ensure no CPU writes hit stuff in the same cacheline whilst DMA is in progress. A clarification to the comment to say that it covers all the buffers at the end of the structure would be a good addition. Jonathan