[alsa-devel] [PATCH] ASoC: topology: Add support for TLV bytes control

[Mark Brown]

On Wed, Aug 12, 2015 at 10:10:51AM +0800, mengdong.lin at intel.com wrote:

> Allow vendor drivers to define bespoke bytes ext handlers and IDs for
> TLV bytes controls. And the topology core will bind these handlers by
> matching IDs defined by the vendor driver and user space topology
> data file.

> @@ -513,6 +517,15 @@ static int soc_tplg_kcontrol_bind_io(struct snd_soc_tplg_ctl_hdr *hdr,
>  {
>  	int i;
>  
> +	/* TLV bytes controls don't need get/put ops */

AFAICT it's actually the case that we're binding them later rather than
that the ops aren't needed.  Isn't that what soc_tplg_bytes_ext_bind_io()
does?

> +	if (k->iface & SNDRV_CTL_ELEM_IFACE_MIXER
> +		&& k->access & SNDRV_CTL_ELEM_ACCESS_TLV_READWRITE
> +		&& k->access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK
> +		&& hdr->ops.info == SND_SOC_TPLG_CTL_BYTES) {
> +			k->info = snd_soc_bytes_info_ext;
> +			return 0;
> +	}
> +

I'm confused.  What's special about TLV controls compared to other
controls, why are the existing bespoke handlers which get bound in this
function not sufficient and why don't we bind the TLV bespoke handlers
here?

Having two different classes of bespoke handlers like this both called
bespoke handlers seems like it's going to lead to problems - either
bringing the interfaces closer together or naming them in a way that
clarifies their meaning seems better.  Instead of just calling them
"bespoke handlers" we should probably just call them handlers for
whatever kind of control they're for and probably bind them first rather
than second so we're doing more specific to less specific handling.
That way drivers can also have specific handling for things the topology
data didn't anticipate they'd need it for which seems like it might come
in handy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150814/6d9d509c/attachment.sig>