Hi Takashi,
Today's linux-next merge of the sound tree got a conflict in
sound/soc/samsung/smdk_wm8580.c sound/soc/samsung/smdk_wm9713.c between
commit 7ca825bed699c77b218ead402202df384556950b ("ASoC: Samsung: Rename
DMA device") from the s5p tree and various commits from the sound tree.
I used the versions from the sound tree that seemed to be supersets of the
ones from the s5p tree.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Stephen Rothwell wrote:
>
> Hi Takashi,
>
> Today's linux-next merge of the sound tree got a conflict in
> sound/soc/samsung/smdk_wm8580.c sound/soc/samsung/smdk_wm9713.c between
> commit 7ca825bed699c77b218ead402202df384556950b ("ASoC: Samsung: Rename
> DMA device") from the s5p tree and various commits from the sound tree.
>
> I used the versions from the sound tree that seemed to be supersets of the
> ones from the s5p tree.
Merry Xmas Stephen :-)
Thanks for your information.
As I said to Mark, I did 'cherry-pick' following 2 commits in my tree for
avoiding build error from sound-2.6.git.
I couldn't 'merge' into my tree because there is no suitable branch in your
tree...
--
commit 83e37b8e400ca51cc97946815b3055daacd92fa8
Author: Jassi Brar <[email protected]>
Date: Mon Nov 22 15:35:53 2010 +0900
ARM: Samsung: Define common audio-dma device
The ASoC uses common DMA driver for Audio devices. So it makes
sense to a common audio-dma device shared across all platforms.
Signed-off-by: Jassi Brar <[email protected]>
Acked-by: Kukjin Kim <[email protected]>
Acked-by: Liam Girdwood <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
commit 58bb4072132c54d832082cc6eac396a6db009cbd
Author: Jassi Brar <[email protected]>
Date: Mon Nov 22 15:35:50 2010 +0900
ASoC: Samsung: Rename DMA device
Some Samsung SoCs have a PCM(DSP) controller. So the name
s3c24xx-pcm-audio for DMA driver is not very appropraite.
This patch moves :-
s3c24xx-pcm-audio -> samsung-audio
Signed-off-by: Jassi Brar <[email protected]>
Acked-by: Kukjin Kim <[email protected]>
Acked-by: Liam Girdwood <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
--
Maybe happened conflict from latter commit.
Anyway I need above commits from sound-2.6.git in my tree...
so how method is better to me instead of cherry-pick it?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <[email protected]>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
At Thu, 23 Dec 2010 19:31:12 +0900,
Kukjin Kim wrote:
>
> Stephen Rothwell wrote:
> >
> > Hi Takashi,
> >
> > Today's linux-next merge of the sound tree got a conflict in
> > sound/soc/samsung/smdk_wm8580.c sound/soc/samsung/smdk_wm9713.c between
> > commit 7ca825bed699c77b218ead402202df384556950b ("ASoC: Samsung: Rename
> > DMA device") from the s5p tree and various commits from the sound tree.
> >
> > I used the versions from the sound tree that seemed to be supersets of the
> > ones from the s5p tree.
>
> Merry Xmas Stephen :-)
>
> Thanks for your information.
>
> As I said to Mark, I did 'cherry-pick' following 2 commits in my tree for
> avoiding build error from sound-2.6.git.
> I couldn't 'merge' into my tree because there is no suitable branch in your
> tree...
>
> --
>
> commit 83e37b8e400ca51cc97946815b3055daacd92fa8
> Author: Jassi Brar <[email protected]>
> Date: Mon Nov 22 15:35:53 2010 +0900
>
> ARM: Samsung: Define common audio-dma device
>
> The ASoC uses common DMA driver for Audio devices. So it makes
> sense to a common audio-dma device shared across all platforms.
>
> Signed-off-by: Jassi Brar <[email protected]>
> Acked-by: Kukjin Kim <[email protected]>
> Acked-by: Liam Girdwood <[email protected]>
> Signed-off-by: Mark Brown <[email protected]>
>
> commit 58bb4072132c54d832082cc6eac396a6db009cbd
> Author: Jassi Brar <[email protected]>
> Date: Mon Nov 22 15:35:50 2010 +0900
>
> ASoC: Samsung: Rename DMA device
>
> Some Samsung SoCs have a PCM(DSP) controller. So the name
> s3c24xx-pcm-audio for DMA driver is not very appropraite.
> This patch moves :-
> s3c24xx-pcm-audio -> samsung-audio
>
> Signed-off-by: Jassi Brar <[email protected]>
> Acked-by: Kukjin Kim <[email protected]>
> Acked-by: Liam Girdwood <[email protected]>
> Signed-off-by: Mark Brown <[email protected]>
>
> --
>
> Maybe happened conflict from latter commit.
>
> Anyway I need above commits from sound-2.6.git in my tree...
> so how method is better to me instead of cherry-pick it?
You can merge topic/asoc branch of sound git tree.
This brach contains the all necessary commits for ASoC and is almost
never rebased.
thanks,
Takashi
Takashi Iwai wrote:
>
> At Thu, 23 Dec 2010 19:31:12 +0900,
> Kukjin Kim wrote:
> >
> > Stephen Rothwell wrote:
> > >
> > > Hi Takashi,
> > >
> > > Today's linux-next merge of the sound tree got a conflict in
> > > sound/soc/samsung/smdk_wm8580.c sound/soc/samsung/smdk_wm9713.c
between
> > > commit 7ca825bed699c77b218ead402202df384556950b ("ASoC: Samsung:
Rename
> > > DMA device") from the s5p tree and various commits from the sound
tree.
> > >
> > > I used the versions from the sound tree that seemed to be supersets of
> the
> > > ones from the s5p tree.
> >
> > Merry Xmas Stephen :-)
> >
> > Thanks for your information.
> >
> > As I said to Mark, I did 'cherry-pick' following 2 commits in my tree
for
> > avoiding build error from sound-2.6.git.
> > I couldn't 'merge' into my tree because there is no suitable branch in
your
> > tree...
> >
> > --
> >
> > commit 83e37b8e400ca51cc97946815b3055daacd92fa8
> > Author: Jassi Brar <[email protected]>
> > Date: Mon Nov 22 15:35:53 2010 +0900
> >
> > ARM: Samsung: Define common audio-dma device
> >
> > The ASoC uses common DMA driver for Audio devices. So it makes
> > sense to a common audio-dma device shared across all platforms.
> >
> > Signed-off-by: Jassi Brar <[email protected]>
> > Acked-by: Kukjin Kim <[email protected]>
> > Acked-by: Liam Girdwood <[email protected]>
> > Signed-off-by: Mark Brown <[email protected]>
> >
> > commit 58bb4072132c54d832082cc6eac396a6db009cbd
> > Author: Jassi Brar <[email protected]>
> > Date: Mon Nov 22 15:35:50 2010 +0900
> >
> > ASoC: Samsung: Rename DMA device
> >
> > Some Samsung SoCs have a PCM(DSP) controller. So the name
> > s3c24xx-pcm-audio for DMA driver is not very appropraite.
> > This patch moves :-
> > s3c24xx-pcm-audio -> samsung-audio
> >
> > Signed-off-by: Jassi Brar <[email protected]>
> > Acked-by: Kukjin Kim <[email protected]>
> > Acked-by: Liam Girdwood <[email protected]>
> > Signed-off-by: Mark Brown <[email protected]>
> >
> > --
> >
> > Maybe happened conflict from latter commit.
> >
> > Anyway I need above commits from sound-2.6.git in my tree...
> > so how method is better to me instead of cherry-pick it?
>
> You can merge topic/asoc branch of sound git tree.
> This brach contains the all necessary commits for ASoC and is almost
> never rebased.
Hi,
But I can't merge it because there is no 'topic/asoc' branch in
sound-2.6.git.
(git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git)
Is there another repository?
And should I merge it in my tree even though don't need all of ASoC commits
:-( ?
I'm not sure how many commits are in there...
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <[email protected]>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
At Thu, 23 Dec 2010 20:11:56 +0900,
Kukjin Kim wrote:
>
> Takashi Iwai wrote:
> >
> > At Thu, 23 Dec 2010 19:31:12 +0900,
> > Kukjin Kim wrote:
> > >
> > > Stephen Rothwell wrote:
> > > >
> > > > Hi Takashi,
> > > >
> > > > Today's linux-next merge of the sound tree got a conflict in
> > > > sound/soc/samsung/smdk_wm8580.c sound/soc/samsung/smdk_wm9713.c
> between
> > > > commit 7ca825bed699c77b218ead402202df384556950b ("ASoC: Samsung:
> Rename
> > > > DMA device") from the s5p tree and various commits from the sound
> tree.
> > > >
> > > > I used the versions from the sound tree that seemed to be supersets of
> > the
> > > > ones from the s5p tree.
> > >
> > > Merry Xmas Stephen :-)
> > >
> > > Thanks for your information.
> > >
> > > As I said to Mark, I did 'cherry-pick' following 2 commits in my tree
> for
> > > avoiding build error from sound-2.6.git.
> > > I couldn't 'merge' into my tree because there is no suitable branch in
> your
> > > tree...
> > >
> > > --
> > >
> > > commit 83e37b8e400ca51cc97946815b3055daacd92fa8
> > > Author: Jassi Brar <[email protected]>
> > > Date: Mon Nov 22 15:35:53 2010 +0900
> > >
> > > ARM: Samsung: Define common audio-dma device
> > >
> > > The ASoC uses common DMA driver for Audio devices. So it makes
> > > sense to a common audio-dma device shared across all platforms.
> > >
> > > Signed-off-by: Jassi Brar <[email protected]>
> > > Acked-by: Kukjin Kim <[email protected]>
> > > Acked-by: Liam Girdwood <[email protected]>
> > > Signed-off-by: Mark Brown <[email protected]>
> > >
> > > commit 58bb4072132c54d832082cc6eac396a6db009cbd
> > > Author: Jassi Brar <[email protected]>
> > > Date: Mon Nov 22 15:35:50 2010 +0900
> > >
> > > ASoC: Samsung: Rename DMA device
> > >
> > > Some Samsung SoCs have a PCM(DSP) controller. So the name
> > > s3c24xx-pcm-audio for DMA driver is not very appropraite.
> > > This patch moves :-
> > > s3c24xx-pcm-audio -> samsung-audio
> > >
> > > Signed-off-by: Jassi Brar <[email protected]>
> > > Acked-by: Kukjin Kim <[email protected]>
> > > Acked-by: Liam Girdwood <[email protected]>
> > > Signed-off-by: Mark Brown <[email protected]>
> > >
> > > --
> > >
> > > Maybe happened conflict from latter commit.
> > >
> > > Anyway I need above commits from sound-2.6.git in my tree...
> > > so how method is better to me instead of cherry-pick it?
> >
> > You can merge topic/asoc branch of sound git tree.
> > This brach contains the all necessary commits for ASoC and is almost
> > never rebased.
>
> Hi,
>
> But I can't merge it because there is no 'topic/asoc' branch in
> sound-2.6.git.
> (git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git)
>
> Is there another repository?
OK, Mark's tree doesn't contain. But you can merge for-2.6.38 tree there.
The main sound git tree is found in
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> And should I merge it in my tree even though don't need all of ASoC commits
> :-( ?
In general yes because this is the tree to be merged to 2.6.38.
> I'm not sure how many commits are in there...
You can keep two branches. One contains only your fixes, and another
is the merged branch from yours and from sound git tree. Expose the
latter merged tree for linux-next.
There are many other ways to manage such things, but the above has
worked for me well, at least.
thanks,
Takashi
Takashi Iwai wrote:
>
(snip)
> > > > Anyway I need above commits from sound-2.6.git in my tree...
> > > > so how method is better to me instead of cherry-pick it?
> > >
> > > You can merge topic/asoc branch of sound git tree.
> > > This brach contains the all necessary commits for ASoC and is almost
> > > never rebased.
> >
> > Hi,
> >
> > But I can't merge it because there is no 'topic/asoc' branch in
> > sound-2.6.git.
> > (git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git)
> >
> > Is there another repository?
>
> OK, Mark's tree doesn't contain. But you can merge for-2.6.38 tree there.
>
> The main sound git tree is found in
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
>
Aha~ :-)
> > And should I merge it in my tree even though don't need all of ASoC
commits
> > :-( ?
>
> In general yes because this is the tree to be merged to 2.6.38.
>
Yeah, I know it.
> > I'm not sure how many commits are in there...
>
> You can keep two branches. One contains only your fixes, and another
> is the merged branch from yours and from sound git tree. Expose the
> latter merged tree for linux-next.
>
Yeah...however, firstly, my tree will be sent to rmk during 38 merge window,
if I merge from sound git, for avoiding build error I should send all
including them not only my patches. I think there is no need to rmk...hmm
So I did 'cherry-pick' only needed 2 commits in my tree.
> There are many other ways to manage such things, but the above has
> worked for me well, at least.
Yeah I think so...but is there another better way in this case? Hehehe...
Anyway Merry Xmas ;-)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <[email protected]>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
On Thu, Dec 23, 2010 at 08:11:56PM +0900, Kukjin Kim wrote:
> Takashi Iwai wrote:
> > > Anyway I need above commits from sound-2.6.git in my tree...
> > > so how method is better to me instead of cherry-pick it?
> > You can merge topic/asoc branch of sound git tree.
> > This brach contains the all necessary commits for ASoC and is almost
> > never rebased.
> But I can't merge it because there is no 'topic/asoc' branch in
> sound-2.6.git.
> (git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git)
> Is there another repository?
topic/asoc is in Takashi's tree and is equivalent to my for-next branch,
it usually lags it by only a small amount. Takashi's tree is at:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> And should I merge it in my tree even though don't need all of ASoC commits
> :-( ?
> I'm not sure how many commits are in there...
There's a lot of stuff in there but it shouldn't do any harm to
pre-merge (and we're almost at the merge window anyway).
On Thu, Dec 23, 2010 at 12:54:26PM +0100, Piotr Hosowicz wrote:
> On 23.12.2010 12:50, Mark Brown wrote:
> >topic/asoc is in Takashi's tree and is equivalent to my for-next branch,
> >it usually lags it by only a small amount. Takashi's tree is at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> Each time I get source from Linus tree I get alsa source from
> Takashi and build the kernel. Should I get the source also from you
> to be up to date with sound source?
Only if you're doing embedded development (my tree is only for embedded
stuff) and then only if you really want the bleeding edge stuff - it's
usually at most a few days before any changes in the embedded branch get
sent to Takashi. If you've never heard of the tree before you probably
don't need it.
On 23.12.2010 12:50, Mark Brown wrote:
>> Is there another repository?
>
> topic/asoc is in Takashi's tree and is equivalent to my for-next branch,
> it usually lags it by only a small amount. Takashi's tree is at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
Each time I get source from Linus tree I get alsa source from Takashi
and build the kernel. Should I get the source also from you to be up to
date with sound source?
Regards and Merry Christmas,
Piotr Hosowicz
--
Babcia rox! :
alek: przyszli do mnie jehowi dzisiaj, otworzy?a babcia
pate_q: i co?
alek: po 30 minutach rozmowy chcieli przej?? na chrze?cija?stwo
NP: Peter Green Splinter Group - Hiding In Shadows
NB: 2.6.37-rc7
At Thu, 23 Dec 2010 20:28:27 +0900,
Kukjin Kim wrote:
>
> Takashi Iwai wrote:
> >
>
> (snip)
>
> > > > > Anyway I need above commits from sound-2.6.git in my tree...
> > > > > so how method is better to me instead of cherry-pick it?
> > > >
> > > > You can merge topic/asoc branch of sound git tree.
> > > > This brach contains the all necessary commits for ASoC and is almost
> > > > never rebased.
> > >
> > > Hi,
> > >
> > > But I can't merge it because there is no 'topic/asoc' branch in
> > > sound-2.6.git.
> > > (git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git)
> > >
> > > Is there another repository?
> >
> > OK, Mark's tree doesn't contain. But you can merge for-2.6.38 tree there.
> >
> > The main sound git tree is found in
> > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> >
> Aha~ :-)
>
> > > And should I merge it in my tree even though don't need all of ASoC
> commits
> > > :-( ?
> >
> > In general yes because this is the tree to be merged to 2.6.38.
> >
> Yeah, I know it.
>
> > > I'm not sure how many commits are in there...
> >
> > You can keep two branches. One contains only your fixes, and another
> > is the merged branch from yours and from sound git tree. Expose the
> > latter merged tree for linux-next.
> >
> Yeah...however, firstly, my tree will be sent to rmk during 38 merge window,
> if I merge from sound git, for avoiding build error I should send all
> including them not only my patches. I think there is no need to rmk...hmm
>
> So I did 'cherry-pick' only needed 2 commits in my tree.
And that caused problems :)
> > There are many other ways to manage such things, but the above has
> > worked for me well, at least.
>
> Yeah I think so...but is there another better way in this case? Hehehe...
Well, ideally, create a separate branch containing these cross-tree
commits based on vanilla. Then pull this branch to both arm (or your)
and sound trees. In that way, both trees share the same commits in
the least amount.
I basically don't like to rebase and the commits have been already in
sound tree, but if this is the only way and Russell prefers this, it
can be a possible option.
thanks,
Takashi
Takashi Iwai wrote:
>
> At Thu, 23 Dec 2010 20:28:27 +0900,
> Kukjin Kim wrote:
> >
> > Takashi Iwai wrote:
> > >
> >
> > (snip)
> >
> > > > > > Anyway I need above commits from sound-2.6.git in my tree...
> > > > > > so how method is better to me instead of cherry-pick it?
> > > > >
> > > > > You can merge topic/asoc branch of sound git tree.
> > > > > This brach contains the all necessary commits for ASoC and is
almost
> > > > > never rebased.
> > > >
> > > > Hi,
> > > >
> > > > But I can't merge it because there is no 'topic/asoc' branch in
> > > > sound-2.6.git.
> > > >
(git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git)
> > > >
> > > > Is there another repository?
> > >
> > > OK, Mark's tree doesn't contain. But you can merge for-2.6.38 tree
there.
> > >
> > > The main sound git tree is found in
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> > >
> > Aha~ :-)
> >
> > > > And should I merge it in my tree even though don't need all of ASoC
> > commits
> > > > :-( ?
> > >
> > > In general yes because this is the tree to be merged to 2.6.38.
> > >
> > Yeah, I know it.
> >
> > > > I'm not sure how many commits are in there...
> > >
> > > You can keep two branches. One contains only your fixes, and another
> > > is the merged branch from yours and from sound git tree. Expose the
> > > latter merged tree for linux-next.
> > >
> > Yeah...however, firstly, my tree will be sent to rmk during 38 merge
window,
> > if I merge from sound git, for avoiding build error I should send all
> > including them not only my patches. I think there is no need to
rmk...hmm
> >
> > So I did 'cherry-pick' only needed 2 commits in my tree.
>
> And that caused problems :)
>
Yup...you're right. As I said, I couldn't suitable some branch for me.
> > > There are many other ways to manage such things, but the above has
> > > worked for me well, at least.
> >
> > Yeah I think so...but is there another better way in this case?
Hehehe...
>
> Well, ideally, create a separate branch containing these cross-tree
> commits based on vanilla. Then pull this branch to both arm (or your)
> and sound trees. In that way, both trees share the same commits in
> the least amount.
>
Yeah...
> I basically don't like to rebase and the commits have been already in
> sound tree, but if this is the only way and Russell prefers this, it
> can be a possible option.
>
I agree with you...now, rebase stuff is unnecessary load to you.
Ok...firstly, need to ask to Russell.
(Added Russell in To)
Hi Russell,
Sorry for bothering...
If possible, please read this thread :-)
So...
May/Should I merge sound tree for avoiding build error and conflict between
each other for 37 merge window instead of cherry-pick?
Or sound maintainer should rebase his tree so that can make some branch
which can support to avoid build error for me?
...Or because Stephen already informed about that so you or Linus can care
just current tree during merge window?
Which one is better to us? Or another method? Please let me know.
Thanks and Merry Christmas everyone :-)
Best regards,
Kgene.
--
Kukjin Kim <[email protected]>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
On Fri, Dec 24, 2010 at 10:32:33AM +0900, Kukjin Kim wrote:
> Takashi Iwai wrote:
> > I basically don't like to rebase and the commits have been already in
> > sound tree, but if this is the only way and Russell prefers this, it
> > can be a possible option.
> >
> I agree with you...now, rebase stuff is unnecessary load to you.
>
> Ok...firstly, need to ask to Russell.
> (Added Russell in To)
>
> Hi Russell,
>
> Sorry for bothering...
> If possible, please read this thread :-)
>
> So...
>
> May/Should I merge sound tree for avoiding build error and conflict between
> each other for 37 merge window instead of cherry-pick?
IMHO it is never appropriate to cherry pick commits from someone elses
tree into your own tree as it creates duplicates in the history.
What would be better is to talk to the person who owns the tree with
the commits you're interested in, and see about merging the minimal
set of commits you need into your own tree. They may tell you the
name of a branch for you to merge into your tree (preferred), or more
obscurely tell you a commit id in their tree.
Now there are two options:
- If you know the branch you need, you can then either pull that branch
into your tree, and commit the dependent patches on top of that.
- If you only have a commit ID in the remote tree, you can fetch their
tree first, use gitk to visualize the history and check you have it,
and then do:
git merge --no-commit <commitid>
in your tree. Then commit the result with your own commit message
explaining what's going on.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
Russell King wrote:
>
> On Fri, Dec 24, 2010 at 10:32:33AM +0900, Kukjin Kim wrote:
> > Takashi Iwai wrote:
> > > I basically don't like to rebase and the commits have been already in
> > > sound tree, but if this is the only way and Russell prefers this, it
> > > can be a possible option.
> > >
> > I agree with you...now, rebase stuff is unnecessary load to you.
> >
> > Ok...firstly, need to ask to Russell.
> > (Added Russell in To)
> >
> > Hi Russell,
> >
> > Sorry for bothering...
> > If possible, please read this thread :-)
> >
> > So...
> >
> > May/Should I merge sound tree for avoiding build error and conflict
between
> > each other for 37 merge window instead of cherry-pick?
>
Russell, thanks for your reply :-)
> IMHO it is never appropriate to cherry pick commits from someone elses
> tree into your own tree as it creates duplicates in the history.
>
Absolutely, you're right. I missed.
> What would be better is to talk to the person who owns the tree with
> the commits you're interested in, and see about merging the minimal
> set of commits you need into your own tree. They may tell you the
> name of a branch for you to merge into your tree (preferred), or more
> obscurely tell you a commit id in their tree.
>
Yeah, would be nice to me ;-)
> Now there are two options:
> - If you know the branch you need, you can then either pull that branch
> into your tree, and commit the dependent patches on top of that.
>
Unfortunately, as I know, there is no suitable branch for it and me in
sound-2.6 tree now :-(
> - If you only have a commit ID in the remote tree, you can fetch their
> tree first, use gitk to visualize the history and check you have it,
> and then do:
> git merge --no-commit <commitid>
> in your tree. Then commit the result with your own commit message
> explaining what's going on.
>
Hmm...happened error when merged but I don't know how can solve that :-(
IMHO, your first option is better to me but it depends on Takashi...hehe...
Anyway Thanks and Happy New year!
Takashi, as Russell's first option, could you please make some branch which
includes following to me?
Of course, I know you need rebase you tree for it...so sorry for bothering.
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
#topic/asoc
commit 83e37b8e400ca51cc97946815b3055daacd92fa8
Author: Jassi Brar <[email protected]>
Date: Mon Nov 22 15:35:53 2010 +0900
ARM: Samsung: Define common audio-dma device
The ASoC uses common DMA driver for Audio devices. So it makes
sense to a common audio-dma device shared across all platforms.
Signed-off-by: Jassi Brar <[email protected]>
Acked-by: Kukjin Kim <[email protected]>
Acked-by: Liam Girdwood <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
commit 58bb4072132c54d832082cc6eac396a6db009cbd
Author: Jassi Brar <[email protected]>
Date: Mon Nov 22 15:35:50 2010 +0900
ASoC: Samsung: Rename DMA device
Some Samsung SoCs have a PCM(DSP) controller. So the name
s3c24xx-pcm-audio for DMA driver is not very appropraite.
This patch moves :-
s3c24xx-pcm-audio -> samsung-audio
Signed-off-by: Jassi Brar <[email protected]>
Acked-by: Kukjin Kim <[email protected]>
Acked-by: Liam Girdwood <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Please let me know your opinion.
Happy New year ;-)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <[email protected]>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
On Tue, Dec 28, 2010 at 11:24:49AM +0900, Kukjin Kim wrote:
> Takashi, as Russell's first option, could you please make some branch which
> includes following to me?
Please keep myself and Liam in the CC on all ASoC discussion.
> Of course, I know you need rebase you tree for it...so sorry for bothering.
This isn't going to help as it will just introduce the same duplicate
commits issue into the sound tree. I'm still not clear what the
affected commits actually are but given that Stephen's original report
indicated that the ASoC changes are subsets of your changes would it not
make sense to just drop the relevant commits from your tree (which seems
to be rebased often, unlike the sound tree which doesn't rebase)?
Another option is to do a second round of merges after both sound and
ALSA trees with whatever the dependant commits are.
On Tue, Dec 28, 2010 at 03:39:48PM +0000, Mark Brown wrote:
> On Tue, Dec 28, 2010 at 11:24:49AM +0900, Kukjin Kim wrote:
>
> > Takashi, as Russell's first option, could you please make some branch which
> > includes following to me?
>
> Please keep myself and Liam in the CC on all ASoC discussion.
You weren't included on Stephen's email. Have you told Stephen which
files he needs to notify you about? I suspect Stephen operates by
notifying the people who's trees clash, rather than selecting people
based on files.
> > Of course, I know you need rebase you tree for it...so sorry for bothering.
>
> This isn't going to help as it will just introduce the same duplicate
> commits issue into the sound tree. I'm still not clear what the
> affected commits actually are but given that Stephen's original report
> indicated that the ASoC changes are subsets of your changes would it not
> make sense to just drop the relevant commits from your tree (which seems
> to be rebased often, unlike the sound tree which doesn't rebase)?
I don't think you read what I said (you probably didn't even see it.)
What Kukjin has already done is looked in the ALSA tree, extracted the
commits he wants from it, committed those into his tree, and based a
pile of work on top of that.
I said "don't do that" because it creates unnecessary duplications in
the git history. I suggested that if Kukjin needs commits from the ALSA
tree, he asks the ALSA people for a commit in their tree to pull into
his tree to base his code on instead.
> Another option is to do a second round of merges after both sound and
> ALSA trees with whatever the dependant commits are.
If Kukjin has code which requires commits from the ALSA tree, and he
doesn't have the ALSA tree, he can't build-test the code in his tree.
Are you really suggesting that people should keep un-build-tested code
in their trees, and push that un-tested code upstream when the dependent
trees have merged? Are you really suggesting that swathes of commits
should not be bisectable?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, Dec 28, 2010 at 04:23:30PM +0000, Russell King wrote:
> On Tue, Dec 28, 2010 at 03:39:48PM +0000, Mark Brown wrote:
> > Please keep myself and Liam in the CC on all ASoC discussion.
> You weren't included on Stephen's email. Have you told Stephen which
> files he needs to notify you about? I suspect Stephen operates by
> notifying the people who's trees clash, rather than selecting people
> based on files.
I suspect so too; the file patterns in MAINTAINERS cover it otherwise
(and originally the ASoC tree was actually getting merged first so the
right thing would've happened anyway).
> > > Of course, I know you need rebase you tree for it...so sorry for bothering.
> > This isn't going to help as it will just introduce the same duplicate
> > commits issue into the sound tree. I'm still not clear what the
> > affected commits actually are but given that Stephen's original report
> > indicated that the ASoC changes are subsets of your changes would it not
> > make sense to just drop the relevant commits from your tree (which seems
> > to be rebased often, unlike the sound tree which doesn't rebase)?
> I don't think you read what I said (you probably didn't even see it.)
> What Kukjin has already done is looked in the ALSA tree, extracted the
> commits he wants from it, committed those into his tree, and based a
> pile of work on top of that.
Right, but looking at Stephen's original mail it seems like the bits
that are conflicting here are two different commits in the ASoC and
Samsung code where the ASoC version is a superset of the Samsung side
set. If that analysis is correct then the ASoC commits will do the
right thing once they turn up in the Samsung tree so unless there's a
pressing reason for the Samsung versions they could just be dropped for
the time being.
> I said "don't do that" because it creates unnecessary duplications in
> the git history. I suggested that if Kukjin needs commits from the ALSA
> tree, he asks the ALSA people for a commit in their tree to pull into
> his tree to base his code on instead.
Yes, which due to the lack of rebasing is hard to arrange except by
merging all of ASoC en masse (which someone already suggested).
> > Another option is to do a second round of merges after both sound and
> > ALSA trees with whatever the dependant commits are.
> If Kukjin has code which requires commits from the ALSA tree, and he
> doesn't have the ALSA tree, he can't build-test the code in his tree.
> Are you really suggesting that people should keep un-build-tested code
> in their trees, and push that un-tested code upstream when the dependent
> trees have merged? Are you really suggesting that swathes of commits
> should not be bisectable?
No, I'm suggesting that a separate branch be maintained with the
affected commits which gets rebased and tested against -next or whatever
until everything they need hits the tree they need to be merged via.
The bulk of things go in as normal, then the extra commits are added in
a second merge later. This is often required for practical testing when
there's a lot of work going on over the tree, even if it can be split up
neatly for merge.
This is annoying if it goes on for a long time but given that Linus is
likely to release this week that shouldn't be the case, and it assumes
the set of affected changes is small. As I've no idea why the Samsung
side of the changes is there I don't know if that is the case or not.
Happy New year everyone :-)
Firstly, thanks for Russell and Mark.
Hmm...
I thought it's very simple, but it is not. Because needs some peoples'
another work :-(
Anyway, so I decided that will drop/change some commits which occur conflict
between sound tree and build error in my tree. Already discussed about that
with Jassi and he agreed.
Then if possible, will send remained small stuff to Linus during -rc.
Thank you so much again ;-)
Best regards,
Kgene.
--
Kukjin Kim <[email protected]>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
Mark Brown wrote:
> On Tue, Dec 28, 2010 at 04:23:30PM +0000, Russell King wrote:
> > On Tue, Dec 28, 2010 at 03:39:48PM +0000, Mark Brown wrote:
>
> > > Please keep myself and Liam in the CC on all ASoC discussion.
>
> > You weren't included on Stephen's email. Have you told Stephen which
> > files he needs to notify you about? I suspect Stephen operates by
> > notifying the people who's trees clash, rather than selecting people
> > based on files.
>
> I suspect so too; the file patterns in MAINTAINERS cover it otherwise
> (and originally the ASoC tree was actually getting merged first so the
> right thing would've happened anyway).
>
> > > > Of course, I know you need rebase you tree for it...so sorry for
> bothering.
>
> > > This isn't going to help as it will just introduce the same duplicate
> > > commits issue into the sound tree. I'm still not clear what the
> > > affected commits actually are but given that Stephen's original report
> > > indicated that the ASoC changes are subsets of your changes would it
not
> > > make sense to just drop the relevant commits from your tree (which
seems
> > > to be rebased often, unlike the sound tree which doesn't rebase)?
>
> > I don't think you read what I said (you probably didn't even see it.)
>
> > What Kukjin has already done is looked in the ALSA tree, extracted the
> > commits he wants from it, committed those into his tree, and based a
> > pile of work on top of that.
>
> Right, but looking at Stephen's original mail it seems like the bits
> that are conflicting here are two different commits in the ASoC and
> Samsung code where the ASoC version is a superset of the Samsung side
> set. If that analysis is correct then the ASoC commits will do the
> right thing once they turn up in the Samsung tree so unless there's a
> pressing reason for the Samsung versions they could just be dropped for
> the time being.
>
> > I said "don't do that" because it creates unnecessary duplications in
> > the git history. I suggested that if Kukjin needs commits from the ALSA
> > tree, he asks the ALSA people for a commit in their tree to pull into
> > his tree to base his code on instead.
>
> Yes, which due to the lack of rebasing is hard to arrange except by
> merging all of ASoC en masse (which someone already suggested).
>
> > > Another option is to do a second round of merges after both sound and
> > > ALSA trees with whatever the dependant commits are.
>
> > If Kukjin has code which requires commits from the ALSA tree, and he
> > doesn't have the ALSA tree, he can't build-test the code in his tree.
> > Are you really suggesting that people should keep un-build-tested code
> > in their trees, and push that un-tested code upstream when the dependent
> > trees have merged? Are you really suggesting that swathes of commits
> > should not be bisectable?
>
> No, I'm suggesting that a separate branch be maintained with the
> affected commits which gets rebased and tested against -next or whatever
> until everything they need hits the tree they need to be merged via.
> The bulk of things go in as normal, then the extra commits are added in
> a second merge later. This is often required for practical testing when
> there's a lot of work going on over the tree, even if it can be split up
> neatly for merge.
>
> This is annoying if it goes on for a long time but given that Linus is
> likely to release this week that shouldn't be the case, and it assumes
> the set of affected changes is small. As I've no idea why the Samsung
> side of the changes is there I don't know if that is the case or not.