* Re: [PATCH] conf: topology: Add topolgy for skylake i2s configuration [not found] ` <20160209114749.GA7243@subhransu-desktop> @ 2016-02-09 11:54 ` Takashi Iwai 2016-02-09 13:14 ` Subhransu S. Prusty 0 siblings, 1 reply; 9+ messages in thread From: Takashi Iwai @ 2016-02-09 11:54 UTC (permalink / raw) To: Subhransu S. Prusty Cc: patches.audio, Vinod Koul, alsa-devel, broonie, lgirdwood On Tue, 09 Feb 2016 12:47:53 +0100, Subhransu S. Prusty wrote: > > On Tue, Feb 09, 2016 at 12:15:45PM +0100, Takashi Iwai wrote: > > On Mon, 08 Feb 2016 04:55:56 +0100, > > Subhransu S. Prusty wrote: > > > > > > This patch adds basic playback/capture support for skylake i2s > > > platform. DSP topology module data are passed through the binary > > > files. The framework parses these files and puts the data in the > > > widget private section for the corresponding widget. This is > > > parsed by kernel driver and stored as module config for the DSP. > > > Based on usecase these data are sent to the DSP through IPCs for > > > further processing. > > > > Can we have sources for these binaries, or do they have to be > > binary-only? > > Hi Takashi, > > These are binary only data. Then this isn't a good material for merging to alsa-lib. How is the license compatibility? Takashi ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] conf: topology: Add topolgy for skylake i2s configuration 2016-02-09 11:54 ` [PATCH] conf: topology: Add topolgy for skylake i2s configuration Takashi Iwai @ 2016-02-09 13:14 ` Subhransu S. Prusty 2016-02-09 13:18 ` Takashi Iwai 0 siblings, 1 reply; 9+ messages in thread From: Subhransu S. Prusty @ 2016-02-09 13:14 UTC (permalink / raw) To: Takashi Iwai; +Cc: patches.audio, Vinod Koul, alsa-devel, broonie, lgirdwood On Tue, Feb 09, 2016 at 12:54:39PM +0100, Takashi Iwai wrote: > On Tue, 09 Feb 2016 12:47:53 +0100, > Subhransu S. Prusty wrote: > > > > On Tue, Feb 09, 2016 at 12:15:45PM +0100, Takashi Iwai wrote: > > > On Mon, 08 Feb 2016 04:55:56 +0100, > > > Subhransu S. Prusty wrote: > > > > > > > > This patch adds basic playback/capture support for skylake i2s > > > > platform. DSP topology module data are passed through the binary > > > > files. The framework parses these files and puts the data in the > > > > widget private section for the corresponding widget. This is > > > > parsed by kernel driver and stored as module config for the DSP. > > > > Based on usecase these data are sent to the DSP through IPCs for > > > > further processing. > > > > > > Can we have sources for these binaries, or do they have to be > > > binary-only? > > > > Hi Takashi, > > > > These are binary only data. > > Then this isn't a good material for merging to alsa-lib. How is the > license compatibility? Each binary file here holds config for each module based on skl_dfw_module structure as expected by Skylake driver. The skl driver formats IPCs parsing this config. This structure skl_dfw_module is already defined as part of skl-tplg-interface.h. Regards, Subhransu > > > Takashi -- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] conf: topology: Add topolgy for skylake i2s configuration 2016-02-09 13:14 ` Subhransu S. Prusty @ 2016-02-09 13:18 ` Takashi Iwai 2016-02-09 13:34 ` Vinod Koul 0 siblings, 1 reply; 9+ messages in thread From: Takashi Iwai @ 2016-02-09 13:18 UTC (permalink / raw) To: Subhransu S. Prusty Cc: patches.audio, Vinod Koul, alsa-devel, broonie, lgirdwood On Tue, 09 Feb 2016 14:14:19 +0100, Subhransu S. Prusty wrote: > > On Tue, Feb 09, 2016 at 12:54:39PM +0100, Takashi Iwai wrote: > > On Tue, 09 Feb 2016 12:47:53 +0100, > > Subhransu S. Prusty wrote: > > > > > > On Tue, Feb 09, 2016 at 12:15:45PM +0100, Takashi Iwai wrote: > > > > On Mon, 08 Feb 2016 04:55:56 +0100, > > > > Subhransu S. Prusty wrote: > > > > > > > > > > This patch adds basic playback/capture support for skylake i2s > > > > > platform. DSP topology module data are passed through the binary > > > > > files. The framework parses these files and puts the data in the > > > > > widget private section for the corresponding widget. This is > > > > > parsed by kernel driver and stored as module config for the DSP. > > > > > Based on usecase these data are sent to the DSP through IPCs for > > > > > further processing. > > > > > > > > Can we have sources for these binaries, or do they have to be > > > > binary-only? > > > > > > Hi Takashi, > > > > > > These are binary only data. > > > > Then this isn't a good material for merging to alsa-lib. How is the > > license compatibility? > > Each binary file here holds config for each module based on skl_dfw_module > structure as expected by Skylake driver. The skl driver formats IPCs parsing > this config. > > This structure skl_dfw_module is already defined as part of > skl-tplg-interface.h. 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. IMO, this should go to firmware tree instead, unless you can give the source code to build the binary. Takashi ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] conf: topology: Add topolgy for skylake i2s configuration 2016-02-09 13:18 ` Takashi Iwai @ 2016-02-09 13:34 ` Vinod Koul 2016-02-09 13:48 ` Takashi Iwai 0 siblings, 1 reply; 9+ messages in thread From: Vinod Koul @ 2016-02-09 13:34 UTC (permalink / raw) To: Takashi Iwai Cc: patches.audio, alsa-devel, broonie, Subhransu S. Prusty, lgirdwood On Tue, Feb 09, 2016 at 02:18:58PM +0100, Takashi Iwai wrote: > On Tue, 09 Feb 2016 14:14:19 +0100, > Subhransu S. Prusty wrote: > > > > On Tue, Feb 09, 2016 at 12:54:39PM +0100, Takashi Iwai wrote: > > > On Tue, 09 Feb 2016 12:47:53 +0100, > > > Subhransu S. Prusty wrote: > > > > > > > > On Tue, Feb 09, 2016 at 12:15:45PM +0100, Takashi Iwai wrote: > > > > > On Mon, 08 Feb 2016 04:55:56 +0100, > > > > > Subhransu S. Prusty wrote: > > > > > > > > > > > > This patch adds basic playback/capture support for skylake i2s > > > > > > platform. DSP topology module data are passed through the binary > > > > > > files. The framework parses these files and puts the data in the > > > > > > widget private section for the corresponding widget. This is > > > > > > parsed by kernel driver and stored as module config for the DSP. > > > > > > Based on usecase these data are sent to the DSP through IPCs for > > > > > > further processing. > > > > > > > > > > Can we have sources for these binaries, or do they have to be > > > > > binary-only? > > > > > > > > Hi Takashi, > > > > > > > > These are binary only data. > > > > > > Then this isn't a good material for merging to alsa-lib. How is the > > > license compatibility? > > > > Each binary file here holds config for each module based on skl_dfw_module > > structure as expected by Skylake driver. The skl driver formats IPCs parsing > > this config. > > > > This structure skl_dfw_module is already defined as part of > > skl-tplg-interface.h. > > 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; > 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? -- ~Vinod ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] conf: topology: Add topolgy for skylake i2s configuration 2016-02-09 13:34 ` Vinod Koul @ 2016-02-09 13:48 ` Takashi Iwai 2016-02-11 3:52 ` Vinod Koul 0 siblings, 1 reply; 9+ messages in thread From: Takashi Iwai @ 2016-02-09 13:48 UTC (permalink / raw) To: Vinod Koul Cc: patches.audio, alsa-devel, broonie, Subhransu S. Prusty, lgirdwood On Tue, 09 Feb 2016 14:34:32 +0100, Vinod Koul wrote: > > On Tue, Feb 09, 2016 at 02:18:58PM +0100, Takashi Iwai wrote: > > On Tue, 09 Feb 2016 14:14:19 +0100, > > Subhransu S. Prusty wrote: > > > > > > On Tue, Feb 09, 2016 at 12:54:39PM +0100, Takashi Iwai wrote: > > > > On Tue, 09 Feb 2016 12:47:53 +0100, > > > > Subhransu S. Prusty wrote: > > > > > > > > > > On Tue, Feb 09, 2016 at 12:15:45PM +0100, Takashi Iwai wrote: > > > > > > On Mon, 08 Feb 2016 04:55:56 +0100, > > > > > > Subhransu S. Prusty wrote: > > > > > > > > > > > > > > This patch adds basic playback/capture support for skylake i2s > > > > > > > platform. DSP topology module data are passed through the binary > > > > > > > files. The framework parses these files and puts the data in the > > > > > > > widget private section for the corresponding widget. This is > > > > > > > parsed by kernel driver and stored as module config for the DSP. > > > > > > > Based on usecase these data are sent to the DSP through IPCs for > > > > > > > further processing. > > > > > > > > > > > > Can we have sources for these binaries, or do they have to be > > > > > > binary-only? > > > > > > > > > > Hi Takashi, > > > > > > > > > > These are binary only data. > > > > > > > > Then this isn't a good material for merging to alsa-lib. How is the > > > > license compatibility? > > > > > > Each binary file here holds config for each module based on skl_dfw_module > > > structure as expected by Skylake driver. The skl driver formats IPCs parsing > > > this config. > > > > > > This structure skl_dfw_module is already defined as part of > > > skl-tplg-interface.h. > > > > 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. Takashi ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] conf: topology: Add topolgy for skylake i2s configuration 2016-02-09 13:48 ` Takashi Iwai @ 2016-02-11 3:52 ` Vinod Koul 2016-02-11 8:38 ` Takashi Iwai 0 siblings, 1 reply; 9+ messages in thread From: Vinod Koul @ 2016-02-11 3:52 UTC (permalink / raw) To: Takashi Iwai Cc: patches.audio, alsa-devel, broonie, Subhransu S. Prusty, lgirdwood 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. Do you have recommendation for location of these two files in alsa-lib? Thanks -- ~Vinod ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] conf: topology: Add topolgy for skylake i2s configuration 2016-02-11 3:52 ` Vinod Koul @ 2016-02-11 8:38 ` Takashi Iwai 2016-02-11 13:56 ` Takashi Sakamoto 0 siblings, 1 reply; 9+ messages in thread From: Takashi Iwai @ 2016-02-11 8:38 UTC (permalink / raw) To: Vinod Koul Cc: patches.audio, alsa-devel, broonie, Subhransu S. Prusty, lgirdwood 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] conf: topology: Add topolgy for skylake i2s configuration 2016-02-11 8:38 ` Takashi Iwai @ 2016-02-11 13:56 ` Takashi Sakamoto 2016-02-11 15:35 ` Takashi Iwai 0 siblings, 1 reply; 9+ messages in thread From: Takashi Sakamoto @ 2016-02-11 13:56 UTC (permalink / raw) To: Takashi Iwai, Vinod Koul Cc: patches.audio, alsa-devel, broonie, Subhransu S. Prusty, lgirdwood Hi, On Feb 11 2016 17:38, Takashi Iwai wrote: > 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? Could I ask your opinion about device-dependent codes in common library? The alsa-lib is designed for generic ALSA applications. So codes in alsa-lib can be used by the applications. On the other hand, your codes are not completely common. Even if Intel SoCs are widely used in this world, I think there's rest of consideration about merging it. And when you include device-dependent code into such common library, I think it increases maintenance cost, because no one except you can understand it. I think it's not so better shape of shared library. In short, IF Interl corp. lost their interests in ALSA, your codes might not be mainteined anymore. (And I can remember some OSS projects got by Intel corp.) For example, simple mixer API has backend modules for AC97/HDA/python2 and the modules are not currently maintained. Near future, your codes will join in such bothersome stuffs, won't they? Well. I'm not so goot at what you achieve with this patch and a series of your work for TLV extensions of ALSA ctl interface. So could I request your intension about this patch? At least, I cannot still understand what your codes works with kernel implementation for features integrated into skl SoC. I believe we should take more time to this patch, at least for some developers who select alternative ways to control devices for which they currently work. Of cource, I believe that your work will reach more users than our effort. We can judge that it's more reasonable to merge your codes into common library. But to reach the decision, more explainations and discussions are required. Regards Takashi Sakamoto ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] conf: topology: Add topolgy for skylake i2s configuration 2016-02-11 13:56 ` Takashi Sakamoto @ 2016-02-11 15:35 ` Takashi Iwai 0 siblings, 0 replies; 9+ messages in thread From: Takashi Iwai @ 2016-02-11 15:35 UTC (permalink / raw) To: Takashi Sakamoto Cc: alsa-devel, Vinod Koul, lgirdwood, patches.audio, broonie, Subhransu S. Prusty On Thu, 11 Feb 2016 14:56:03 +0100, Takashi Sakamoto wrote: > > Hi, > > On Feb 11 2016 17:38, Takashi Iwai wrote: > > 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? > > Could I ask your opinion about device-dependent codes in common library? > > The alsa-lib is designed for generic ALSA applications. So codes in > alsa-lib can be used by the applications. On the other hand, your codes > are not completely common. Even if Intel SoCs are widely used in this > world, I think there's rest of consideration about merging it. The code isn't about inclusion into the library itself, but it's a code (a la helper binary) to generate a card-specific external data. So it's rather a kind of config data, just represented in a binary form. Takashi ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-02-11 15:35 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1454903756-2075-1-git-send-email-subhransu.s.prusty@intel.com> [not found] ` <s5ha8naxhge.wl-tiwai@suse.de> [not found] ` <20160209114749.GA7243@subhransu-desktop> 2016-02-09 11:54 ` [PATCH] conf: topology: Add topolgy for skylake i2s configuration Takashi Iwai 2016-02-09 13:14 ` Subhransu S. Prusty 2016-02-09 13:18 ` Takashi Iwai 2016-02-09 13:34 ` Vinod Koul 2016-02-09 13:48 ` Takashi Iwai 2016-02-11 3:52 ` Vinod Koul 2016-02-11 8:38 ` Takashi Iwai 2016-02-11 13:56 ` Takashi Sakamoto 2016-02-11 15:35 ` Takashi Iwai
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.