summaryrefslogtreecommitdiff
path: root/sound/soc/sdca/sdca_regmap.c
AgeCommit message (Collapse)Author
11 daysASoC: SDCA: Add support for -cn- value propertiesCharles Keepax
Many of the DisCo properties that specify Control values have an additional variant that specifies a separate value for each Control Number. Add support for these. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250718135432.1048566-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
11 daysASoC: SDCA: Fix some holes in the regmap readable/writeable helpersCharles Keepax
The current regmap readable/writeable helper functions always allow the Next flag and allows any Control Number. Mask the Next flag based on SDCA_ACCESS_MODE_DUAL which is the only Mode that supports it. Also check that the Control Number is valid for the given control. Fixes: e3f7caf74b79 ("ASoC: SDCA: Add generic regmap SDCA helpers") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250718135432.1048566-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-20ASoC: SDCA: Remove regmap module macrosCharles Keepax
There is no need to include MODULE_LICENSE() and MODULE_DESCRIPTION() in sdca_regmap.c as this file is part of a larger module that already defines these. Fixes: e3f7caf74b79 ("ASoC: SDCA: Add generic regmap SDCA helpers") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20250516131011.221310-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-02-27ASoC: SDCA: Add helper to write out defaults and fixed valuesCharles Keepax
The concept of an SDCA default value differs slightly from the regmap usage of the term. An SDCA default is a value that is parsed from DisCo and then written out to the hardware if no user value has superceded it. Add a helper function that will iterate through all the SDCA Controls and write out any default values. After these have been written out once they will exist in the cache and that will take care of any user values superceeding them. The code here also writes out any Controls with a fixed value as there is only one available value for these Controls there is no point in allowing the user to select them, simply treat them similarly to a default. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20250217140159.2288784-5-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-02-27ASoC: SDCA: Add regmap helpers for parsing for DisCo Constant valuesCharles Keepax
Add helpers to parse the DisCo Constant values from ACPI and populate an array of reg_defaults with these. This will allow drivers to access these ACPI specified values through the same interface as other registers that are physically present on the device, using the regmap cache. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20250217140159.2288784-4-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-02-27ASoC: SDCA: Add generic regmap SDCA helpersCharles Keepax
Add helper functions that SDCA drivers can use to calculate the properties of SDCA Controls (registers) specified through DisCo. Most of these are fairly obvious from the SDCA Access Modes. DisCo Constants, values which are specified in the ACPI rather than on the device, are handled as unreadable and unwritable registers. The intention is these will be populated in the register defaults table allowing drivers to read them normally. This means the drivers can be agnostic as to which values are DisCo Constants. Finally, support for SDCA Dual Ranked Controls is currently limited here, at the moment the current value will be used directly. Writing the current value directly is valid as per the specification although the synchronicity of updates across multiple registers is lost. Support for this will probably need to be added later. But its a fairly hard problem and doesn't need to be solved immediately. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20250217140159.2288784-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>