From: Mark Brown <broonie@kernel.org>
To: Herve Codina <herve.codina@bootlin.com>
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
linux-kernel@vger.kernel.org,
Linus Walleij <linus.walleij@linaro.org>,
Takashi Iwai <tiwai@suse.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
linux-gpio@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Bartosz Golaszewski <brgl@bgdev.pl>
Subject: Re: [PATCH 2/3] ASoC: codecs: Add support for the Renesas IDT821034 codec
Date: Wed, 11 Jan 2023 14:09:45 +0000 [thread overview]
Message-ID: <Y77DKSdZf27qE+xl@sirena.org.uk> (raw)
In-Reply-To: <20230111134905.248305-3-herve.codina@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]
On Wed, Jan 11, 2023 at 02:49:04PM +0100, Herve Codina wrote:
> +++ b/sound/soc/codecs/idt821034.c
> @@ -0,0 +1,1234 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * IDT821034 ALSA SoC driver
Please make the entire comment a C++ one so things look more
intentional.
> +static int idt821034_8bit_write(struct idt821034 *idt821034, u8 val)
> +{
> + struct spi_transfer xfer[] = {
> + {
> + .tx_buf = &idt821034->spi_tx_buf,
> + .len = 1,
> + }, {
> + .cs_off = 1,
> + .tx_buf = &idt821034->spi_tx_buf,
> + .len = 1,
> + }
> + };
> + int ret;
> +
> + idt821034->spi_tx_buf = val;
> +
> + dev_vdbg(&idt821034->spi->dev, "spi xfer wr 0x%x\n", val);
> +
> + ret = spi_sync_transfer(idt821034->spi, xfer, 2);
Why is this open coding register I/O rather than using regmap?
> + conf = 0x80 | idt821034->cache.codec_conf | IDT821034_CONF_CHANNEL(ch);
regmap provides cache support too.
> +static int idt821034_reg_write_gain(struct idt821034 *idt821034,
> + unsigned int reg, unsigned int val)
> +{
> + u16 gain_val;
> + u8 gain_type;
> + u8 ch;
> +
> + ch = IDT821034_REGMAP_ADDR_GET_CH(reg);
> + gain_type = IDT821034_REGMAP_ADDR_IS_DIR_OUT(reg) ?
> + IDT821034_GAIN_RX : IDT821034_GAIN_TX;
> + gain_val = (val & 0x01) ? 0 : val >> 1;
> +
> + return idt821034_set_gain_channel(idt821034, ch, gain_type, gain_val);
> +}
So if the low bit of the gain is zero we just discard the value? This
really needs some comments...
> +static int idt821034_reg_write(void *context, unsigned int reg, unsigned int val)
> +{
> + struct idt821034 *idt821034 = context;
> +
> + dev_dbg(&idt821034->spi->dev, "reg_write(0x%x, 0x%x)\n", reg, val);
> +
> + switch (IDT821034_REGMAP_ADDR_GET_TYPE(reg)) {
> + case IDT821034_REGMAP_ADDR_TYPE_GBLCONF:
> + return idt821034_reg_write_gblconf(idt821034, reg, val);
> +
Oh, so there is some regmap stuff but it's not actually a regmap and is
instead some virtual thing which rewrites all the values with no
comments or anything explaining what's going on.... this all feels very
confused. I would expect the regmap usage to be such that the regmap
represents the physical device, any rewriting of the values or anything
like that should be done on top of the regmap rather than underneath it.
Without knowing why things are written in this way or what it's trying
to accomplish it's hard to comment in detail on what specifically should
be done.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-01-11 14:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-11 13:49 [PATCH 0/3] Add the Renesas IDT821034 codec support Herve Codina
2023-01-11 13:49 ` [PATCH 1/3] dt-bindings: sound: Add Renesas IDT821034 codec Herve Codina
2023-01-11 16:28 ` Krzysztof Kozlowski
2023-01-11 16:55 ` Herve Codina
2023-01-11 13:49 ` [PATCH 2/3] ASoC: codecs: Add support for the " Herve Codina
2023-01-11 14:09 ` Mark Brown [this message]
2023-01-11 16:40 ` Herve Codina
2023-01-11 17:57 ` Mark Brown
2023-01-13 8:04 ` Herve Codina
2023-01-13 12:59 ` Mark Brown
2023-01-13 14:19 ` Herve Codina
2023-01-11 13:49 ` [PATCH 3/3] MAINTAINERS: add the Renesas IDT821034 codec entry Herve Codina
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=Y77DKSdZf27qE+xl@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=brgl@bgdev.pl \
--cc=christophe.leroy@csgroup.eu \
--cc=devicetree@vger.kernel.org \
--cc=herve.codina@bootlin.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=tiwai@suse.com \
/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