On Tue, 05 Apr 2016 18:08:55 +0200, Koul, Vinod wrote: > > On Tue, 2016-04-05 at 18:05 +0200, Takashi Iwai wrote: > > On Tue, 05 Apr 2016 17:52:19 +0200, > > Koul, Vinod wrote: > > > > > > On Tue, 2016-04-05 at 16:45 +0200, Takashi Iwai wrote: > > > > > There is no special dependency here, so we can just add > > > > > > src/conf/toplogty/*/data/Makefile.am in the toplevel > > > > > > configure.ac? > > > > > > > > > > Yes that seems better. Also please note if we do that alsa-lib > > > > > can > > > > > compile the data before it compiles skl topology so we can get > > > > > rid > > > > > of > > > > > bnary blobs whcih are prebuilt and get them generated on alsa > > > > > -lib > > > > > compile. > > > > > > > > Yeah, that's nicer, too. > > > > > > One thing though we need to run the binary to generate blobs, am > > > thinking of hooking that up with install step. > > > > Compiling something at installation is wrong in general. > > Nope that's not what I meant. > > We will compile the tool and create the binary at alsa-lib compile step. > > Then we need to run that to generate the binary blobs and that can be > done at install step OK. But now I noticed another pitfall. The topology firmware is endian-sensitive, and the code to generate is so, too. Thus it can't work for big-endian architectures. One solution would be to bundle the firmware binary and provide the generator code as a supplement like the current version. Another option would be to check the endianess in configure script and limit the intel topology f/w only for little endian via AM_CONDITIONAL(). Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
