From: David Lechner <dlechner@baylibre.com>
To: Angelo Dureghello <adureghello@baylibre.com>,
Jonathan Cameron <jic23@kernel.org>
Cc: "Lars-Peter Clausen" <lars@metafoo.de>,
"Michael Hennerich" <Michael.Hennerich@analog.com>,
"Nuno Sá" <nuno.sa@analog.com>, "Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Olivier Moysan" <olivier.moysan@foss.st.com>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/8] iio: dac: introducing ad3552r-axi
Date: Tue, 3 Sep 2024 11:17:24 -0500 [thread overview]
Message-ID: <4a62ea7b-a8af-49e0-9718-30d927a69038@baylibre.com> (raw)
In-Reply-To: <74e0b200-d4c0-4aa3-9ee6-f49ac3f1467d@baylibre.com>
On 9/3/24 3:34 AM, Angelo Dureghello wrote:
> Hi Jonathan and all,
>
>
> On 31/08/24 1:38 PM, Jonathan Cameron wrote:
>> On Thu, 29 Aug 2024 14:31:58 +0200
>> Angelo Dureghello <adureghello@baylibre.com> wrote:
>>
>>> Hi, asking for comments for this patchset, that is mostly
>>> ready, at least feature-complete and functionally tested.
>>>
>>> I am introducing ad3552r-axi variant, controlled from a fpga-based
>>> AXI IP, as a platform driver, using the DAC backend. The patchset is
>>> actually based on linux-iio, since some needed DAC backend features
>>> was already there on that repo only, still to be merged in mainline.
>>>
>>> Comments i would like to ask are:
>>>
>>> - i added some devicetree bindings inside current ad3552r yaml,
>>> device is the same, so i wouldn't create a different yaml file.
>> Agreed. If same device, it's usually better to keep it in one file.
>>
>>> - if it's ok adding the bus-type property in the DAC backend:
>>> actually, this platform driver uses a 4 lanes parallel bus, plus
>>> a clock line, similar to a qspi. This to read an write registers
>>> and as well to send samples at double data rate. Other DAC may
>>> need "parallel" or "lvds" in the future.
>> If it is for register read + write as well, sounds to me like you need
>> to treat this as a new bus type, possibly then combined with a
>> backend, or something similar to spi offload?
>>
>> What bus does this currently sit on in your DT bindings?
>> (add an example)
>
>
> &amba {
>
> ref_clk: clk@44B00000 {
> compatible = "adi,axi-clkgen-2.00.a";
> reg = <0x44B00000 0x10000>;
> #clock-cells = <0>;
> clocks = <&clkc 15>, <&clkc 15>;
> clock-names = "s_axi_aclk", "clkin1";
> clock-output-names = "ref_clk";
> };
>
> dac_tx_dma: dma-controller@0x44a30000 {
> compatible = "adi,axi-dmac-1.00.a";
> reg = <0x44a30000 0x10000>;
> #dma-cells = <1>;
> interrupt-parent = <&intc>;
> interrupts = <0 57 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clkc 15>;
>
> adi,channels {
> #size-cells = <0>;
> #address-cells = <1>;
>
> dma-channel@0 {
> reg = <0>;
> adi,source-bus-width = <32>;
> adi,source-bus-type = <0>;
> adi,destination-bus-width = <32>;
> adi,destination-bus-type = <1>;
> };
> };
> };
>
> backend: controller@44a70000 {
> compatible = "adi,axi-dac-9.1.b";
> reg = <0x44a70000 0x1000>;
> dmas = <&dac_tx_dma 0>;
> dma-names = "tx";
> #io-backend-cells = <0>;
> clocks = <&ref_clk>;
> bus-type = <1>; /* IIO QSPI */
> };
>
> axi-ad3552r {
> compatible = "adi,ad3552r";
> reset-gpios = <&gpio0 92 GPIO_ACTIVE_LOW>;
> io-backends = <&backend>;
> #address-cells = <1>;
> #size-cells = <0>;
> channel@0 {
> reg = <0>;
> adi,output-range-microvolt = <(-10000000) (10000000)>;
> };
> };
Shouldn't the axi-ad3552r node be one level higher since it isn't
a memory-mapped device, but rather an external chip?
But based on the other feedback we got in this series and some
#devicetree IRC chat here is an alternate binding suggestion we
could consider.
First, even though the FPGA IP block for use with AD3225R uses
the same register map as the AXI DAC IP block, some of the
registers behave differently, so it makes sense to have a
different compatible string rather than using the bus-type
property to tell the difference between the two IP blocks.
There are likely more differences than just the bus type.
Second, technically, the AXI DAC IP block can't be used as
a generic SPI controller, so it wouldn't make sense to put
it in drivers/spi. But, from wiring point of view, it could
still make sense to use SPI DT bindings since we have SPI
wiring. At the same time, the AXI DAC IP block is also
providing extra functionality in addition to the SPI bus
so it makes sense to keep the io-backend bindings for those
extra bits.
backend: spi@44a70000 {
compatible = "adi,axi-dac-ad3225r";
reg = <0x44a70000 0x1000>;
dmas = <&dac_tx_dma 0>;
dma-names = "tx";
#io-backend-cells = <0>;
clocks = <&ref_clk>;
#address-cells = <1>;
#size-cells = <0>;
dac@0 {
compatible = "adi,ad3552r";
reg = <0>;
/*
* Not sure how right this is - attempting to say that
* the QSPI select pin is hardwired high, so the 4 SPI I/O
* pins on the DAC are always functioning as SDIO0/1/2/3
* as opposed to the usual 2 SDI/SDO pins and 2 unused.
*/
spi-3-wire;
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>;
reset-gpios = <&gpio0 92 GPIO_ACTIVE_LOW>;
io-backends = <&backend>;
#address-cells = <1>;
#size-cells = <0>;
channel@0 {
reg = <0>;
adi,output-range-microvolt = <(-10000000) (10000000)>;
};
};
};
next prev parent reply other threads:[~2024-09-03 16:17 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-29 12:31 Angelo Dureghello
2024-08-29 12:31 ` [PATCH RFC 1/8] dt-bindings: iio: dac: ad3552r: add io-backend property Angelo Dureghello
2024-08-29 12:32 ` [PATCH RFC 2/8] iio: backend: extend features Angelo Dureghello
2024-08-31 11:23 ` Jonathan Cameron
2024-09-02 14:03 ` Angelo Dureghello
2024-09-03 19:11 ` Jonathan Cameron
2024-09-04 12:01 ` Angelo Dureghello
2024-09-05 10:28 ` Nuno Sá
2024-09-07 14:02 ` Jonathan Cameron
2024-08-29 12:32 ` [PATCH RFC 3/8] iio: backend adi-axi-dac: backend features Angelo Dureghello
2024-08-31 11:34 ` Jonathan Cameron
2024-09-02 16:04 ` Angelo Dureghello
2024-09-03 19:16 ` Jonathan Cameron
2024-09-05 10:49 ` Nuno Sá
2024-09-05 11:58 ` Angelo Dureghello
2024-09-06 5:54 ` Nuno Sá
2024-09-05 12:11 ` Angelo Dureghello
2024-09-06 5:53 ` Nuno Sá
2024-08-29 12:32 ` [PATCH RFC 4/8] dt-bindings: iio: dac: add adi axi-dac bus property Angelo Dureghello
2024-08-29 13:39 ` Rob Herring (Arm)
2024-08-29 15:46 ` Conor Dooley
2024-08-30 8:16 ` Krzysztof Kozlowski
2024-08-30 15:06 ` Conor Dooley
2024-08-30 8:19 ` Angelo Dureghello
2024-08-30 15:33 ` Conor Dooley
2024-09-02 9:32 ` Angelo Dureghello
2024-09-03 19:18 ` Jonathan Cameron
2024-09-06 9:04 ` Conor Dooley
2024-09-06 11:32 ` Nuno Sá
2024-09-07 8:53 ` Angelo Dureghello
2024-09-09 12:17 ` Conor Dooley
2024-09-05 9:50 ` Nuno Sá
2024-09-06 8:50 ` Conor Dooley
2024-09-06 8:55 ` Conor Dooley
2024-09-06 11:28 ` Nuno Sá
2024-08-29 12:32 ` [PATCH RFC 5/8] iio: dac: ad3552r: changes to use FIELD_PREP Angelo Dureghello
2024-08-31 11:48 ` Jonathan Cameron
2024-09-02 16:15 ` Angelo Dureghello
2024-09-03 19:19 ` Jonathan Cameron
2024-08-29 12:32 ` [PATCH RFC 6/8] iio: dac: ad3552r: extract common code (no changes in behavior intended) Angelo Dureghello
2024-08-29 12:32 ` [PATCH RFC 7/8] iio: dac: ad3552r: add axi platform driver Angelo Dureghello
2024-08-31 12:13 ` Jonathan Cameron
2024-09-03 8:17 ` Angelo Dureghello
2024-09-03 19:28 ` Jonathan Cameron
2024-08-29 12:32 ` [PATCH RFC 8/8] iio: ABI: add DAC sysfs synchronous_mode parameter Angelo Dureghello
2024-08-31 12:15 ` Jonathan Cameron
2024-08-31 11:38 ` [RFC PATCH 0/8] iio: dac: introducing ad3552r-axi Jonathan Cameron
2024-09-03 8:34 ` Angelo Dureghello
2024-09-03 16:17 ` David Lechner [this message]
2024-09-03 19:39 ` Jonathan Cameron
2024-09-05 9:16 ` Nuno Sá
2024-09-07 14:12 ` Jonathan Cameron
2024-09-09 7:37 ` Nuno Sá
2024-09-09 18:59 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4a62ea7b-a8af-49e0-9718-30d927a69038@baylibre.com \
--to=dlechner@baylibre.com \
--cc=Michael.Hennerich@analog.com \
--cc=adureghello@baylibre.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=olivier.moysan@foss.st.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®