From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 96AA034F497 for ; Tue, 9 Sep 2025 16:22:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757434925; cv=none; b=oJTRddqbJkL1C5JvtPMZnwYEwZMT/kqv+uors4dyGKsPtHojrN4tHGSJM97C2R2RnrSEO10cg7JCfH2J/BmMJqDi12hYM3XfH9ebniH1Aa86k/9fBvF0PVPSXzJ24aIRsySsa0Q2uCDPxWlPcehCfA7HxeVmRZx5CtUOC0bHmOg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757434925; c=relaxed/simple; bh=5NEls3RautMWjf7fmx/h17K5+vxU6Xp1Jd5Y5X7kUVs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Mo8ww8tRcQMlA91xEWjNh0aN4FoxnE/UQep7GA7uV7dRvwWPNL179S1hV51zg75DSELqSDJd4P1WzMRjLDAzbkQyBLb7ukEBj5nnMb5h31bqFwWB50/Tm13PHXG6hC6KC5piK1jNWgosN+33c0ddxw08GfS93gXex1g/RGZq4mQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=gvYiNVeX; arc=none smtp.client-ip=209.85.221.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="gvYiNVeX" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-3d44d734cabso4110688f8f.3 for ; Tue, 09 Sep 2025 09:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1757434922; x=1758039722; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=vB6vel85xH/3moH+g+uQmnmcTAMVpwBdAUJ6dS/hQ0o=; b=gvYiNVeXu5uADjRR2MmJUy2uI7e67WSccTi1Du44hF35vPy7XCSVviAZo/mkAjcnbN 6OO3DlHVM+E0sETda7750zlnF/LuUxVUOLkBrGHNow1wx1lE/upMMRrUwkTg31YeBq4V s7sFWc5w6/Fto3I4nowgBiNBMv2huw3KzDJ3Bmr7j8HEZWclBHU2M4zu6htP/3sI5Bd6 Zpw+BbCFnEoQU9xPH56SvtGiJABw1HUi65+Zn/u5bf9L9PLWBDvqIcrAFLkb5NILhiz3 ABvYqbWUG50QXS1ZlpSiUlvjV5AQYCHBpWHDB4C2SU4ys0M66qOOyAY6jwrfdnrxNQKJ Y8Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757434922; x=1758039722; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vB6vel85xH/3moH+g+uQmnmcTAMVpwBdAUJ6dS/hQ0o=; b=lMuh5fuN5OgTNuiNCZ/6yosNWVU7zbzFSD6Vx7MN23PSV6RGrZ7MykzCnpQlb8gXGo DBUeAxVGRO5ojQc/9vMGjohdq4Ii2DhggJzpzC9bVAAf5WDOan8JaYI4JZQnobEgCm3c QeG7AHpMIes6M067BCRvzWyqeDUuinmiiin7ofVYJCm0uJPHoaai0V4DANb/iYrIs2Xg NvHvITyrXTd3VJDdD62IPtZMRUrTPD7YzsJdY1i291+pJ3J2o7zOjXoc5G7jgRiLcpgA CBNTY9GAV8Se7WXxLS6eyXTXFCJSzO3OaptHyouku0AJubAeM/qPwfGqQIEU45lKF6FG t4gg== X-Forwarded-Encrypted: i=1; AJvYcCUil1e4MyyE1MRPPZcylJvHtMftI8/ETJRlEmSXHLvtGZJ2c/mMvK7k9c/7E7P6JRwXKItBhsudqP0a@vger.kernel.org X-Gm-Message-State: AOJu0Yzu1xbqYjYTxTJA6qJZ0oMyXfDyMHoHeQHXhweUsdpX0LPLdRQj oO2fsPwCsrVhJR9YST8djvtonD/JWb4QnqI7V2lgvK0zNHiuv6Vmj/CXeECY4we8XQM= X-Gm-Gg: ASbGncsvB/jmzYE0NH1A7m1+6gwOC63E3xt3pi1VMFYfP8UQmrunZ5zEt+HAnp+L+Pe CnlaBTDuKP0H+A/X9Hmz3DXDlbzmZG2RxC0f+oeaXccfn/1oqeTkw3XGvA41iomitVrW1W/S6Sk UiQtCsJ8qymp5b89yk7Pk5P5Tlaj8rA3rB9qJlz8NTGW+h76/eugKLdNzF+BgfcT0SiUJkkvLrI aV51qzVZOf9LvTPNKpH7d3sk6PFJRa9DR5J9T7DQCwL+2fZyin/dRMQbGWsVXZVoNbugsAIXhBB mE9y2vT0nt86IONUSBPPmB7GIAnoEq48umTx2Z2p85bGNC7Wht8qi76ndLQoDCzo7HVgvw6j3L4 Yqrnc1xPWifkHfBklhZfhB5oJvCdFeH/UAmg8AAPLLPU+iXTnMAf1iw97nOs6A5+yd2BqYVyNIP p3+Q== X-Google-Smtp-Source: AGHT+IHGjEvpUk4kRe6tL0aUTwHSNc54ByX9LFjKz57zJu5HMFNymvEeL6UiPy8a+Af/hD4XTZIDpg== X-Received: by 2002:a05:6000:2c0c:b0:3e7:46bf:f89d with SMTP id ffacd0b85a97d-3e746bffe2dmr8337138f8f.44.1757434921854; Tue, 09 Sep 2025 09:22:01 -0700 (PDT) Received: from ?IPV6:2a05:6e02:1041:c10:545e:637a:28a6:9ede? ([2a05:6e02:1041:c10:545e:637a:28a6:9ede]) by smtp.googlemail.com with ESMTPSA id 5b1f17b1804b1-45df65e79desm3405345e9.2.2025.09.09.09.22.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Sep 2025 09:22:01 -0700 (PDT) Message-ID: <222acc86-c405-4e05-ac8c-520ba81ef0a0@linaro.org> Date: Tue, 9 Sep 2025 18:22:00 +0200 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/2] iio: adc: Add the NXP SAR ADC support for the s32g2/3 platforms To: =?UTF-8?Q?Nuno_S=C3=A1?= , David Lechner , jic23@kernel.org, nuno.sa@analog.com, andy@kernel.org, robh@kernel.org, conor+dt@kernel.org, krzk+dt@kernel.org Cc: linux-iio@vger.kernel.org, s32@nxp.com, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, chester62515@gmail.com, mbrugger@suse.com, ghennadi.procopciuc@oss.nxp.com References: <20250903102756.1748596-1-daniel.lezcano@linaro.org> <20250903102756.1748596-3-daniel.lezcano@linaro.org> <0bfce1eb-69f1-4dae-b461-234eb98ffce1@linaro.org> <6b8cd005-b04c-4dd7-abf7-5a51319a5f0a@baylibre.com> <23b80d52-6149-483b-a159-276dd00d12cd@linaro.org> Content-Language: en-US From: Daniel Lezcano In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 09/09/2025 11:29, Nuno Sá wrote: > Hi *Daniel* (sorry for that :)), > > On Mon, 2025-09-08 at 08:58 -0500, David Lechner wrote: >> On 9/8/25 7:16 AM, Daniel Lezcano wrote: >>> On 05/09/2025 23:54, David Lechner wrote: >>>> On 9/5/25 3:58 PM, Daniel Lezcano wrote: >>>>> On 05/09/2025 17:25, David Lechner wrote: >>>>>> On 9/5/25 4:44 AM, Daniel Lezcano wrote: >>>>>>> On 04/09/2025 19:49, David Lechner wrote: >>>>>>>> On 9/4/25 12:40 PM, Daniel Lezcano wrote: >>>>> >>>>> [ ... ] [ ... ] >> Unfortunately, not really. Until the last few years, there wasn't really >> any users of these APIs. I added devm_iio_dmaengine_buffer_setup_with_handle() >> for the SPI offloading work I did recently. The only reason it had to be >> added is because we needed to get the DMA handle from a different devicetree >> node from the ADC's node. Since this device has dmas and dma-names in >> the devicetree, then if devm_iio_dmaengine_buffer_setup[_ext]() doesn't work >> with that, then it might have other problems (assumptions made for a specific >> use case) than just not calling dma_slave_config(). >> >> I think maybe Nuno and certainly I are guilty of trying to offer you advice >> without looking deeply enough into what you already submitted. :-/ >> > > Yes, I pretty much just asked for (at least) some discussion about this and see > if we could use what we already have in IIO. > >> I see now that what you are doing with the DMA looks more like other SoC ADCs >> (AT91/STM32/AM335x) which is quite different from how the iio_dmaengine_buffer >> stuff works, e.g. cyclic vs. not. So unless you are interested in evolving > > Supporting cyclic should be fairly easy (Paul left it almost prepared for it) > and do I have some patches already. I'm just waiting on having something > accepted on the ADI DMA IP driver (dmaengine) before sending the IIO patches I > already have. > >> the iio_dmaengine_buffer code to be more general to handle this case as well, >> it might not be the right tool for the job currently. > > I think for the STM (IIRC) case they "open" coded it because the IIO DMA support > we had at the time (if any) was more "rudimentary" - (no real zero copy > interface with userspace for example). But yeah, it seems there are some gaps > for your usecase so as David said, you would need to be interested in evolving > the IIO DMA API to accommodate your needs. Again, if nicely integrated you would > gain some nice "improvements" in performance (not having to use the fileio > interface for reading the buffers) for "free". > > As for dma_slave_config(), you're right and we have no usecase needing that > setup and TBH, I did not looked or have any idea (atm) on how to do it. That > said, I'll be here to help and contribute if you decide to try and follow the > IIO DMA buffer API. I would be glad to help improving the IIO DMA but I don't have enough bandwidth ATM. I was hoping to get this driver merged for v6.18 which is the next LTS AFAICT. Is it something possible by taking into account all the comments without improving the DMA code ? Do you have a pointer to Paul's series and the patches you mentioned above ? I can give a try when having some spare time -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog