Colin Cross wrote on Friday, January 21, 2011 11:43 AM:
On Thu, Jan 20, 2011 at 12:52 PM, Stephen Warren wrote:
create mode 100644 arch/arm/mach-tegra/include/mach/harmony_audio.h
Does this file really belong in mach-tegra if its for a driver that is in a common directory (drivers/sound/soc)? Putting it in include/linux would solve all your tree-ordering problems.
Colin,
Re: The location I chose; I followed an existing example of another ASoC driver. Perhaps there is a more appropriate location, although the ASoC maintainers didn't point one out.
I'm afraid I don't understand how moving the file would solve the dependency issues though:
There's a change in sound/soc/... that needs this new file.
There's a change in arch/arm/mach-tegra/... that needs this new file.
Both those two changes would typically get checked into two separate git repositories.
As far as I can tell, we could:
a) Check the new file into both repositories, and git will hopefully just merge them together in the next merge window. Mark pointed out a long time ago that this is generally frowned upon though.
b) Check the change into just one repository, e.g. ASoC since it's ready to accept the sound/soc/... changes that rely on it, and then have Tegra's for-next merge that (or merge linux-next after it's filtered up there, although I'm not sure if merging linux-next is workable with git?) (or merge directly from ASoC's for-2.6.39) and only then apply the arch/arm/tegra changes that rely on it. Mark pointed out a long time ago that such cross- subsystem merges are very rare, although it sounded like they do happen sometimes.
c) Only check in the sound/soc/... changes, wait until they're in 2.6.39-rc1 and hence can be picked up from there for Tegra's for-next, and then check in the Tegra changes that rely on it. This would delay the complete changes until 2.6.40:-(
I'm still in the dark how this normally works; it seems like it must be pretty common to add a new driver to the driver repository, with that driver defining a new platform_data type, and also needing to add code to the architecture/chip repository to provide that platform_data, and hopefully have both those things go in in parallel, rather than being staged across two kernel releases.