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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
