From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) (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 9D4221304AB for ; Thu, 11 Jul 2024 21:31:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720733485; cv=none; b=W1WEBAqDZSqzT26hqWtwKlAxzyakEtsz9RHXFEk42o1wS3gqLWZvTkP/A7zFsmo730E6T3CVkezb8h9DAvF2V5gOzaD/cR8u48WvLJD8BLAg64+8hLoHgS5odPOAlN5lfpB2+Oth0Y8O8tAb2rJbP1rZH47uYE92n2EqGQt5v1o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720733485; c=relaxed/simple; bh=jFC/ch/i8/z5xVvWKDKmHwOHmrjhAbhPZHERWwIZfQI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=XR0F3xlV334EHNFELdd8lQc6XHPGrTuq0lrRE1EDAbP31btBMA5fEWuM15/bQbjF63CWugGEahjUncRdtHcV4mwOOhK5x9hBVHxXUPxmu10wWYqUxRhic4OQY1ox8SUfVi/sAfbk0dbxNU3tZWPR1FJ2SDTQOalZZlxshueOrOs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=YK/tsZmO; arc=none smtp.client-ip=209.85.167.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="YK/tsZmO" Received: by mail-oi1-f176.google.com with SMTP id 5614622812f47-3d9c487b2b5so866746b6e.3 for ; Thu, 11 Jul 2024 14:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1720733483; x=1721338283; 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=SfeKN2QfdZHciO4OVOVkpdd43CD7Qm2bGhXeNljngUw=; b=YK/tsZmO76iCrXYiHHrA+y32F7ZmMZuF8/UZuTosVFxz8STblfzPAh4imVFyrVFO4f fDRHIncSoh9OLUXnvgWPm6MH6RZz8pwXTiWEToNqjIKlSB4CytM3CWlHOVgKVdQXVIp7 B/0X5QMNNWfERunu6Dg0kWQ+PxJPhVMegQOjT2ONyY3dqIWsbDH55blM32qaMlU1Pal5 wwhypADmV86JRrS+u9q+oBHrhXSjIy/lEo7n7z6mUZOgNdfV+bXT39k16a1FrlrYM2kG /2OT2+5hVQEvl9RL1Y1JNmULaNnQ1mmUDMGt4KWhw57oVGTVoPObjG2Ngja21hreL2ER C7Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720733483; x=1721338283; 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=SfeKN2QfdZHciO4OVOVkpdd43CD7Qm2bGhXeNljngUw=; b=V4T38a7WSeCqGPQ3dvhAbPOBm4lN972gD/LksCx2Mmzi4QdQUc0wXgSqnx09tYgsbz KqUIHiWTCqsBd7fnMtTFdSOJ3L4ySjg6+oGNHnnguFoE7P7B8KmxARJpx4QfVIHSlHbn //0B/gjjnFEy2Oj+Hba3PTriL6hpxxszZZxKemgtcicEAuiPXsxFFtZtYYUOZtkgKHB2 mGMPSnKUcDrsHhban0DsTWxBRA4Gfde1kXD0GF5P9se17XUWJeRuTsvpK9cNZ1O+4zGe LPBcQYXH+misP4dZpnROy2yVg63XdQR3cpo2Ui0de3OLdmFUUQTLqwd4pN/XJq2docL5 ExcQ== X-Forwarded-Encrypted: i=1; AJvYcCVq34jteqnfvxut1QdHjttXMt2U+ZjWVGradf2o/xEISyxcHj19goonzc+iknBFGaRdfneqTOqmDvMc7OuhUcpf/dH5C5DSSZ5RrQ== X-Gm-Message-State: AOJu0YxSyspzAMFYB2r1zI3w+kS617uQ0ZcrsCA7FCx53jJyD4gqoURy hp7lciuUod7O4d581nJeC0rQPf1q+JlpTocb+on2MCbg0+G8LMP3ZaV3S+yRi1Y= X-Google-Smtp-Source: AGHT+IFf4egknI9k9MvbDQeAJxrUvsMSH7+SArDvalruHrHw+3gkn8noL4LvJ2u6fMwbjYLblTnOIA== X-Received: by 2002:a05:6808:3d2:b0:3d9:3e48:8b13 with SMTP id 5614622812f47-3d93e48a58emr8438609b6e.10.1720733482672; Thu, 11 Jul 2024 14:31:22 -0700 (PDT) Received: from [192.168.0.142] (ip98-183-112-25.ok.ok.cox.net. [98.183.112.25]) by smtp.gmail.com with ESMTPSA id 5614622812f47-3d93ad2447dsm1180928b6e.25.2024.07.11.14.31.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jul 2024 14:31:22 -0700 (PDT) Message-ID: <733f4f7b-53b2-46c1-8bf8-5ed357adab30@baylibre.com> Date: Thu, 11 Jul 2024 16:31:21 -0500 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 2/2] iio: dac: support the ad8460 Waveform DAC To: =?UTF-8?Q?Nuno_S=C3=A1?= , Jonathan Cameron , "Tinaco, Mariel" Cc: Jonathan Cameron , "linux-iio@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Lars-Peter Clausen , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Liam Girdwood , Mark Brown , "Hennerich, Michael" , Marcelo Schmitt , Dimitri Fedrau , Guenter Roeck , Nuno Sa References: <20240510064053.278257-1-Mariel.Tinaco@analog.com> <20240510064053.278257-3-Mariel.Tinaco@analog.com> <20240511174405.10d7fce8@jic23-huawei> <20240628194546.2f608365@jic23-huawei> <20240708170504.00006c9d@Huawei.com> Content-Language: en-US From: David Lechner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 7/11/24 4:20 AM, Nuno Sá wrote: > On Mon, 2024-07-08 at 17:05 +0100, Jonathan Cameron wrote: >> On Mon, 8 Jul 2024 05:17:55 +0000 >> "Tinaco, Mariel" wrote: >> >>>> -----Original Message----- >>>> From: Jonathan Cameron >>>> Sent: Saturday, June 29, 2024 2:46 AM >>>> To: Tinaco, Mariel >>>> Cc: linux-iio@vger.kernel.org; devicetree@vger.kernel.org; linux- >>>> kernel@vger.kernel.org; Lars-Peter Clausen ; Rob Herring >>>> ; Krzysztof Kozlowski ; Conor Dooley >>>> ; Liam Girdwood ; Mark Brown >>>> ; Hennerich, Michael ; >>>> Marcelo Schmitt ; Dimitri Fedrau >>>> ; Guenter Roeck >>>> Subject: Re: [PATCH 2/2] iio: dac: support the ad8460 Waveform DAC >>>> >>>> [External] >>>>   >>>>>>> +}; >>>>>>> + >>>>>>> +static int ad8460_get_powerdown_mode(struct iio_dev *indio_dev, >>>>>>> +      const struct iio_chan_spec *chan) { >>>>>>> + return 0;  >>>>>> >>>>>> Why have the stubs in here?  >>>>> >>>>> Should I move the stubs to a different place in the code or remove >>>>> them altogether since there is only a single powerdown mode available  >>>> Ah. I'd not really understood what was going on here.  This is fine as is. >>>>   >>>>>> AD8460_HVDAC_DATA_WORD_HIGH(index),  >>>>>>> +     ((val >> 8) & 0xFF));  >>>>>> >>>>>> bulk write? or do these need to be ordered?  >>>>> >>>>> For this I used bulk read/write this way. >>>>> >>>>> static int ad8460_set_hvdac_word(struct ad8460_state *state, >>>>> int index, >>>>> int val) >>>>> { >>>>> u8 regvals[AD8460_DATA_BYTE_WORD_LENGTH];  >>>> regmap bulk accesses (when spi anyway) should be provided with DMA safe >>>> buffers. >>>> Easiest way to do that is add one with __aligned(IIO_DMA_MINALIGN) to the >>>> end of the ad8460_state structure.  Possibly you'll need a lock to protect it - >>>> I >>>> haven't checked.  >>>>> >>>>> regvals[0] = val & 0xFF; >>>>> regvals[1] = (val >> 8) & 0xFF;  >>>> >>>> That is an endian conversion so use appropriate endian function to fill it >>>> efficiently and document clearly what is going on. >>>> >>>> >>>> put_unaligned_le16() >>>>   >>>>> >>>>> return regmap_bulk_write(state->regmap,  >>>> AD8460_HVDAC_DATA_WORD_LOW(index),  >>>>> regvals,  >>>> AD8460_DATA_BYTE_WORD_LENGTH); }  >>>>> >>>>>   >>>>>>> +}  >>>>   >>>>>>> + state->regmap = devm_regmap_init_spi(spi, >>>>>>> &ad8460_regmap_config); >>>>>>> + if (IS_ERR(state->regmap)) >>>>>>> + return dev_err_probe(&spi->dev, PTR_ERR(state->regmap), >>>>>>> +      "Failed to initialize regmap"); >>>>>>> + >>>>>>> + ret = devm_iio_dmaengine_buffer_setup_ext(&spi->dev, indio_dev, >>>>>>> +"tx", >>>>>>> +  >>>>>> IIO_BUFFER_DIRECTION_OUT); >>>>>> >>>>>> Ah. I take back my binding comment. I assume this is mapping some >>>>>> non standard interface for the parallel data flow?  >>>>> >>>>> Yes, the HDL side doesn't follow yet the standard IIO backend from >>>>> which this driver was tested  >>>> >>>> Hmm. I'd like to see this brought inline with the other iio backend drivers if >>>> possible.  >>> >>> Does this mean that we would need to implement an AXI IP core on the >>> FPGA side to be able to test this? >> >> Don't think so.  That framework is meant to support any equivalent IP. >> So whatever you have should be supportable. Maybe it's somewhat of a stub >> driver though if there isn't anything controllable. >> >> It's Nuno's area of expertise though +CC. >> > > Hi Jonathan, > > Yeah, I did reply David (IIRC) about the very same question. In the design/HW Mariel > is working on the DAC is directly connected to the DMA core which is handled already > by a proper dma controller driver. So in this case I'm really not seeing the backend > need right now (maybe in the future we may have another design for this device that > could justify for a backend device but no idea on that). > > As you mention, we could very well do a stub platform driver so we can use the > backend framework (like dma-backend or something) that could pretty much be a stub > for the DMA controller. But is it worth it though? We'd actually be "lying" in terms > of HW description as the DMA is a property of the actual converter. > > - Nuno Sá > > I'm a bit inclined to agree with Jonathan here. I could see someone in the future, wanting to, e.g., use DMA + a GPIO controller for the parallel interface if they didn't have an FPGA. So it seems a bit more future-proof to just always use the IIO backend framework for the parallel interface. FWIW, I don't think it would be "lying" since the io-backend DT node would be representing physical parallel bus between the DMA controller and the ADC chip. But if DT maintainers are OK with the idea that a DMA channel can be directly wired to an external chip, I guess I won't complain. :-)