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

[Colin Cross]

On Fri, Jan 21, 2011 at 2:35 PM, Stephen Warren <swarren at nvidia.com> wrote:
> 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.

Could the same platform_data patch go into both ASoC and Tegra?  It
would fall out in the merge, no matter who gets pulled first.  If we
go that route, whichever place you put the header, one of the trees
will have an include file that is in the other tree's directory.

I still think the header makes more sense in include/sound than
mach-tegra, but if the ASoC maintainers prefer it in mach-tegra,
consider the patch Acked-by: Colin Cross <ccross at android.com> for
inclusion in the ASoC tree.