Re: [alsa-devel] [PATCH 03/11] wss_lib: rename cs4321_foo to wss_foo
On 31-07-08 21:03, Krzysztof Helt wrote:
Takashi, you already applied these but is it possible to still get my Acked-by (or Reviewed-by, whatever you want) on them? When a problem is bisected to one of these, people tend to put the people in the patch tags in CC and I looked at them and would like to be informed of any trouble. I tested most users by now, and we'll get the azt2320 fixed before this hits the streets but I still like to be in the loop on any traffic concerning them.
Acked-by: Rene Herman rene.herman@gmail.com
(or Reviewed-by, Tested-by, ...)
Below comments not important:
@@ -679,23 +679,25 @@ static int __devinit snd_opl3sa2_probe(s
[ ... ]
- chip->cs4231 = cs4231;
- if ((err = snd_cs4231_pcm(cs4231, 0, NULL)) < 0)
- chip->wss = wss;
- err = snd_wss_pcm(wss, 0, NULL);
- if (err < 0) return err;
- if ((err = snd_cs4231_mixer(cs4231)) < 0)
- err = snd_wss_mixer(wss);
- if (err < 0) return err; if ((err = snd_opl3sa2_mixer(chip)) < 0) return err;
<mumble>
- if ((err = snd_cs4231_timer(cs4231, 0, NULL)) < 0)
- err = snd_wss_timer(wss, 0, NULL);
- if (err < 0) return err;
[ ... ]
+static void snd_wss_debug(struct snd_wss *chip)
- printk(KERN_DEBUG
" 0x00: left input = 0x%02x "
" 0x10: alt 1 (CFIG 2) = 0x%02x\n",
snd_wss_in(chip, 0x00),
snd_wss_in(chip, 0x10));
- printk(KERN_DEBUG
" 0x01: right input = 0x%02x "
" 0x11: alt 2 (CFIG 3) = 0x%02x\n",
snd_wss_in(chip, 0x01),
snd_wss_in(chip, 0x11));
I'll admit that's actually half-way passable...
@@ -553,79 +628,88 @@ static void snd_wss_playback_format(s
[ ... ]
if (full_calib) {
snd_cs4231_mce_up(chip);
spin_lock_irqsave(&chip->reg_lock, flags);snd_wss_mce_up(chip);
if (chip->hardware != CS4231_HW_INTERWAVE && !chip->single_dma) {
snd_cs4231_out(chip, CS4231_PLAYBK_FORMAT,
(chip->image[CS4231_IFACE_CTRL] & CS4231_RECORD_ENABLE) ?
(pdfr & 0xf0) | (chip->image[CS4231_REC_FORMAT] & 0x0f) :
pdfr);
if (chip->hardware != WSS_HW_INTERWAVE && !chip->single_dma) {
if (chip->image[CS4231_IFACE_CTRL] & CS4231_RECORD_ENABLE)
pdfr = (pdfr & 0xf0) |
} else {(chip->image[CS4231_REC_FORMAT] & 0x0f);
snd_cs4231_out(chip, CS4231_PLAYBK_FORMAT, chip->image[CS4231_PLAYBK_FORMAT] = pdfr);
}chip->image[CS4231_PLAYBK_FORMAT] = pdfr;
spin_unlock_irqrestore(&chip->reg_lock, flags);snd_wss_out(chip, CS4231_PLAYBK_FORMAT, pdfr);
Much beter.
+static void snd_wss_capture_format(struct snd_wss *chip,
[ ... ]
snd_cs4231_out(chip, CS4231_ALT_FEATURE_1, chip->image[CS4231_ALT_FEATURE_1] | 0x20);
snd_cs4231_out(chip, CS4231_REC_FORMAT, chip->image[CS4231_REC_FORMAT] = cdfr);
snd_cs4231_out(chip, CS4231_ALT_FEATURE_1, chip->image[CS4231_ALT_FEATURE_1] &= ~0x20);
snd_wss_out(chip, CS4231_ALT_FEATURE_1,
chip->image[CS4231_ALT_FEATURE_1] | 0x20);
snd_wss_out(chip, CS4231_REC_FORMAT,
chip->image[CS4231_REC_FORMAT] = cdfr);
Not much better...
snd_wss_out(chip, CS4231_ALT_FEATURE_1,
chip->image[CS4231_ALT_FEATURE_1] &= ~0x20);
Same level of betterness.
Rene.
At Tue, 05 Aug 2008 05:41:01 +0200, Rene Herman wrote:
On 31-07-08 21:03, Krzysztof Helt wrote:
Takashi, you already applied these but is it possible to still get my Acked-by (or Reviewed-by, whatever you want) on them? When a problem is bisected to one of these, people tend to put the people in the patch tags in CC and I looked at them and would like to be informed of any trouble. I tested most users by now, and we'll get the azt2320 fixed before this hits the streets but I still like to be in the loop on any traffic concerning them.
Acked-by: Rene Herman rene.herman@gmail.com
(or Reviewed-by, Tested-by, ...)
I've changed the tree structure in my git repo, so I added your Reviewed-by tags to all wss-lib patches now.
Now, the tree contains various topic/* branches. For example, topic/wss-lib holds the whole series of wss and related patches, and topic/asoc holds ASoC-related patches. The master and other branches merge the topic branches appropriately. In this way, the patches can be sorted nicely and rebase can be avoided better as well.
Also, some topic branches are for experimental patches that aren't yet merged. For example, topic/hda-reconfig contains my HD-audio dynamic reconfig patches, and topic/modem-integrate contains MC97 integration patches.
The git URL is: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
and gitweb is: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=summary
thanks,
Takashi
On 05-08-08 11:45, Takashi Iwai wrote:
I've changed the tree structure in my git repo, so I added your Reviewed-by tags to all wss-lib patches now.
I see them, including the MODE_RUNNING changelog addition. Thanks.
Now, the tree contains various topic/* branches. For example, topic/wss-lib holds the whole series of wss and related patches, and topic/asoc holds ASoC-related patches. The master and other branches merge the topic branches appropriately. In this way, the patches can be sorted nicely and rebase can be avoided better as well.
Also, some topic branches are for experimental patches that aren't yet merged. For example, topic/hda-reconfig contains my HD-audio dynamic reconfig patches, and topic/modem-integrate contains MC97 integration patches.
The git URL is: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
and gitweb is: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=summary
I see. That stopped me for a bit.
I used to pull your devel branch directly into v2.6.26 which worked nicely, what with that branch being based at v2.6.26. topic/wss-lib now though is based at v2.6.27-rc1 meaning pulling it pulled in all of 2.6.27-rc1 as well.
I understand why; the wss-lib patches were dependent on some earlier opti9xx patches that are in 2.6.27-rc1 but I specifically this cycle decided to stay on -stable for a bit and not allow myself to be continously sidetracked by all sorts of problems in those megabytes upon megabytes of unrelated changes in the upstream kernel. Last cycle was particularly bad.
So I was just now cherry-picking the WSS patches and its dependents into a local topic/wss-lib when I decided to give it up after all and just go to 2.6.27-rc2. I'm debugging a PAT related problem in 2.6.27 anyway so I guess the attempt _already_ failed independent of ALSA. <sob>.
Hey, now I get to side-track myself with Merkey's kernel debugger...
Anyways -- what's the status of devel (topic/devel now I see) now? Is that still going to be a branch that's just current ALSA, pullable into current release? Worked great for me but if it's too much trouble to maintain, I can appreciate that and will just cherry-pick/rebase things myself locally I guess.
Rene.
At Fri, 08 Aug 2008 13:28:37 +0200, Rene Herman wrote:
On 05-08-08 11:45, Takashi Iwai wrote:
I've changed the tree structure in my git repo, so I added your Reviewed-by tags to all wss-lib patches now.
I see them, including the MODE_RUNNING changelog addition. Thanks.
Now, the tree contains various topic/* branches. For example, topic/wss-lib holds the whole series of wss and related patches, and topic/asoc holds ASoC-related patches. The master and other branches merge the topic branches appropriately. In this way, the patches can be sorted nicely and rebase can be avoided better as well.
Also, some topic branches are for experimental patches that aren't yet merged. For example, topic/hda-reconfig contains my HD-audio dynamic reconfig patches, and topic/modem-integrate contains MC97 integration patches.
The git URL is: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
and gitweb is: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=summary
I see. That stopped me for a bit.
I used to pull your devel branch directly into v2.6.26 which worked nicely, what with that branch being based at v2.6.26. topic/wss-lib now though is based at v2.6.27-rc1 meaning pulling it pulled in all of 2.6.27-rc1 as well.
I understand why; the wss-lib patches were dependent on some earlier opti9xx patches that are in 2.6.27-rc1 but I specifically this cycle decided to stay on -stable for a bit and not allow myself to be continously sidetracked by all sorts of problems in those megabytes upon megabytes of unrelated changes in the upstream kernel. Last cycle was particularly bad.
So I was just now cherry-picking the WSS patches and its dependents into a local topic/wss-lib when I decided to give it up after all and just go to 2.6.27-rc2. I'm debugging a PAT related problem in 2.6.27 anyway so I guess the attempt _already_ failed independent of ALSA. <sob>.
Hey, now I get to side-track myself with Merkey's kernel debugger...
Anyways -- what's the status of devel (topic/devel now I see) now? Is that still going to be a branch that's just current ALSA, pullable into current release? Worked great for me but if it's too much trouble to maintain, I can appreciate that and will just cherry-pick/rebase things myself locally I guess.
I originally wanted to keep the devel branch based on 2.6.26, but due to this reorganization, I had to remove it because it's no longer easy to track (and actually missed some changes in Documentation directory).
The topic/devel branch keeps the patches that don't belong to other topic branches. The master and for-next branches eventually merge topic branches for a single pull. The merge is continuous (unless any severe conflicts) so that you can keep pulling.
So, right now, there is no 2.6.26-branch. Sorry. But, topic branches will remain as they are, so for 2.6.28, it'll be easier to track. You can just pull topic branches you need to 2.6.27.
Takashi
On 08-08-08 13:55, Takashi Iwai wrote:
The topic/devel branch keeps the patches that don't belong to other topic branches. The master and for-next branches eventually merge topic branches for a single pull. The merge is continuous (unless any severe conflicts) so that you can keep pulling.
That sounds perfect, thanks. I'll go sit on your master branch...
Rene.
participants (2)
-
Rene Herman
-
Takashi Iwai