[RFC PATCH 1/2] ASoC: soc-component: add snd_soc_component_read/write_field()
Mark Brown
broonie at kernel.org
Tue Jan 26 14:36:12 CET 2021
On Tue, Jan 26, 2021 at 12:20:19PM +0000, Srinivas Kandagatla wrote:
> +#define __soc_component_field_shift(x) (__builtin_ffs(x) - 1)
Why not have this be a static inline?
> +unsigned int snd_soc_component_read_field(struct snd_soc_component *component,
> + unsigned int reg, unsigned int mask)
> +{
> + unsigned int val;
> +
> + mutex_lock(&component->io_mutex);
> + val = soc_component_read_no_lock(component, reg);
> + if (mask)
> + val = (val & mask) >> __soc_component_field_shift(mask);
I don't understand why this is open coding the locking when it's just a
simple read and then shift?
> + mutex_lock(&component->io_mutex);
> +
> + old = soc_component_read_no_lock(component, reg);
> +
> + val = val << __soc_component_field_shift(mask);
> +
> + new = (old & ~mask) | (val & mask);
> +
> + change = old != new;
> + if (change)
> + ret = soc_component_write_no_lock(component, reg, new);
> +
> + mutex_unlock(&component->io_mutex);
This needs the lock as it's a read/modify/write but could also be
implemented in terms of the existing update_bits() operation rather than
open coding it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20210126/8ff8c850/attachment-0001.sig>
More information about the Alsa-devel
mailing list