[alsa-devel] [PATCH v3 2/4] ARM: tegra: Add Harmony sound platform data type

[Stephen Warren]

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.

-- 
nvpublic