Marc Dietrich wrote at Tuesday, December 20, 2011 5:39 AM:
Am Dienstag, 20. Dezember 2011, 14:11:01 schrieb Leon Romanovsky:
On Tue, Dec 20, 2011 at 13:58, Marc Dietrich marvin24@gmx.de wrote:
Am Dienstag, 20. Dezember 2011, 13:05:50 schrieb Leon Romanovsky:
On Tue, Dec 20, 2011 at 10:47, Marc Dietrich marvin24@gmx.de wrote:
Am Dienstag, 20. Dezember 2011, 08:45:39 schrieb Leon Romanovsky:
On Mon, Dec 19, 2011 at 23:00, Stephen Warren swarren@nvidia.com wrote: > Leon Romanovsky wrote at Monday, December 19, 2011 12:52 PM: Before, I'm going to start pushing other parts of the audio, how do I need to handle cross-tree patches ? For example I'll need to update NVEC (staging tree) and platform_device (tegra and ASoC) On which tree do I base my patches?
If you have updates to other files beside the audio stuff (nvec or board stuff), you need to CC the relevant maintainers (see scripts/get_maintainer.pl).
Different trees have different file versions, this is why i'm asking "on which tree do I base my patches?"
ok, I think patches for upstream should be based on the relevant subsystem trees (e.g. sound (git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git), board (arm-soc git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git) and nvec ( git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git). One may correct me where I'm wrong.
And how will you ensure that the proposed patches will compile well? For example, Mark applied the tegra_alc5632.c patch into ASoC tree, but in tegra tree this file still doesn't exist, so any my attempt to link board-paz00.c (tegra tree) with tegra_alc5632. will lead to compile failures.
test with e.g. linux-next, *submit early* to the subsystems and fix breakage later on.
Well, we should strive to avoid creating any breakage in the first place; if you break anything, that means "git bisect" will stop working, which might make tracking down other problems a pain.
In this case, I think the patches you need to the Tegra tree don't have any dependencies on the ALSA/ASoC tree; you're basically only registering some platform devices, and you can register those irrespective of whether drivers exist for those devices or not yet.
Put another way, registering the devices in the Tegra tree without the ASoC changes being present will be pretty much a harmless no-op. Having the drivers present in the ASoC tree without any platform devices being registered to instantiate them will also be a harmless no-op. Once both sets of changes meet (in linux-next, or a Linus tree), they'll interact and cause audio to start working.
The only dependency you'll have is the addition of the platform data header file, which needs to be in both trees to compile the board file and the driver, but you haven't created this file yet, so there's no problem to date. In the past, Mark and I have handled this by:
* Create a patch that does nothing but add the pdata header file. * Put that patch in a branch of its own. * Merge that branch into both the Tegra tree and the ASoC tree before any changes that use the header file.
But there are other ways to handle this too. Given all the work in the Tegra tree right now though, that way is probably the simplest for everyone to deal with.