From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinod Koul Subject: Re: [PATCH v5 2/4] ASoC: Intel - add Skylake HDA audio driver Date: Tue, 16 Jun 2015 20:55:27 +0530 Message-ID: <20150616152527.GY28601@localhost> References: <1434040438-14535-1-git-send-email-vinod.koul@intel.com> <1434040438-14535-3-git-send-email-vinod.koul@intel.com> <20150615155632.GU18309@sirena.org.uk> <20150615164202.GW18309@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by alsa0.perex.cz (Postfix) with ESMTP id CE7AD2657FE for ; Tue, 16 Jun 2015 17:24:02 +0200 (CEST) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: alsa-devel@alsa-project.org, patches.audio@intel.com, liam.r.girdwood@linux.intel.com, Mark Brown , Jeeja KP , "Subhransu S. Prusty" List-Id: alsa-devel@alsa-project.org On Mon, Jun 15, 2015 at 06:46:33PM +0200, Takashi Iwai wrote: > At Mon, 15 Jun 2015 17:42:02 +0100, > Mark Brown wrote: > > > > On Mon, Jun 15, 2015 at 06:35:16PM +0200, Takashi Iwai wrote: > > > Mark Brown wrote: > > > > On Thu, Jun 11, 2015 at 10:03:56PM +0530, Vinod Koul wrote: > > > > > > > + for (i = 0; i < num_stream; i++) { > > > > > + struct hdac_ext_stream *stream = > > > > > + kzalloc(sizeof(*stream), GFP_KERNEL); > > > > > > Still not sure why these are Sky Lake specific? > > > > > Currently the allocation and the free of each HDA(-ext) stream are > > > left to each controller driver. (See the stream object is embedded.) > > > > It looks awfully like it's dynamically allocated here... > > > > > And, yes, the allocation (especially the assignment of the stream tag) > > > *is* SKL specific. SKL has some twists in the interpretation of > > > HD-audio spec. > > > > I can see the thing calling these functions being driver specific but as > > far as I can see all these are doing is allocating structs, initialising > > them with passed in parameters, putting them on a list and calling a > > core function on them. It's not the bit taking the decisions, it's just > > doing mechanical things. > > Actually, this can be done a bit more cleanly -- if there will be no > more additions to the stream object. It wasn't clear, so the > allocation and free are left to the driver, so far. Stream object shouldnt be modfied, so in that case should I move this to core and ext/ ? -- ~Vinod