Re: [PATCH 03/11] wss_lib: rename cs4321_foo to wss_foo

Re: [PATCH 03/11] wss_lib: rename cs4321_foo to wss_foo

[krzysztof.h1]

> 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>
> 

I think about doing some code improvements in the opl3sa2 e.g. use
WSS tlv macros instead of the tlv macros defined localy.

Regards,
Krzysztof

----------------------------------------------------------------------
Tani Telefon!
Sprawdz >>>  http://link.interia.pl/f1ec0  

Re: [PATCH 03/11] wss_lib: rename cs4321_foo to wss_foo

[Rene Herman]

On 05-08-08 08:18, krzysztof.h1@poczta.fm wrote:

> I think about doing some code improvements in the opl3sa2 e.g. use
> WSS tlv macros instead of the tlv macros defined localy.

The more unification the better. Will review and test. opl3sa2 is 
painfree hardware to test.

Rene.

Re: [PATCH 03/11] wss_lib: rename cs4321_foo to wss_foo

[Rene Herman]

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);
> +		snd_wss_mce_up(chip);
>  		spin_lock_irqsave(&chip->reg_lock, flags);
> -		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) |
> +				       (chip->image[CS4231_REC_FORMAT] & 0x0f);
>  		} else {
> -			snd_cs4231_out(chip, CS4231_PLAYBK_FORMAT, chip->image[CS4231_PLAYBK_FORMAT] = pdfr);
> +			chip->image[CS4231_PLAYBK_FORMAT] = pdfr;
>  		}
> +		snd_wss_out(chip, CS4231_PLAYBK_FORMAT, pdfr);
>  		spin_unlock_irqrestore(&chip->reg_lock, flags);

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.

Re: [PATCH 03/11] wss_lib: rename cs4321_foo to wss_foo

[Takashi Iwai]

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

Re: [PATCH 03/11] wss_lib: rename cs4321_foo to wss_foo

[Rene Herman]

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.

Re: [PATCH 03/11] wss_lib: rename cs4321_foo to wss_foo

[Takashi Iwai]

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

Re: [PATCH 03/11] wss_lib: rename cs4321_foo to wss_foo

[Rene Herman]

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.