From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: alsa-devel@alsa-project.org, broonie@linaro.org,
Takashi Iwai <tiwai@suse.de>,
Clemens Ladisch <clemens@ladisch.de>,
omair.m.abdullah@intel.com, Vinod Koul <vinod.koul@intel.com>
Subject: Re: [PATCH 1/4] ALSA: control: return payload length for TLV operation
Date: Sat, 3 Sep 2016 12:32:13 +0100 [thread overview]
Message-ID: <20160903113213.GG21682@localhost.localdomain> (raw)
In-Reply-To: <a21ab28c-12d5-41c2-9209-4127fe3ca79a@sakamocchi.jp>
On Fri, Sep 02, 2016 at 08:18:04PM +0900, Takashi Sakamoto wrote:
> Clemens,
>
> On Aug 31 2016 20:54, Clemens Ladisch wrote:
> > Takashi Iwai wrote:
> >> TLV has never been and (will never be) an API to handle a
> >> generic binary stream.
> >
> > It would be possible to define something like SNDRV_CTL_TLVT_HWDEP_BLOB
> > or _COEFFICIENTS, or to reserve a range of TLVT values for driver-
> > defined types. (But we cannot change soc-wm-adsp to support only proper
> > TLV data, because this would introduce a regression.)
>
> For our information, I wrote a patch including your idea.
>
>
> Thanks for your bright comment ;)
>
> Takashi Sakamoto
>
> ---- 8< ----
>
> >From d1a0eabf1b33fae5de7cedf7aee23778f5dcf46c Mon Sep 17 00:00:00 2001
> From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
> Date: Fri, 2 Sep 2016 00:12:20 +0900
> Subject: [PATCH] ALSA: control: coefficient support
>
> ---
> include/uapi/sound/asound.h | 5 +++++
> include/uapi/sound/tlv.h | 1 +
> sound/soc/codecs/wm_adsp.c | 3 ++-
> sound/soc/soc-ops.c | 37 ++++++++++++++++++++++++++++++++++---
> sound/soc/soc-topology.c | 3 ++-
> 5 files changed, 44 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
> index 609cadb..69c0585 100644
> --- a/include/uapi/sound/asound.h
> +++ b/include/uapi/sound/asound.h
> @@ -848,6 +848,11 @@ typedef int __bitwise snd_ctl_elem_iface_t;
> #define SNDRV_CTL_ELEM_ACCESS_TLV_WRITE (1<<5) /* TLV write is possible */
> #define SNDRV_CTL_ELEM_ACCESS_TLV_READWRITE
> (SNDRV_CTL_ELEM_ACCESS_TLV_READ|SNDRV_CTL_ELEM_ACCESS_TLV_WRITE)
> #define SNDRV_CTL_ELEM_ACCESS_TLV_COMMAND (1<<6) /* TLV command is
> possible */
> +/*
> + * Arbitrary data is accepted for coefficients, instead of pure
> threshold level
> + * information.
> + */
> +#define SNDRV_CTL_ELEM_ACCESS_TLV_COEFF (1<<7)
Yeah the addition of a new flag here would very much get my vote.
The only way at the moment to tell if you are dealing with this
type of control from user-space is to look for
a control of type SNDRV_CTL_ELEM_TYPE_BYTES that doesn't have
SNDRV_CTL_ELEM_ACCESS_READ or SNDRV_CTL_ELEM_ACCESS_WRITE. Which
is far from ideal.
> #define SNDRV_CTL_ELEM_ACCESS_INACTIVE (1<<8) /* control does actually
> nothing, but may be updated */
> #define SNDRV_CTL_ELEM_ACCESS_LOCK (1<<9) /* write lock */
> #define SNDRV_CTL_ELEM_ACCESS_OWNER (1<<10) /* write lock owner */
> diff --git a/include/uapi/sound/tlv.h b/include/uapi/sound/tlv.h
> index ffc4f20..fd1c867 100644
> --- a/include/uapi/sound/tlv.h
> +++ b/include/uapi/sound/tlv.h
> @@ -19,6 +19,7 @@
> #define SNDRV_CTL_TLVT_DB_RANGE 3 /* dB range container */
> #define SNDRV_CTL_TLVT_DB_MINMAX 4 /* dB scale with min/max */
> #define SNDRV_CTL_TLVT_DB_MINMAX_MUTE 5 /* dB scale with min/max with
> mute */
> +#define SNDRV_CTL_TLVT_COEFF 6 /* Arbitrary data */
>
> /*
> * channel-mapping TLV items
> diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c
> index 21fbe7d..525d70b 100644
> --- a/sound/soc/codecs/wm_adsp.c
> +++ b/sound/soc/codecs/wm_adsp.c
> @@ -930,7 +930,8 @@ static unsigned int wmfw_convert_flags(unsigned int
> in, unsigned int len)
> wr = SNDRV_CTL_ELEM_ACCESS_TLV_WRITE;
> vol = SNDRV_CTL_ELEM_ACCESS_VOLATILE;
>
> - out = SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK;
> + out = SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK |
> + SNDRV_CTL_ELEM_ACCESS_TLV_COEFF;
> } else {
> rd = SNDRV_CTL_ELEM_ACCESS_READ;
> wr = SNDRV_CTL_ELEM_ACCESS_WRITE;
> diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c
> index a513a34..14cdd59 100644
> --- a/sound/soc/soc-ops.c
> +++ b/sound/soc/soc-ops.c
> @@ -31,6 +31,7 @@
> #include <sound/soc.h>
> #include <sound/soc-dpcm.h>
> #include <sound/initval.h>
> +#include <sound/tlv.h>
>
> /**
> * snd_soc_info_enum_double - enumerated double mixer info callback
> @@ -773,19 +774,49 @@ int snd_soc_bytes_tlv_callback(struct snd_kcontrol
> *kcontrol, int op_flag,
> unsigned int size, unsigned int __user *tlv)
> {
> struct soc_bytes_ext *params = (void *)kcontrol->private_value;
> - unsigned int count = size < params->max ? size : params->max;
> + unsigned int count;
> + unsigned int type;
> int ret = -ENXIO;
>
> + /*
> + * The TLV packet can transfer numerical ID for one control element.
> + * But ALSA control core don't tell it to each implementation of
> + * TLV callback. Here, instead, use the first volatile data to
> + * check access information.
> + */
> + if (!(kcontrol->vd[0].access & SNDRV_CTL_ELEM_ACCESS_TLV_COEFF))
> + return -ENXIO;
> +
> + /* The data should be constructed according to TLV protocol. */
> + if (copy_from_user(&type, tlv, sizeof(unsigned int)))
> + return -EFAULT;
> +
> + /* The type should be an arbitrary data. */
> + if (type != SNDRV_CTL_TLVT_COEFF)
> + return -ENXIO;
> +
I agree it is probably a bit late to add this now.
Thanks,
Charles
next prev parent reply other threads:[~2016-09-03 11:32 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-29 23:44 [RFC][PATCH 0/4] ALSA: control: return payload length of TLV operation Takashi Sakamoto
2016-08-29 23:44 ` [PATCH 1/4] ALSA: control: return payload length for " Takashi Sakamoto
2016-08-30 5:29 ` Takashi Iwai
2016-08-30 6:19 ` Takashi Sakamoto
2016-08-30 6:59 ` Takashi Iwai
2016-08-30 7:13 ` Takashi Sakamoto
2016-08-30 7:39 ` Takashi Iwai
2016-08-30 7:05 ` Clemens Ladisch
2016-08-30 7:09 ` Takashi Sakamoto
2016-08-30 8:04 ` Clemens Ladisch
2016-08-30 12:22 ` Takashi Sakamoto
2016-08-30 14:51 ` Vinod Koul
2016-08-30 22:04 ` Takashi Sakamoto
2016-08-31 4:20 ` Vinod Koul
2016-08-31 4:30 ` Takashi Sakamoto
2016-08-31 9:05 ` Charles Keepax
2016-08-31 9:40 ` Takashi Iwai
2016-08-31 11:54 ` Clemens Ladisch
2016-08-31 12:08 ` Takashi Iwai
2016-08-31 15:26 ` Takashi Sakamoto
2016-08-31 15:40 ` Takashi Iwai
2016-09-02 11:30 ` Takashi Sakamoto
2016-09-02 13:09 ` Takashi Iwai
2016-09-02 14:50 ` Takashi Sakamoto
2016-09-02 15:19 ` Takashi Iwai
2016-09-02 16:26 ` Takashi Iwai
2016-09-03 11:38 ` Charles Keepax
2016-09-04 11:07 ` Takashi Sakamoto
2016-09-04 20:45 ` Takashi Iwai
2016-09-06 3:30 ` Takashi Sakamoto
2016-09-12 12:37 ` Charles Keepax
2016-09-12 15:25 ` Vinod Koul
2016-09-12 15:28 ` Takashi Iwai
2016-09-12 16:03 ` Charles Keepax
2016-09-12 16:28 ` Takashi Iwai
2016-09-13 8:39 ` Charles Keepax
2016-08-31 12:19 ` Charles Keepax
2016-08-31 13:24 ` Clemens Ladisch
2016-08-31 14:18 ` Charles Keepax
2016-08-31 16:05 ` Vinod Koul
2016-09-02 11:18 ` Takashi Sakamoto
2016-09-02 16:05 ` Takashi Iwai
2016-09-03 3:53 ` Takashi Sakamoto
2016-09-03 11:32 ` Charles Keepax [this message]
2016-08-29 23:44 ` [PATCH 2/4] ALSA: control: delegate checking the length of data payload to each drivers Takashi Sakamoto
2016-08-30 15:46 ` Vinod Koul
2016-08-29 23:44 ` [PATCH 3/4] ALSA: control: add kerneldoc for snd_kcontrol_tlv_rw_t Takashi Sakamoto
2016-08-29 23:44 ` [PATCH 4/4] ALSA: control: bump up protocol version to 2.0.8 Takashi Sakamoto
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=20160903113213.GG21682@localhost.localdomain \
--to=ckeepax@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@linaro.org \
--cc=clemens@ladisch.de \
--cc=o-takashi@sakamocchi.jp \
--cc=omair.m.abdullah@intel.com \
--cc=tiwai@suse.de \
--cc=vinod.koul@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.