From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH] conf: topology: Add topolgy for skylake i2s configuration Date: Thu, 11 Feb 2016 09:38:55 +0100 Message-ID: References: <1454903756-2075-1-git-send-email-subhransu.s.prusty@intel.com> <20160209114749.GA7243@subhransu-desktop> <20160209131415.GA26322@subhransu-desktop> <20160209133432.GN19598@localhost> <20160211035258.GU19598@localhost> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id C3CBD260647 for ; Thu, 11 Feb 2016 09:38:55 +0100 (CET) In-Reply-To: <20160211035258.GU19598@localhost> 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: Vinod Koul Cc: patches.audio@intel.com, alsa-devel@alsa-project.org, broonie@kernel.org, "Subhransu S. Prusty" , lgirdwood@gmail.com List-Id: alsa-devel@alsa-project.org On Thu, 11 Feb 2016 04:52:58 +0100, Vinod Koul wrote: > > On Tue, Feb 09, 2016 at 02:48:36PM +0100, Takashi Iwai wrote: > > > > Well, the question is whether this IP is a programmed data block, not > > > > some simple numbers. If yes, it's always a question whether it's > > > > compatible with GPL. Although alsa-lib is LGPL, putting the binary > > > > blob in the *code tree* doesn't look good to me. > > > > > > Hi Takashi, > > > > > > This is simple numbers only. Numbers which identify the data for firmware, > > > its resources, ids, pipe number, module number and for controls default > > > values etc. Basically this struct > > > > > > struct skl_dfw_module { > > > char uuid[SKL_UUID_STR_SZ]; > > > > > > u16 module_id; > > > u16 instance_id; > > > u32 max_mcps; > > > u32 mem_pages; > > > u32 obs; > > > u32 ibs; > > > u32 vbus_id; > > > > > > u32 max_in_queue:8; > > > u32 max_out_queue:8; > > > u32 time_slot:8; > > > u32 core_id:4; > > > u32 rsvd1:4; > > > > > > u32 module_type:8; > > > u32 conn_type:4; > > > u32 dev_type:4; > > > u32 hw_conn_type:4; > > > u32 rsvd2:12; > > > > > > u32 params_fixup:8; > > > u32 converter:8; > > > u32 input_pin_type:1; > > > u32 output_pin_type:1; > > > u32 is_dynamic_in_pin:1; > > > u32 is_dynamic_out_pin:1; > > > u32 is_loadable:1; > > > u32 rsvd3:11; > > > > > > struct skl_dfw_pipe pipe; > > > struct skl_dfw_module_fmt in_fmt[MAX_IN_QUEUE]; > > > struct skl_dfw_module_fmt out_fmt[MAX_OUT_QUEUE]; > > > struct skl_dfw_module_pin in_pin[MAX_IN_QUEUE]; > > > struct skl_dfw_module_pin out_pin[MAX_OUT_QUEUE]; > > > struct skl_dfw_module_caps caps; > > > } __packed; > > > > OK, but how did you create it? Via a hex editor? If you used some > > converter, you'd better provide the readable source, too. > > > > > > IMO, this should go to firmware tree instead, unless you can give the > > > > source code to build the binary. > > > > > > Okay that should be fine, where do we add the source? > > > > In alsa-lib. It's not necessarily to be in form as all build-ready > > there, but providing the capability is important for future > > development. > > Okay so we will add a intel-topology.c file to alsa-lib, this will also > include a file which will contain the above structure values for each module > in C style. > > This way anyone can edit it easily and we can build blobs from alsa lib and > then run topology tool on it. It's much better, indeed. > Do you have recommendation for location of these two files in alsa-lib? Just put in the same directory? Takashi