From: Jonathan Cameron <jic23@kernel.org>
To: Angelo Dureghello <adureghello@baylibre.com>
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, dlechner@baylibre.com
Subject: Re: [PATCH RFC 3/8] iio: backend adi-axi-dac: backend features
Date: Sat, 31 Aug 2024 12:34:18 +0100 [thread overview]
Message-ID: <20240831123418.6bef6039@jic23-huawei> (raw)
In-Reply-To: <20240829-wip-bl-ad3552r-axi-v0-v1-3-b6da6015327a@baylibre.com>
On Thu, 29 Aug 2024 14:32:01 +0200
Angelo Dureghello <adureghello@baylibre.com> wrote:
> From: Angelo Dureghello <adureghello@baylibre.com>
>
> Extend DAC backend with new features required for the AXI driver
> version for the a3552r DAC.
>
> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Hi Angelo
Minor comments inline.
>
> static int axi_dac_enable(struct iio_backend *back)
> @@ -460,7 +493,13 @@ static int axi_dac_data_source_set(struct iio_backend *back, unsigned int chan,
> case IIO_BACKEND_EXTERNAL:
> return regmap_update_bits(st->regmap,
> AXI_DAC_REG_CHAN_CNTRL_7(chan),
> - AXI_DAC_DATA_SEL, AXI_DAC_DATA_DMA);
> + AXI_DAC_DATA_SEL,
> + AXI_DAC_DATA_DMA);
Unrelated change. If you want to change this, separate patch.
> + case IIO_BACKEND_INTERNAL_RAMP_16:
> + return regmap_update_bits(st->regmap,
> + AXI_DAC_REG_CHAN_CNTRL_7(chan),
> + AXI_DAC_DATA_SEL,
> + AXI_DAC_DATA_INTERNAL_RAMP_16);
> default:
> return -EINVAL;
> }
> @@ -518,9 +557,204 @@ static int axi_dac_reg_access(struct iio_backend *back, unsigned int reg,
> return regmap_write(st->regmap, reg, writeval);
> }
>
> +
> +static int axi_dac_bus_reg_write(struct iio_backend *back,
> + u32 reg, void *val, size_t size)
Maybe just pass an unsigned int for val?
So follow what regmap does? You will still need the size, but it
will just be configuration related rather than affecting the type
of val.
> +{
> + struct axi_dac_state *st = iio_backend_get_priv(back);
> +
> + if (!st->bus_type)
> + return -EOPNOTSUPP;
> +
> + if (st->bus_type == AXI_DAC_BUS_TYPE_QSPI) {
As below, I'd use a switch and factor out this block as a separate
bus specific function.
> + int ret;
> + u32 ival;
> +
> + if (size != 1 && size != 2)
> + return -EINVAL;
> +
> + switch (size) {
> + case 1:
> + ival = FIELD_PREP(AXI_DAC_DATA_WR_8, *(u8 *)val);
> + break;
> + case 2:
> + ival = FIELD_PREP(AXI_DAC_DATA_WR_16, *(u16 *)val);
> + break;
> + default:
> + return -EINVAL;
Hopefully compiler won't need this and the above. I'd drop the size != 1..
check in favour of just doing it in this switch.
> + }
> +
> + ret = regmap_write(st->regmap, AXI_DAC_CNTRL_DATA_WR, ival);
> + if (ret)
> + return ret;
> +
> + /*
> + * Both REG_CNTRL_2 and AXI_DAC_CNTRL_DATA_WR need to know
> + * the data size. So keeping data size control here only,
> + * since data size is mandatory for to the current transfer.
> + * DDR state handled separately by specific backend calls,
> + * generally all raw register writes are SDR.
> + */
> + if (size == 1)
> + ret = regmap_set_bits(st->regmap, AXI_DAC_REG_CNTRL_2,
> + AXI_DAC_SYMB_8B);
> + else
> + ret = regmap_clear_bits(st->regmap, AXI_DAC_REG_CNTRL_2,
> + AXI_DAC_SYMB_8B);
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(st->regmap, AXI_DAC_REG_CUSTOM_CTRL,
> + AXI_DAC_ADDRESS,
> + FIELD_PREP(AXI_DAC_ADDRESS, reg));
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(st->regmap, AXI_DAC_REG_CUSTOM_CTRL,
> + AXI_DAC_TRANSFER_DATA,
> + AXI_DAC_TRANSFER_DATA);
> + if (ret)
> + return ret;
> +
> + ret = regmap_read_poll_timeout(st->regmap,
> + AXI_DAC_REG_CUSTOM_CTRL, ival,
> + ival & AXI_DAC_TRANSFER_DATA,
> + 10, 100 * KILO);
> + if (ret)
> + return ret;
> +
> + return regmap_clear_bits(st->regmap, AXI_DAC_REG_CUSTOM_CTRL,
> + AXI_DAC_TRANSFER_DATA);
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int axi_dac_bus_reg_read(struct iio_backend *back,
> + u32 reg, void *val, size_t size)
As for write, I'd just use an unsigned int * for val like
regmap does.
> +{
> + struct axi_dac_state *st = iio_backend_get_priv(back);
> +
> + if (!st->bus_type)
> + return -EOPNOTSUPP;
> +
> + if (st->bus_type == AXI_DAC_BUS_TYPE_QSPI) {
It got mentioned in binding review but if this isn't QSPI, even
if similar don't call it that.
Maybe use a switch from the start give it will make sense
anyway the moment there is a second bus type.
I'd be tempted to factor the rest of this block out.
I guess expectation is we'll see more bus types so that factoring
out will be needed soon anyway.
> + int ret;
> + u32 bval;
u32 bval = 0;
> +
> + if (size != 1 && size != 2)
> + return -EINVAL;
> +
> + bval = 0;
> + ret = axi_dac_bus_reg_write(back,
> + AXI_DAC_RD_ADDR(reg), &bval, size);
Ugly wrap. Move more stuff on to first line.
> + if (ret)
> + return ret;
> +
> + ret = regmap_read_poll_timeout(st->regmap, AXI_DAC_UI_STATUS,
> + bval, bval != AXI_DAC_BUSY,
> + 10, 100);
> + if (ret)
> + return ret;
> +
> + return regmap_read(st->regmap, AXI_DAC_CNTRL_DATA_RD, val);
> + }
> +
> + return -EINVAL;
> +}
next prev parent reply other threads:[~2024-08-31 11:34 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-29 12:31 [RFC PATCH 0/8] iio: dac: introducing ad3552r-axi 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 [this message]
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
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=20240831123418.6bef6039@jic23-huawei \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=adureghello@baylibre.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--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