All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vinod.koul@intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, Mark Brown <broonie@kernel.org>,
	"Subhransu S. Prusty" <subhransu.s.prusty@intel.com>,
	lgirdwood@gmail.com, Lars-Peter Clausen <lars@metafoo.de>
Subject: Re: [PATCH v5 03/12] ALSA: control: Add init callback for kcontrol
Date: Mon, 8 Sep 2014 13:38:07 +0530	[thread overview]
Message-ID: <20140908080807.GJ1610@intel.com> (raw)
In-Reply-To: <s5hppf6a679.wl-tiwai@suse.de>

On Mon, Sep 08, 2014 at 10:04:42AM +0200, Takashi Iwai wrote:
> At Mon, 8 Sep 2014 09:44:21 +0530,
> Vinod Koul wrote:
> > 
> > On Sat, Sep 06, 2014 at 05:56:02PM +0200, Takashi Iwai wrote:
> > > At Sat, 6 Sep 2014 15:21:24 +0100,
> > > Mark Brown wrote:
> > > > 
> > > > On Tue, Sep 02, 2014 at 06:05:58PM +0530, Subhransu S. Prusty wrote:
> > > > > Some controls need to initialize stuffs like pvt data, so they need a
> > > > > callback if the control creation is successful.
> > > > 
> > > > Adding Takashi - this is ALSA core code so he needs to review it.
> > > 
> > > This would bloat effectively the data size of all sound drivers, so I
> > > can't ack it without more proper reasoning.  That is, please convince
> > > me why this change must be taken for the cost of size bloat of all
> > > sound drivers.  Can't you do it in the caller side of snd_ctl_add()
> > > like many other drivers already do?
> > Okay lets step back and see why we need this :)
> > 
> > In our case after the control creation we need to allocate memory which will
> > hold the data for the byte controls. This can be done only after the
> > controls are created (by asoc).
> 
> Why?  Because you don't need how many bytes to allocate?
> 
> > For that we need a callback into driver so that we can allocate the memory.
> > Thats why we added .init() method. If you have any other way to do this, we
> > are all ears :)
> 
> For example, you can embed an init flag into your record and call the
> initializer in get/put callback if not called yet.
Yes but that would involve open coding in all control hanlers for the driver :

if (!initialized)
	allocate_control_mem();

This approach was done earlier (checking in info) and flaged off by Mark. It make better to
have these handled in the framework.

Either ways we are okay with whatever you two decide :)

-- 
~Vinod

  reply	other threads:[~2014-09-08  8:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-02 12:35 [PATCH v5 00/12] Add mrfld DSP topology and widgets Subhransu S. Prusty
2014-09-02 12:35 ` [PATCH v5 01/12] ASoC: mfld: pcm: Replace pr_ with dev_ Subhransu S. Prusty
2014-09-06 14:21   ` Mark Brown
2014-09-02 12:35 ` [PATCH v5 02/12] ASoC: Intel: mfld-pcm: don't call trigger ops to DSP for internal streams Subhransu S. Prusty
2014-09-02 12:35 ` [PATCH v5 03/12] ALSA: control: Add init callback for kcontrol Subhransu S. Prusty
2014-09-06 14:21   ` Mark Brown
2014-09-06 15:56     ` Takashi Iwai
2014-09-08  4:14       ` Vinod Koul
2014-09-08  8:04         ` Takashi Iwai
2014-09-08  8:08           ` Vinod Koul [this message]
2014-09-08  8:36             ` Takashi Iwai
2014-09-08 11:08               ` Vinod Koul
2014-09-09 11:44             ` Mark Brown
2014-09-10  8:05               ` Vinod Koul
2014-09-02 12:35 ` [PATCH v5 04/12] ASoC: Intel: mrfld: add bytes control for modules Subhransu S. Prusty
2014-09-02 12:36 ` [PATCH v5 05/12] ASoC: Intel: mrfld: add the gain controls Subhransu S. Prusty
2014-09-02 12:36 ` [PATCH v5 06/12] ASoC: Intel: mfld-pcm: add control for powering up/down dsp Subhransu S. Prusty
2014-09-02 12:36 ` [PATCH v5 07/12] ASoC: Intel: mrfld: add DSP core controls Subhransu S. Prusty
2014-09-02 12:36 ` [PATCH v5 08/12] ASoC: Export dapm_kcontrol_get_value Subhransu S. Prusty
2014-09-02 12:36 ` [PATCH v5 09/12] ASoC: Intel: mrfld: add the DSP DAPM widgets Subhransu S. Prusty
2014-09-02 12:36 ` [PATCH v5 10/12] ASoC: Intel: mfld-pcm: add FE and BE ops Subhransu S. Prusty
2014-09-02 12:36 ` [PATCH v5 11/12] ASoC: Intel: mrfld: Use snd_soc_dai_get_drvdata to derive drv data Subhransu S. Prusty
2014-09-02 12:36 ` [PATCH v5 12/12] ASoC: Intel: mrfld: add the DSP mixers Subhransu S. Prusty

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=20140908080807.GJ1610@intel.com \
    --to=vinod.koul@intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=subhransu.s.prusty@intel.com \
    --cc=tiwai@suse.de \
    /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.