[yocto] Yocto Kernel Module Workflow Question

[Glenn Schmottlach]

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!