From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 30B4FC54EBE for ; Fri, 13 Jan 2023 08:05:33 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id E725F59C6; Fri, 13 Jan 2023 09:04:40 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz E725F59C6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1673597131; bh=MpXDrBxOfA/wXLqyW3cVkwQMnJn13SdYEnemaJmt/Zw=; h=Date:From:To:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=KH1F6Ccb9/1OSO3sYvY+zeGbY2QRrx+rhLrfkc7QHX5tO9niXm6rT7ZKJYW+r3IBg 8tRiziQERYTEBLpveztP5bWLxiQnndA3ROFWio6Z+OAGT91bJPTJdNi7IhCMBr3vDU SqdAlmOmv2hHwkj8BEltl/Ch60mZdKcPYz3iDq2o= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 9BDF4F802E8; Fri, 13 Jan 2023 09:04:40 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 6D829F802E8; Fri, 13 Jan 2023 09:04:39 +0100 (CET) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 402AEF8016D for ; Fri, 13 Jan 2023 09:04:36 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 402AEF8016D Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256 header.s=gm1 header.b=Bu0gSlWM Received: (Authenticated sender: herve.codina@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 12EE51C000B; Fri, 13 Jan 2023 08:04:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1673597076; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wvxk6DPDlmeOz1Nn9izcenGUkdQHjs7DPmCAW7HiLUE=; b=Bu0gSlWMgpDnKyBJAhbLPzgDZLvaaTCma7cj46th38QxpH/47+drhybCAiePHomM0aTh83 +PXDsWuxQ0Gze0oSdhbIo31xIIwfPwHPP5kCc5Eb0QcCvts6IrrEX6pBoZYt6mPF/snPmq b/DFsQClZhA1dHPWiT9Y+EoRd/xRmZ/MnZQOI5RFkcDPWvXhg88+HqTLhPB/+Twbf/b5xe ODYI5UOQVKp0rZnJ69vWJMU1zopXB+Olug2gjyfbsBe3POdUeDo+TzsYBLOc7qApp71wsr tGND6/XXAbxN3j8QDXt522WDLId2uUazy6oVdOyihsb9hfF4lAIOzbgsfCRwVw== Date: Fri, 13 Jan 2023 09:04:31 +0100 From: Herve Codina To: Mark Brown Subject: Re: [PATCH 2/3] ASoC: codecs: Add support for the Renesas IDT821034 codec Message-ID: <20230113090431.7f84c93a@bootlin.com> In-Reply-To: References: <20230111134905.248305-1-herve.codina@bootlin.com> <20230111134905.248305-3-herve.codina@bootlin.com> <20230111174022.077f6a8c@bootlin.com> Organization: Bootlin X-Mailer: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org, Thomas Petazzoni , linux-kernel@vger.kernel.org, Linus Walleij , Takashi Iwai , Liam Girdwood , Christophe Leroy , linux-gpio@vger.kernel.org, Rob Herring , Krzysztof Kozlowski , Bartosz Golaszewski Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Hi Mark, On Wed, 11 Jan 2023 17:57:01 +0000 Mark Brown wrote: > On Wed, Jan 11, 2023 at 05:40:22PM +0100, Herve Codina wrote: > > Mark Brown wrote: =20 > > > On Wed, Jan 11, 2023 at 02:49:04PM +0100, Herve Codina wrote: =20 >=20 > > > 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 sho= uld > > > be done. =20 >=20 > > Yes, I use regmap to ease the integration of controls and use the > > already defined controls macros but the device registers do not fit > > well with regmap. =20 >=20 > If this doesn't fit into regmap then don't try to shoehorn it into > regmap, that just makes it incredibly hard to follow what's going on. >=20 > > The device registers are not defined as simple as address/value pairs. > > Accesses contains one or more bytes and the signification of the > > data (and bytes) depends on the first bits. > > - 0b10xxxxxx means 'Control register' with some data as xxxxxx > > and one extra byte > > - 0b1101yyyy means 'Configuration register, slic mode' with > > some other data as yyyy and one extra byte > > - 0b1100zzzz means 'Configuration register, gain mode' with > > some other data as zzzz and two extra bytes =20 >=20 > So really the device only has three registers, each of different sizes > and windowed fields within those registers? I love innovation, > innovation is great and it's good that our hardware design colleagues > work so hard to keep us in jobs. It seems hardly worth it to treat them > as registers TBH. This is so far off a register/value type thing that I > just wouldn't even try. >=20 > > Of course, I can describe all of these in details. > > Where do you want to have this information ? All at the top > > of the file ? Each part (low-level, virtual regs, ...) at > > the beginning of each part in the code ? =20 >=20 > I'm not sure what problem it solves to use regmap or have virtual > registers in the first place. I think you would be better off with > custom _EXT controls, you almost have that anway just hidden in the > middle of the fake register stuff instead of directly there. My sense > is that the result would be much less code. If you are trying to map > things onto registers you probably want comments at every level since > you don't know where people are going to end up jumping into the code. >=20 > Perhaps it's possible to write some new SND_SOC_ helpers that work with > just a value in the device's driver data rather than a regmap and have > a callback to trigger a write to the device? I suspect that'd be > generally useful actually... Well, I wil try to use my own .put() and .get() for snd_controls. For DAPM (struct snd_soc_dapm_widget), no kind of .put() and .get() are available. I will use some Ids for the 'reg' value and use the .write() and .read() hooks available in struct snd_soc_component_driver in order to handle these Ids and so perform the accesses. Do you think this can be the right way (at least for a first try) ? Best regards, Herv=C3=A9 --=20 Herv=C3=A9 Codina, Bootlin Embedded Linux and Kernel engineering https://bootlin.com