I am developing a codec kernel driver/module for the BeagleBone Black and have a question about the recommended work-flow for developing this module in the context of the Yocto/poky environment. Currently I'm working with the Daisy release using the meta-ti layer and the linux-ti-staging_3.14 kernel sources.
The codec driver, at this point, is just an very minimal implementation. It follows closely the instructions described here: http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_Audio_DAC_Example The work involves a dummy (platform independent) ALSA driver for the DAC and then code modifications to the ALSA machine layer driver (sound/soc/davinci/davinci-evm) and the BeagleBone Black device tree to knit all of these pieces together. There seems to be two approaches for developing the codec driver. The first approach is to build the codec driver externally from the kernel sources (e.g. as described in working with "out-of-tree" modules in the Yocto Kernel Development Guide). With this model I can represent the codec driver as a separate Yocto/Bitbake recipe and simply include the resulting package in my target image. Unfortunately, the codec driver also requires changes to the kernel sources in the ALSA machine layer driver and device tree. My approach here is the create a linux-ti-staging_3.14.bbappend file that contains a series of patches to the kernel for the machine layer driver and device tree. In this scenario, the kernel sources do *not* explicitly know about this new codec since there are no changes to the sound/soc/codec Makefile and associated Kconfig's that describe the dependencies of the codec driver. This means of course that menuconfig won't show the codec as a build-able option. So the ALSA machine driver (davinci-evm) knows the name of the codec driver but nothing more other than it's association with a particular device tree configuration node (e.g. dtc_id). This may not be ideal for someone configuring the kernel since this codec doesn't appear as an option and the dependencies (as described in the Kconfig) are not clear. The work-around, albeit clumsy, is to bundle the changes to the Makefile/Kconfig's and the codec source itself as a set of patches referenced from the linux-ti-staging_3.14.bbappend file. Now building the kernel modules also builds the codec (e.g. no separate codec Bitbake recipe is required). This works but now my codec sources exist as a "patch" and stored directly in the recipe. Assuming I want to do iterative development with this module, every change to the codec sources require me to update the codec "patch". Also, the codec source must then effectively be version-controlled within the *.bbappend recipe itself (as a *.patch file or possibly as a naked codec.c that is copied into the destination kernel sources during the patch step of bitbake). Ideally, I'd like to maintain my codec driver outside of the kernel tree (since it is not dependent on the BeagleBone Black) and just maintain the *.bbappend to make the necessary platform-specific machine-layer/device-tree patches. I want the codec to be built with the kernel sources but not treated as a Yocto "out-of-tree" module. Is there a way for the *.bbappend to fetch the codec sources from another repo and place them in the kernel sound/soc/codecs directory before the kernel is built? Can anyone suggest a better/alternative work-flow that accommodates keeping the codec sources in a separate repo (much like the "out-of-tree" modules) while allowing seamless integration into the kernel sources. Fundamentally, I don't want the codec sources to be version controlled directly *inside* the *.bbappend recipe as either a patch or as a raw source file. Is there an alternative work-flow that works better with Yocto? Any feedback would be appreciated . . . thanks! -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto