[alsa-devel] More HDA NID / control / proc related changes
Hi all,
continuing the work of extending the HDA codec proc contents, I would like to introduce two new patches:
ALSA: hda - add more NID->Control mapping ALSA: hda - introduce HDA_SUBDEV_AMP_FLAG (ControlAmp in proc)
Patches can be obtained here:
http://git.alsa-project.org/?p=alsa-kernel.git;a=shortlog;h=topic/hda-nid
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Tue, 8 Dec 2009, Jaroslav Kysela wrote:
Hi all,
continuing the work of extending the HDA codec proc contents, I would like to introduce two new patches:
ALSA: hda - add more NID->Control mapping ALSA: hda - introduce HDA_SUBDEV_AMP_FLAG (ControlAmp in proc)
Patches can be obtained here:
http://git.alsa-project.org/?p=alsa-kernel.git;a=shortlog;h=topic/hda-nid
I merged these patches and added patch named:
ALSA: hda - simplify usage of HDA_SUBDEV_AMP_FLAG
.. to my main GIT tree.
The next idea is to modify hda-analyzer to show the codec routes and assigned mixer controls.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Mon, 14 Dec 2009 09:46:50 +0100 (CET), Jaroslav Kysela wrote:
On Tue, 8 Dec 2009, Jaroslav Kysela wrote:
Hi all,
continuing the work of extending the HDA codec proc contents, I would like to introduce two new patches:
ALSA: hda - add more NID->Control mapping ALSA: hda - introduce HDA_SUBDEV_AMP_FLAG (ControlAmp in proc)
Patches can be obtained here:
http://git.alsa-project.org/?p=alsa-kernel.git;a=shortlog;h=topic/hda-nid
I merged these patches and added patch named:
ALSA: hda - simplify usage of HDA_SUBDEV_AMP_FLAG
.. to my main GIT tree.
The next idea is to modify hda-analyzer to show the codec routes and assigned mixer controls.
snd_hda_add_nids() looks buggy to me. It doesn't increment nids pointer.
Also, snd_hda_add_nids() and snd_hda_nid_add() are a bit confusing and inconsistent, IMO.
Anyway, it'd be really, really helpful if you make a proper pullable branch based on the upstream tree. Right now I can't pull your commits but only do cherry-picks, which is basically stupid when both are using GIT.
thanks,
Takashi
On Mon, 14 Dec 2009, Takashi Iwai wrote:
At Mon, 14 Dec 2009 09:46:50 +0100 (CET), Jaroslav Kysela wrote:
On Tue, 8 Dec 2009, Jaroslav Kysela wrote:
Hi all,
continuing the work of extending the HDA codec proc contents, I would like to introduce two new patches:
ALSA: hda - add more NID->Control mapping ALSA: hda - introduce HDA_SUBDEV_AMP_FLAG (ControlAmp in proc)
Patches can be obtained here:
http://git.alsa-project.org/?p=alsa-kernel.git;a=shortlog;h=topic/hda-nid
I merged these patches and added patch named:
ALSA: hda - simplify usage of HDA_SUBDEV_AMP_FLAG
.. to my main GIT tree.
The next idea is to modify hda-analyzer to show the codec routes and assigned mixer controls.
snd_hda_add_nids() looks buggy to me. It doesn't increment nids pointer.
Good point. Fixed now.
Also, snd_hda_add_nids() and snd_hda_nid_add() are a bit confusing and inconsistent, IMO.
It is consistent with ctl functions:
snd_hda_ctl_add -> snd_hda_nid_add snd_hda_add_new_ctls -> snd_hda_add_nids
Anyway, it'd be really, really helpful if you make a proper pullable branch based on the upstream tree. Right now I can't pull your commits but only do cherry-picks, which is basically stupid when both are using GIT.
I found the possible changes (resolving clashes) during merges very evil, altough I understand your easy work scheme. Also, I don't like the missing lines in comments (Signed-off-by etc.) for merged patches for all involved people. It makes more difficult to track the patch flow.
My topic/hda-nid branch is now based on your master tree.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Mon, 14 Dec 2009 13:34:19 +0100 (CET), Jaroslav Kysela wrote:
On Mon, 14 Dec 2009, Takashi Iwai wrote:
At Mon, 14 Dec 2009 09:46:50 +0100 (CET), Jaroslav Kysela wrote:
On Tue, 8 Dec 2009, Jaroslav Kysela wrote:
Hi all,
continuing the work of extending the HDA codec proc contents, I would like to introduce two new patches:
ALSA: hda - add more NID->Control mapping ALSA: hda - introduce HDA_SUBDEV_AMP_FLAG (ControlAmp in proc)
Patches can be obtained here:
http://git.alsa-project.org/?p=alsa-kernel.git;a=shortlog;h=topic/hda-nid
I merged these patches and added patch named:
ALSA: hda - simplify usage of HDA_SUBDEV_AMP_FLAG
.. to my main GIT tree.
The next idea is to modify hda-analyzer to show the codec routes and assigned mixer controls.
snd_hda_add_nids() looks buggy to me. It doesn't increment nids pointer.
Good point. Fixed now.
Also, snd_hda_add_nids() and snd_hda_nid_add() are a bit confusing and inconsistent, IMO.
It is consistent with ctl functions:
snd_hda_ctl_add -> snd_hda_nid_add snd_hda_add_new_ctls -> snd_hda_add_nids
Ah. But both function names look too similar, I'd say, and the relationship above can't be seen obviously from the names.
Anyway, it'd be really, really helpful if you make a proper pullable branch based on the upstream tree. Right now I can't pull your commits but only do cherry-picks, which is basically stupid when both are using GIT.
I found the possible changes (resolving clashes) during merges very evil, altough I understand your easy work scheme.
Right. IOW, the commits that have been already published for the public tree shouldn't be rebased. The rebasing is the most evil thing for the published commits.
Rebasing doesn't matter for local commits, of course. Also, it's also more or less OK for some test trees / branches. But, never rebase if a branch gets merged.
Also, I don't like the missing lines in comments (Signed-off-by etc.) for merged patches for all involved people. It makes more difficult to track the patch flow.
Well, the meta info has to be set properly *before* merge. So, the only question is whether a developed branch is ready for merging or not...
If your topic/hda-nid branch isn't ready for merging, I don't care right now :)
My topic/hda-nid branch is now based on your master tree.
Thanks.
Takashi
On Mon, 14 Dec 2009, Takashi Iwai wrote:
At Mon, 14 Dec 2009 13:34:19 +0100 (CET), Jaroslav Kysela wrote:
On Mon, 14 Dec 2009, Takashi Iwai wrote:
At Mon, 14 Dec 2009 09:46:50 +0100 (CET), Jaroslav Kysela wrote:
On Tue, 8 Dec 2009, Jaroslav Kysela wrote:
Hi all,
continuing the work of extending the HDA codec proc contents, I would like to introduce two new patches:
ALSA: hda - add more NID->Control mapping ALSA: hda - introduce HDA_SUBDEV_AMP_FLAG (ControlAmp in proc)
Patches can be obtained here:
http://git.alsa-project.org/?p=alsa-kernel.git;a=shortlog;h=topic/hda-nid
I merged these patches and added patch named:
ALSA: hda - simplify usage of HDA_SUBDEV_AMP_FLAG
.. to my main GIT tree.
The next idea is to modify hda-analyzer to show the codec routes and assigned mixer controls.
snd_hda_add_nids() looks buggy to me. It doesn't increment nids pointer.
Good point. Fixed now.
Also, snd_hda_add_nids() and snd_hda_nid_add() are a bit confusing and inconsistent, IMO.
It is consistent with ctl functions:
snd_hda_ctl_add -> snd_hda_nid_add snd_hda_add_new_ctls -> snd_hda_add_nids
Ah. But both function names look too similar, I'd say, and the relationship above can't be seen obviously from the names.
Any idea to rename functions?
Anyway, it'd be really, really helpful if you make a proper pullable branch based on the upstream tree. Right now I can't pull your commits but only do cherry-picks, which is basically stupid when both are using GIT.
I found the possible changes (resolving clashes) during merges very evil, altough I understand your easy work scheme.
Right. IOW, the commits that have been already published for the public tree shouldn't be rebased. The rebasing is the most evil thing for the published commits.
Rebasing doesn't matter for local commits, of course. Also, it's also more or less OK for some test trees / branches. But, never rebase if a branch gets merged.
Also, I don't like the missing lines in comments (Signed-off-by etc.) for merged patches for all involved people. It makes more difficult to track the patch flow.
Well, the meta info has to be set properly *before* merge. So, the only question is whether a developed branch is ready for merging or not...
Unfortunately, I'm not talking about the meta-info. The patch delivery should be in the patch comment itself according to the SubmittingPatches document. For example:
commit 761c9d45d14e0afa3c0b8eb84b4075602e50533b Author: Olof Johansson olof@lixom.net Date: Thu Dec 10 11:15:55 2009 -0600
ASoC: Fix build of OMAP sound drivers
.... Reported-by: Anand Gadiyar gadiyar@ti.com Signed-off-by: Olof Johansson olof@lixom.net Acked-by: Liam Girdwood lrg@slimlogic.co.uk Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com
Where's your Signed-off-by: line? You rely on the SCM system to obtain this information from the 'Merge' commit. I don't think that it's good. Even if you do rebasing, you can have a clean repository. Just ommit git fancy merging and you'll see that you can work with patches in same way as in CVS or other "old" SCMs. I think that ONLY stable "fixed" commits should be in the Linus's tree and our patches should be commited as cleanly as possible with whole relevant information.
It's also about accepting the 'git pull' requests. If we accept the 'git format-patch' output via e-mail only , we can add appropriate information to the patch comment and the patches are valid without any requirement to know the "patch base" in the GIT repository.
The same rule should be applied to local branches - when merging, the contents should be cherry picked.
If your topic/hda-nid branch isn't ready for merging, I don't care right now :)
It is ready (if you accept current function names).
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Mon, 14 Dec 2009 15:32:54 +0100 (CET), Jaroslav Kysela wrote:
On Mon, 14 Dec 2009, Takashi Iwai wrote:
At Mon, 14 Dec 2009 13:34:19 +0100 (CET), Jaroslav Kysela wrote:
On Mon, 14 Dec 2009, Takashi Iwai wrote:
At Mon, 14 Dec 2009 09:46:50 +0100 (CET), Jaroslav Kysela wrote:
On Tue, 8 Dec 2009, Jaroslav Kysela wrote:
Hi all,
continuing the work of extending the HDA codec proc contents, I would like to introduce two new patches:
ALSA: hda - add more NID->Control mapping ALSA: hda - introduce HDA_SUBDEV_AMP_FLAG (ControlAmp in proc)
Patches can be obtained here:
http://git.alsa-project.org/?p=alsa-kernel.git;a=shortlog;h=topic/hda-nid
I merged these patches and added patch named:
ALSA: hda - simplify usage of HDA_SUBDEV_AMP_FLAG
.. to my main GIT tree.
The next idea is to modify hda-analyzer to show the codec routes and assigned mixer controls.
snd_hda_add_nids() looks buggy to me. It doesn't increment nids pointer.
Good point. Fixed now.
Also, snd_hda_add_nids() and snd_hda_nid_add() are a bit confusing and inconsistent, IMO.
It is consistent with ctl functions:
snd_hda_ctl_add -> snd_hda_nid_add snd_hda_add_new_ctls -> snd_hda_add_nids
Ah. But both function names look too similar, I'd say, and the relationship above can't be seen obviously from the names.
Any idea to rename functions?
Nor particular in mind, but I'd name like snd_hda_ctl_add_nid() if it's for snd_hda_ctl_add().
Or, use the same name snd_hda_add_nid() and snd_hda_add_nids(), unify the argument order, but make the latter accept array, or so.
Anyway, it'd be really, really helpful if you make a proper pullable branch based on the upstream tree. Right now I can't pull your commits but only do cherry-picks, which is basically stupid when both are using GIT.
I found the possible changes (resolving clashes) during merges very evil, altough I understand your easy work scheme.
Right. IOW, the commits that have been already published for the public tree shouldn't be rebased. The rebasing is the most evil thing for the published commits.
Rebasing doesn't matter for local commits, of course. Also, it's also more or less OK for some test trees / branches. But, never rebase if a branch gets merged.
Also, I don't like the missing lines in comments (Signed-off-by etc.) for merged patches for all involved people. It makes more difficult to track the patch flow.
Well, the meta info has to be set properly *before* merge. So, the only question is whether a developed branch is ready for merging or not...
Unfortunately, I'm not talking about the meta-info. The patch delivery should be in the patch comment itself according to the SubmittingPatches document. For example:
commit 761c9d45d14e0afa3c0b8eb84b4075602e50533b Author: Olof Johansson olof@lixom.net Date: Thu Dec 10 11:15:55 2009 -0600
ASoC: Fix build of OMAP sound drivers .... Reported-by: Anand Gadiyar <gadiyar@ti.com> Signed-off-by: Olof Johansson <olof@lixom.net> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>Where's your Signed-off-by: line? You rely on the SCM system to obtain this information from the 'Merge' commit. I don't think that it's good.
This is fully normal. Do you see sign-off in each pull by Linus? Many trees with sub-trees or sub-projects are done in that way. See x86 tree, for example.
thanks,
Takashi
On Mon, 14 Dec 2009, Takashi Iwai wrote:
Or, use the same name snd_hda_add_nid() and snd_hda_add_nids(), unify the argument order, but make the latter accept array, or so.
Renamed in this way. Please, check topic/hda-nid or for-next branch.
branch based on the upstream tree. Right now I can't pull your commits but only do cherry-picks, which is basically stupid when both are using GIT.
I found the possible changes (resolving clashes) during merges very evil, altough I understand your easy work scheme.
Right. IOW, the commits that have been already published for the public tree shouldn't be rebased. The rebasing is the most evil thing for the published commits.
Rebasing doesn't matter for local commits, of course. Also, it's also more or less OK for some test trees / branches. But, never rebase if a branch gets merged.
Also, I don't like the missing lines in comments (Signed-off-by etc.) for merged patches for all involved people. It makes more difficult to track the patch flow.
Well, the meta info has to be set properly *before* merge. So, the only question is whether a developed branch is ready for merging or not...
Unfortunately, I'm not talking about the meta-info. The patch delivery should be in the patch comment itself according to the SubmittingPatches document. For example:
commit 761c9d45d14e0afa3c0b8eb84b4075602e50533b Author: Olof Johansson olof@lixom.net Date: Thu Dec 10 11:15:55 2009 -0600
ASoC: Fix build of OMAP sound drivers .... Reported-by: Anand Gadiyar <gadiyar@ti.com> Signed-off-by: Olof Johansson <olof@lixom.net> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>Where's your Signed-off-by: line? You rely on the SCM system to obtain this information from the 'Merge' commit. I don't think that it's good.
This is fully normal. Do you see sign-off in each pull by Linus?
Linus should be only exception, because this patch route is quite obvious.
Many trees with sub-trees or sub-projects are done in that way. See x86 tree, for example.
It does not mean that it's the correct way.
Anyway, I created for-next branch in my repository. Could you import changes without explicitly asking if you do not have any comments? I'll merge patches from Clemens there as well.
Thanks, Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Mon, Dec 14, 2009 at 04:45:18PM +0100, Jaroslav Kysela wrote:
On Mon, 14 Dec 2009, Takashi Iwai wrote:
Where's your Signed-off-by: line? You rely on the SCM system to obtain this information from the 'Merge' commit. I don't think that it's good.
This is fully normal. Do you see sign-off in each pull by Linus?
Linus should be only exception, because this patch route is quite obvious.
Many trees with sub-trees or sub-projects are done in that way. See x86 tree, for example.
It does not mean that it's the correct way.
It's been discussed relatively often on the lists - the general position is that so long as the last person to sign off is the person who created the actual commit everything is fine. If the commit gets changed (as a result of a rebase or whatever) then you need to add a new signoff but otherwise we can be sure that the commit will not have changed since the SHA1 would change if there were changes so there's no question of any licensing issues.
At Mon, 14 Dec 2009 16:45:18 +0100 (CET), Jaroslav Kysela wrote:
Anyway, I created for-next branch in my repository. Could you import changes without explicitly asking if you do not have any comments? I'll merge patches from Clemens there as well.
Could you rebase it rather on the latest Linus tree instead? Or, rebase it on topic/hda branch I opened now for 2.6.34 development.
My master branch is for the development tip, and its merge history is pretty messy. Ditto for for-next branch. It contains lots of unneeded merge commits. The merge history gets straightened when backed to for-linus branch.
If your changes are only for HD-audio, then you can branch from either fix/hda or topic/hda branch in my tree. The former is for the current kernel and the latter for the next kernel. For ASoC, fix/asoc and topic/asoc, and for others, fix/misc and topic/misc branches are available for (relatively) straight history.
I cherry-pick'ed the last commit of Clemens to topic/misc. So I'd need only your topic/hda-nid branch for merge.
thanks,
Takashi
On Mon, 14 Dec 2009, Takashi Iwai wrote:
At Mon, 14 Dec 2009 16:45:18 +0100 (CET), Jaroslav Kysela wrote:
Anyway, I created for-next branch in my repository. Could you import changes without explicitly asking if you do not have any comments? I'll merge patches from Clemens there as well.
Could you rebase it rather on the latest Linus tree instead? Or, rebase it on topic/hda branch I opened now for 2.6.34 development.
My master branch is for the development tip, and its merge history is pretty messy. Ditto for for-next branch. It contains lots of unneeded merge commits. The merge history gets straightened when backed to for-linus branch.
If your changes are only for HD-audio, then you can branch from either fix/hda or topic/hda branch in my tree. The former is for the current kernel and the latter for the next kernel. For ASoC, fix/asoc and topic/asoc, and for others, fix/misc and topic/misc branches are available for (relatively) straight history.
I cherry-pick'ed the last commit of Clemens to topic/misc. So I'd need only your topic/hda-nid branch for merge.
Ok, I would propose a bit different approach. I created two new branches in my tree:
fixes - for current kernel devel - for next kernel
To avoid too many merges, I would like that you pull from these branches only when you compose the changeset for Linus (fixes) or for your next kernel (master branch - pull from fixes+devel). In case of problems or comments, I will fix them with new patch (so, in these trees, my patches will have stable SHA keys).
Do you think that it will work for you?
Thanks, Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Tue, 15 Dec 2009, Jaroslav Kysela wrote:
On Mon, 14 Dec 2009, Takashi Iwai wrote:
At Mon, 14 Dec 2009 16:45:18 +0100 (CET), Jaroslav Kysela wrote:
Anyway, I created for-next branch in my repository. Could you import changes without explicitly asking if you do not have any comments? I'll merge patches from Clemens there as well.
Could you rebase it rather on the latest Linus tree instead? Or, rebase it on topic/hda branch I opened now for 2.6.34 development.
My master branch is for the development tip, and its merge history is pretty messy. Ditto for for-next branch. It contains lots of unneeded merge commits. The merge history gets straightened when backed to for-linus branch.
If your changes are only for HD-audio, then you can branch from either fix/hda or topic/hda branch in my tree. The former is for the current kernel and the latter for the next kernel. For ASoC, fix/asoc and topic/asoc, and for others, fix/misc and topic/misc branches are available for (relatively) straight history.
I cherry-pick'ed the last commit of Clemens to topic/misc. So I'd need only your topic/hda-nid branch for merge.
Ok, I would propose a bit different approach. I created two new branches in my tree:
fixes - for current kernel devel - for next kernel
To avoid too many merges, I would like that you pull from these branches only when you compose the changeset for Linus (fixes) or for your next
^^^^
Should be mostly. Of course, if our changes depends on changes in different trees, we have to merge before.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Tue, 15 Dec 2009 09:42:04 +0100 (CET), Jaroslav Kysela wrote:
On Mon, 14 Dec 2009, Takashi Iwai wrote:
At Mon, 14 Dec 2009 16:45:18 +0100 (CET), Jaroslav Kysela wrote:
Anyway, I created for-next branch in my repository. Could you import changes without explicitly asking if you do not have any comments? I'll merge patches from Clemens there as well.
Could you rebase it rather on the latest Linus tree instead? Or, rebase it on topic/hda branch I opened now for 2.6.34 development.
My master branch is for the development tip, and its merge history is pretty messy. Ditto for for-next branch. It contains lots of unneeded merge commits. The merge history gets straightened when backed to for-linus branch.
If your changes are only for HD-audio, then you can branch from either fix/hda or topic/hda branch in my tree. The former is for the current kernel and the latter for the next kernel. For ASoC, fix/asoc and topic/asoc, and for others, fix/misc and topic/misc branches are available for (relatively) straight history.
I cherry-pick'ed the last commit of Clemens to topic/misc. So I'd need only your topic/hda-nid branch for merge.
Ok, I would propose a bit different approach. I created two new branches in my tree:
fixes - for current kernel devel - for next kernel
To avoid too many merges, I would like that you pull from these branches only when you compose the changeset for Linus (fixes) or for your next kernel (master branch - pull from fixes+devel). In case of problems or comments, I will fix them with new patch (so, in these trees, my patches will have stable SHA keys).
Do you think that it will work for you?
Yep, that'll be fine.
BTW, I found Steve's ac97 patch in your fix branch. I haven't applied it just because 5 seconds don't look like a "right" fix. Though, it will unlikely regress on other hardwares, it's OK to just take it as a "workaround"... I'll merge that tree, too.
thanks,
Takashi
participants (3)
-
Jaroslav Kysela -
Mark Brown -
Takashi Iwai