On Thu, Apr 21, 2016 at 01:00:26PM +0200, Takashi Iwai wrote: > On Thu, 21 Apr 2016 12:56:54 +0200, > Vinod Koul wrote: > > > > On Thu, Apr 21, 2016 at 09:23:25AM +0200, Takashi Iwai wrote: > > > On Thu, 21 Apr 2016 08:27:38 +0200, > > > Vinod Koul wrote: > > > > > > > > From: Shreyas NC <shreyas.nc@xxxxxxxxx> > > > > > > > > The DSP modules need private data and that is provided as binary > > > > blob. These blobs are compiled from C structures which specify module > > > > configuration. > > > > > > > > Signed-off-by: Shreyas NC <shreyas.nc@xxxxxxxxx> > > > > Signed-off-by: Vinod Koul <vinod.koul@xxxxxxxxx> > > > > > > What if this program is executed on big endian system? > > > > So we made the data structure m,emebers as __lexx shouldn't that take care > > of this, or we can say, we don't support BE systems. > > > > Am not sure if someone running BE system will be intrested in Intel aDSP :D > > It's not about whether it runs on a BE system. The most likely > problem is about the package build. > > The firmware sub-package is usually handled as a noarch one that is > used commonly among all architectures. If you generate a different > data per architecture and write to the same file, it results in the > inconsistent package, since the firmware generated by a BE host may be > used for LE machine. > > So, this needs a bit more consideration. If we don't provide the > firmware binary but only rely on the file creation at build time, it > won't get the complete set depending on the running machine. > > Maybe we should add the binary files in addition to the f/w generation > code in case anyone needs to modify the data. Yes anyway based on other discussion we will add precompiled files as well to this, so default binary data is present. And we should generate only if someone modifies, will modify this Thanks -- ~Vinod _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
