[alsa-devel] [PATCH v5 03/12] ALSA: control: Add init callback for kcontrol

[Vinod Koul]

On Mon, Sep 08, 2014 at 10:36:57AM +0200, Takashi Iwai wrote:
> At Mon, 8 Sep 2014 13:38:07 +0530,
> Vinod Koul wrote:
> > 
> > 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.
> 
> For the cost of bloating all sound drivers with every control element?
> No.  You can extend the framework, but not in this way.
Yes makes sense.

> For example, it's nonsense to keep this permanently in each control
> element, and both in kcontrol and kcontrol_new.  Remember that this is
> a oneshot callback that is called only after creation...
Yes indeed, so we are going to rely on the falg in driver records and initialize at
first invocation.

Updated series spinning now
-- 
~Vinod