From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 22FED3587BC for ; Tue, 18 Nov 2025 13:57:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763474265; cv=none; b=HEOsYjFNl2SeOlRCJ0C/7iOL3wKYuRaiw9hBZK2dtgwseOQws57DXmmNEyTYFh6hEAUi/sTslLqXpext5zHVZocvr60nDaTQv98SqdQuXMoiKF28rSlYSHT3So0+F6ITCwfgVhFFFti6DHtogrXsQ/zUX+vzcCT2d2AY8DQigm8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763474265; c=relaxed/simple; bh=mfMgEPem+bHdCW32SziEJw133LN6fYuGSmC870ikt8I=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=sSQ9HBeg50RyjR8Madkfr4NRl24uRodAOG0O9Y632tjxcZMDz+VdvTdpiXYJeybUPOlRbOYNMFrmZI1uJYjmg+NsHNEIHKZMQi3JoQ89rOb4WCNRDDl9lrk9eKjXSHraO0VITHJV8rm2F+hg41GE2rRFwC5/CQD+SvxHUtijlKc= 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=GC/MRswZ; arc=none smtp.client-ip=209.85.128.49 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="GC/MRswZ" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-47795f6f5c0so24570385e9.1 for ; Tue, 18 Nov 2025 05:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1763474262; x=1764079062; 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=SUDZ4lylaMkBQy9BPqNgegQrO9kWuZYea7qf7A3b2LY=; b=GC/MRswZcBaqLBUZI42NmlIMRt8m1+kqjMzSYRp/vGIwLdk4VT9YAhhFki3sgYhm+W 7MQVjmuUJQ1ez34bK5mLygiDm7A8dwn+hVGnbO2YjIAcFPlU7+W8xgQFPW7rjaMDaNkU r+Sk6lzg/k1I4q9jygJNZWo20NQvvNK/bhMHPNMg5KjBCzBUzinQnzlrmTHOluMtAiPh NOmzC/oRCgpT/56bJ7zDSDFpOMUaU2Ix2yn0C6+2pV70QGS+pFT7biLv+lICiEgdDAnT DTD4scazP+3d/b181e4SikN9AQAfjJpSQPTKLLLDqR6hEppqFZxJheA851yByUyrYQwz soAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763474262; x=1764079062; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SUDZ4lylaMkBQy9BPqNgegQrO9kWuZYea7qf7A3b2LY=; b=QPwLQJy3PD8BqEhQs++rg7kZ60T+J0kgVj+zZOAnKdGSDW7gZDx1+OQZ9bd24HFzjq TAFCMl13AaN0jEHJHET7vf1gWJslx452otyX54WjcYByCMRc8bfQpFsXWV+M9CVpd2ow GPD4DxdpiGRze3LlgDvO4OF5eMf7pwMV7trF3uZjzJuWW8F8CJK+HW5z7kYZiy07u0lV 9Nz7iniIYSGthmKw4QKRGWmRscxovco2dNtePDLymeDcwvWRPhjYShZkmyL4eWVGU7eY 4E0zfir6WGYW+RHJU+GpMUxCGP9eYPCyRW8xGzMC5J7kmAELgSb5H1wnZH8DjbeVFGvF 31ag== X-Forwarded-Encrypted: i=1; AJvYcCUjpo2Bx6Nnup5wF0WlOQosza+X2PU2Q2JyOLl/gnzBLnYcfFwKnmlFDWLD0G8m0Zg3crtED1F9Pg2D9VY=@vger.kernel.org X-Gm-Message-State: AOJu0YyqQJzqtd1tu9eVP4hc4HRjW3CfJrfGrN/aVaQt9ekdE5S3CfxJ CDs2DSyIjrY/Iog+XOYLmxkVhUyxqtd4NE9GMBEaC+DRy3cIk8HBZNsgul4ge5XZZdg= X-Gm-Gg: ASbGncvWZH58xVcVYYTce9m99WN9SYnqyYAJLIkMM/7K2NBnmAywNij5zc5O3HRseon Ys4pjjmzmV3UIRjmDvrDrW5d4mTQBbIGmYuHvtLfBjWfcM9/lVmu9yzieywqqV1ThNLtycH6i03 XbHG1WYGACqK/67lGOoau9I7LUG/N8JKNUzVALq4t7/QeyleiRFTVgIC9CDkZEQg5OsFVk222O3 qe8mUQ/NRQ2iPIuP/dUSZOA7L+XcRuN9NtfrVEwqof/a8pQTRZu4JU2gy/moEircfUT6wSvncoL cgHPtWRF374/ADaKL+T/ZpvBp0sUr9FBlpogrvPMaygejMVlg/QKomzOx7nw30DGz2G+kd59Q2E rOAWAZbz9iD8Jc1AL/3qAZ4qcfhTe5nU0YNwux20s45zU262bkR9VVXqtwzfhesMmtukA09kunZ WpyiwvHrz3RSx/pce+jOe69g1NkTiBuiIHZkq7iIJe+vnHSiScbNF7KYlmruRbjbF8UQ== X-Google-Smtp-Source: AGHT+IG9vP9ywNhwcCVn9uZYhtMtnoVY99ke6nSnOYKsVre1wo2fJQ2gXlVy6Kn/osQqy7PyWirVeQ== X-Received: by 2002:a05:600c:4585:b0:477:63dc:be00 with SMTP id 5b1f17b1804b1-4778feaa7f5mr130859165e9.25.1763474262494; Tue, 18 Nov 2025 05:57:42 -0800 (PST) Received: from ?IPV6:2a05:6e02:1041:c10:3006:e9fd:4de4:66f6? ([2a05:6e02:1041:c10:3006:e9fd:4de4:66f6]) by smtp.googlemail.com with ESMTPSA id 5b1f17b1804b1-47787e36ca3sm393988575e9.5.2025.11.18.05.57.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Nov 2025 05:57:42 -0800 (PST) Message-ID: Date: Tue, 18 Nov 2025 14:57:41 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 2/2] iio: adc: Add the NXP SAR ADC support for the s32g2/3 platforms To: Andy Shevchenko Cc: jic23@kernel.org, dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org, robh@kernel.org, conor+dt@kernel.org, krzk+dt@kernel.org, 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, Vinod Koul References: <20251017164238.1908585-1-daniel.lezcano@linaro.org> <20251017164238.1908585-3-daniel.lezcano@linaro.org> <050f96d5-e60c-4b33-b6d2-24fb3925e378@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 Hi Andy, On 10/31/25 13:45, Andy Shevchenko wrote: > On Fri, Oct 31, 2025 at 12:32:03PM +0100, Daniel Lezcano wrote: >> On 10/30/25 10:28, Andy Shevchenko wrote: >>> On Thu, Oct 30, 2025 at 09:27:21AM +0100, Daniel Lezcano wrote: >>>> On 10/18/25 22:12, Andy Shevchenko wrote: >>>>> On Fri, Oct 17, 2025 at 06:42:38PM +0200, Daniel Lezcano wrote: > > [ ... ] > >>>>>> + dma_samples = (u32 *)dma_buf->buf; >>>>> >>>>> Is it aligned properly for this type of casting? >>>> >>>> TBH, I don't know the answer :/ >>>> >>>> How can I check that ? >>> >>> Is buf defined as a pointer to u32 / int or bigger? or is it just byte buffer? >>> If the latter, how does the address of it being formed? Does it come from a heap >>> (memory allocator)? If yes, we are fine, as this is usually the case for all >>> (k)malloc'ed memory. >> >> buf is a byte buffer allocated with dmam_alloc_coherent(..., GFP_KERNEL) > > We are fine :-) > > ... > >>>>>> + dmaengine_tx_status(info->dma_chan, info->cookie, &state); >>>>> >>>>> No return value check? >>>> >>>> The return value is not necessary here because the caller of the callback >>>> will check with dma_submit_error() in case of error which covers the >>>> DMA_ERROR case and the other cases are not useful because the residue is >>>> taken into account right after. >>> >>> In some cases it might return DMA_PAUSE (and actually this is the correct way >>> to get residue, one needs to pause the channel to read it, otherwise it will >>> give outdated / incorrect information). >> >> But if the residue is checked in the callback routine without checking >> DMA_PAUSED, the result is the same no ? > > DMA in some corner cases might have already be charged for the next transfer. > Do you have a synchronisation between DMA start and residue check? > > I.o.w. this may work for your case, but in general it's not guaranteed. The proper > read of residue is to: pause DMA --> read residue --> resume DMA. I discussed with Vinod about this change and he suggested to use the callback_result() to get the residue as a parameter so the dmaengine_txstatus() call won't be needed anymore. Unfortunately, it does not work. I had a look in the DMA driver and the internals but my knowledge is limited in this area so I was unable to find out what is going on. Moreover there are no so many driver using this API I can use as an example. The best I was able to do was propagating the residue to the result in the vchan_complete() but it does not work. Then I stepped back by not using the callback_result() and used dmaengine_pause(), read the residue, dmaengine_resume() but there are no result after these calls. I don't know why. The issue you are mentioning above should be handled in other drivers doing the same kind of acquisition but the routine is similar to the one proposed here (eg. stm32). The NXP SAR acquisition routine is running since several years in production AFAICT. I investigated the different solutions without success, while I can run the acquisition routine without problem here with my hardware. A signal generator captured by the ADC, plotted and compared with the oscilloscope display. The circ buffer is working well here and no bug was spotted with the current routine. I think I did my best to make the driver better from its initial submission. The best is the enemy of the good, and I would like to make some progress here in the driver acceptance. Changing the entire driver for the sake of replacing the circ_buffer by the kfifo and change the code for a scenario which is not happening is not really worth. Especially that the DMA engine is being modified to take into the cyclic DMA in its API, thus the circ_buffer and the routine will go away once the driver is changed to take into account this new API. IOW, can we keep this routine as it is for now as it works fine and go forward for a v6 ? -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog