All of lore.kernel.org
 help / color / mirror / Atom feed
From: Songhee Baek <sbaek@nvidia.com>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: Arun Shamanna Lakshmi <aruns@nvidia.com>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"swarren@wwwdotorg.org" <swarren@wwwdotorg.org>,
	"perex@perex.cz" <perex@perex.cz>,
	"tiwai@suse.de" <tiwai@suse.de>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] ASoC: DAPM: Add support for multi register mux
Date: Wed, 2 Apr 2014 08:26:11 -0700	[thread overview]
Message-ID: <D6C615D3E4730340AE82D5BD856631C0A26CB3259B@HQMAIL02.nvidia.com> (raw)
In-Reply-To: <533BB5E6.7050004@metafoo.de>

> -----Original Message-----
> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
> Sent: Wednesday, April 02, 2014 12:02 AM
> To: Songhee Baek
> Cc: Arun Shamanna Lakshmi; lgirdwood@gmail.com; broonie@kernel.org;
> swarren@wwwdotorg.org; perex@perex.cz; tiwai@suse.de; alsa-
> devel@alsa-project.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ASoC: DAPM: Add support for multi register mux
> 
> On 04/02/2014 08:56 AM, Songhee Baek wrote:
> >
> >
> >> -----Original Message-----
> >> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
> >> Sent: Tuesday, April 01, 2014 11:47 PM
> >> To: Songhee Baek
> >> Cc: Arun Shamanna Lakshmi; lgirdwood@gmail.com; broonie@kernel.org;
> >> swarren@wwwdotorg.org; perex@perex.cz; tiwai@suse.de; alsa-
> >> devel@alsa-project.org; linux-kernel@vger.kernel.org
> >> Subject: Re: [PATCH] ASoC: DAPM: Add support for multi register mux
> >>
> >> On 04/02/2014 08:17 AM, Songhee Baek wrote:
> >>>> -----Original Message-----
> >>>> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
> >>>> Sent: Tuesday, April 01, 2014 11:00 PM
> >>>> To: Arun Shamanna Lakshmi
> >>>> Cc: lgirdwood@gmail.com; broonie@kernel.org;
> >> swarren@wwwdotorg.org;
> >>>> perex@perex.cz; tiwai@suse.de; alsa-devel@alsa-project.org; linux-
> >>>> kernel@vger.kernel.org; Songhee Baek
> >>>> Subject: Re: [PATCH] ASoC: DAPM: Add support for multi register mux
> >>>>
> >>>> On 04/01/2014 08:26 PM, Arun Shamanna Lakshmi wrote:
> >>>> [...]
> >>>>>>> diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index
> >>>>>>> c8a780d..4d2b35c 100644
> >>>>>>> --- a/sound/soc/soc-dapm.c
> >>>>>>> +++ b/sound/soc/soc-dapm.c
> >>>>>>> @@ -514,9 +514,9 @@ static int dapm_connect_mux(struct
> >>>>>> snd_soc_dapm_context *dapm,
> >>>>>>>      	unsigned int val, item;
> >>>>>>>      	int i;
> >>>>>>>
> >>>>>>> -	if (e->reg != SND_SOC_NOPM) {
> >>>>>>> -		soc_widget_read(dest, e->reg, &val);
> >>>>>>> -		val = (val >> e->shift_l) & e->mask;
> >>>>>>> +	if (e->reg[0] != SND_SOC_NOPM) {
> >>>>>>> +		soc_widget_read(dest, e->reg[0], &val);
> >>>>>>> +		val = (val >> e->shift_l) & e->mask[0];
> >>>>>>>      		item = snd_soc_enum_val_to_item(e, val);
> >>>>>>
> >>>>>> This probably should handle the new enum type as well. You'll
> >>>>>> probably need some kind of flag in the struct to distinguish
> >>>>>> between the two enum types.
> >>>>>
> >>>>> Any suggestion on the flag name ?
> >>>>>
> >>>>
> >>>> How about 'onehot'?
> >>>>
> >>>> [...]
> >>>>>>> +		reg_val = BIT(bit_pos);
> >>>>>>> +	}
> >>>>>>> +
> >>>>>>> +	for (i = 0; i < e->num_regs; i++) {
> >>>>>>> +		if (i == reg_idx) {
> >>>>>>> +			change = snd_soc_test_bits(codec, e->reg[i],
> >>>>>>> +							e->mask[i],
> >>>>>> reg_val);
> >>>>>>> +
> >>>>>>> +		} else {
> >>>>>>> +			/* accumulate the change to update the
> >> DAPM
> >>>>>> path
> >>>>>>> +			    when none is selected */
> >>>>>>> +			change += snd_soc_test_bits(codec, e-
> >>> reg[i],
> >>>>>>> +							e->mask[i], 0);
> >>>>>>
> >>>>>> change |=
> >>>>>>
> >>>>>>> +
> >>>>>>> +			/* clear the register when not selected */
> >>>>>>> +			snd_soc_write(codec, e->reg[i], 0);
> >>>>>>
> >>>>>> I think this should happen as part of the DAPM update sequence
> >>>>>> like you had earlier. Some special care should probably be take
> >>>>>> to make sure that you de-select the previous mux input before
> >>>>>> selecting the new one if the new one is in a different register than
> the previous one.
> >>>>>
> >>>>> I am not sure I follow this part. We are clearing the 'not selected'
> >>>>> registers before we set the one we want. Do you want us to loop
> >>>>> the logic of soc_dapm_mux_update_power for each register ? or do
> >>>>> you want to change the dapm_update structure so that it takes all
> >>>>> the regs, masks, and values together ?
> >>>>
> >>>> The idea with the dapm_update struct is that the register updates
> >>>> are done in the middle of the power-down and power-up sequence.
> So
> >>>> yes, change the dapm_update struct to be able to hold all register
> >>>> updates and do all register updates in dapm_widget_update. I think
> >>>> an earlier version of your patch already had this.
> >>>
> >>> Is the change similar to as shown below?
> >>>
> >>> for (reg_idx = 0; reg_idx < e->num_regs; reg_idx++) {
> >>> 	val = e->values[item * e->num_regs + reg_idx];
> >>> 	ret = snd_soc_update_bits_locked(codec, e->reg[reg_idx],
> >>> 				e->mask[reg_idx], val);
> >>> 	if (ret)
> >>> 	return ret;
> >>> }
> >>>
> >>> During updating of the register's value, the above change can create
> >>> non-zero value in two different registers (very short transition) as
> >>> Mark mentioned for that change so we need to clear register first
> >>> before writing the desired value in the register.
> >>>
> >>> Should we add the clearing all registers and write the mux value in
> >>> desired register in the update function?
> >>>
> >>
> >> In dapm_update_widget() you have this line:
> >>
> >>    ret = soc_widget_update_bits(w, update->reg, update->mask, update-
> >>> val);
> >>
> >> That needs to be done for every register update. When you setup the
> >> update struct you need to make sure that the register clears come
> >> before the register set.
> >>
> >> E.g. if you have register 0x3, 0x4, 0x5 and you select a bit in
> >> register 0x4 it should look like this.
> >>
> >> update->reg[0] = 0x3;
> >> update->val[0] = 0x0;
> >> update->reg[1] = 0x5;
> >> update->val[1] = 0x0;
> >> update->reg[2] = 0x4;
> >> update->val[2] = 0x8;
> >>
> >> When you set a bit in register 0x3 it should look like this:
> >>
> >> update->reg[0] = 0x4;
> >> update->val[0] = 0x0;
> >> update->reg[1] = 0x5;
> >> update->val[1] = 0x0;
> >> update->reg[2] = 0x3;
> >> update->val[2] = 0x1;
> >>
> >> So basically the write operation goes into update->reg[e->num_regs-1]
> >> the clear operations go into the other slots before that.
> >
> > Does update reg/val array have the writing sequence, is it correct?
> > And can I assume that update struct has reg/val/mask arrays not pointers?
> 
> Right now the update struct does not have support for multiple register
> writes. That's up to you to implement this. I guess making it an array for now
> should be fine. But you need to add some safety checks to make sure that
> num_regs is not larger or equal to the array size.

I think that the dapm update struct needs to have reg[2]/val[2]/mask[2].
Because the mux is one-hot coded, only one register has a non-zero value.
So reg[0] will contain the register to be clear and reg[2] has selected register
to be set.
How about your opinion for this?

WARNING: multiple messages have this Message-ID (diff)
From: Songhee Baek <sbaek@nvidia.com>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: Arun Shamanna Lakshmi <aruns@nvidia.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"swarren@wwwdotorg.org" <swarren@wwwdotorg.org>,
	"tiwai@suse.de" <tiwai@suse.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"broonie@kernel.org" <broonie@kernel.org>
Subject: Re: [PATCH] ASoC: DAPM: Add support for multi register mux
Date: Wed, 2 Apr 2014 08:26:11 -0700	[thread overview]
Message-ID: <D6C615D3E4730340AE82D5BD856631C0A26CB3259B@HQMAIL02.nvidia.com> (raw)
In-Reply-To: <533BB5E6.7050004@metafoo.de>

> -----Original Message-----
> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
> Sent: Wednesday, April 02, 2014 12:02 AM
> To: Songhee Baek
> Cc: Arun Shamanna Lakshmi; lgirdwood@gmail.com; broonie@kernel.org;
> swarren@wwwdotorg.org; perex@perex.cz; tiwai@suse.de; alsa-
> devel@alsa-project.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ASoC: DAPM: Add support for multi register mux
> 
> On 04/02/2014 08:56 AM, Songhee Baek wrote:
> >
> >
> >> -----Original Message-----
> >> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
> >> Sent: Tuesday, April 01, 2014 11:47 PM
> >> To: Songhee Baek
> >> Cc: Arun Shamanna Lakshmi; lgirdwood@gmail.com; broonie@kernel.org;
> >> swarren@wwwdotorg.org; perex@perex.cz; tiwai@suse.de; alsa-
> >> devel@alsa-project.org; linux-kernel@vger.kernel.org
> >> Subject: Re: [PATCH] ASoC: DAPM: Add support for multi register mux
> >>
> >> On 04/02/2014 08:17 AM, Songhee Baek wrote:
> >>>> -----Original Message-----
> >>>> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
> >>>> Sent: Tuesday, April 01, 2014 11:00 PM
> >>>> To: Arun Shamanna Lakshmi
> >>>> Cc: lgirdwood@gmail.com; broonie@kernel.org;
> >> swarren@wwwdotorg.org;
> >>>> perex@perex.cz; tiwai@suse.de; alsa-devel@alsa-project.org; linux-
> >>>> kernel@vger.kernel.org; Songhee Baek
> >>>> Subject: Re: [PATCH] ASoC: DAPM: Add support for multi register mux
> >>>>
> >>>> On 04/01/2014 08:26 PM, Arun Shamanna Lakshmi wrote:
> >>>> [...]
> >>>>>>> diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index
> >>>>>>> c8a780d..4d2b35c 100644
> >>>>>>> --- a/sound/soc/soc-dapm.c
> >>>>>>> +++ b/sound/soc/soc-dapm.c
> >>>>>>> @@ -514,9 +514,9 @@ static int dapm_connect_mux(struct
> >>>>>> snd_soc_dapm_context *dapm,
> >>>>>>>      	unsigned int val, item;
> >>>>>>>      	int i;
> >>>>>>>
> >>>>>>> -	if (e->reg != SND_SOC_NOPM) {
> >>>>>>> -		soc_widget_read(dest, e->reg, &val);
> >>>>>>> -		val = (val >> e->shift_l) & e->mask;
> >>>>>>> +	if (e->reg[0] != SND_SOC_NOPM) {
> >>>>>>> +		soc_widget_read(dest, e->reg[0], &val);
> >>>>>>> +		val = (val >> e->shift_l) & e->mask[0];
> >>>>>>>      		item = snd_soc_enum_val_to_item(e, val);
> >>>>>>
> >>>>>> This probably should handle the new enum type as well. You'll
> >>>>>> probably need some kind of flag in the struct to distinguish
> >>>>>> between the two enum types.
> >>>>>
> >>>>> Any suggestion on the flag name ?
> >>>>>
> >>>>
> >>>> How about 'onehot'?
> >>>>
> >>>> [...]
> >>>>>>> +		reg_val = BIT(bit_pos);
> >>>>>>> +	}
> >>>>>>> +
> >>>>>>> +	for (i = 0; i < e->num_regs; i++) {
> >>>>>>> +		if (i == reg_idx) {
> >>>>>>> +			change = snd_soc_test_bits(codec, e->reg[i],
> >>>>>>> +							e->mask[i],
> >>>>>> reg_val);
> >>>>>>> +
> >>>>>>> +		} else {
> >>>>>>> +			/* accumulate the change to update the
> >> DAPM
> >>>>>> path
> >>>>>>> +			    when none is selected */
> >>>>>>> +			change += snd_soc_test_bits(codec, e-
> >>> reg[i],
> >>>>>>> +							e->mask[i], 0);
> >>>>>>
> >>>>>> change |=
> >>>>>>
> >>>>>>> +
> >>>>>>> +			/* clear the register when not selected */
> >>>>>>> +			snd_soc_write(codec, e->reg[i], 0);
> >>>>>>
> >>>>>> I think this should happen as part of the DAPM update sequence
> >>>>>> like you had earlier. Some special care should probably be take
> >>>>>> to make sure that you de-select the previous mux input before
> >>>>>> selecting the new one if the new one is in a different register than
> the previous one.
> >>>>>
> >>>>> I am not sure I follow this part. We are clearing the 'not selected'
> >>>>> registers before we set the one we want. Do you want us to loop
> >>>>> the logic of soc_dapm_mux_update_power for each register ? or do
> >>>>> you want to change the dapm_update structure so that it takes all
> >>>>> the regs, masks, and values together ?
> >>>>
> >>>> The idea with the dapm_update struct is that the register updates
> >>>> are done in the middle of the power-down and power-up sequence.
> So
> >>>> yes, change the dapm_update struct to be able to hold all register
> >>>> updates and do all register updates in dapm_widget_update. I think
> >>>> an earlier version of your patch already had this.
> >>>
> >>> Is the change similar to as shown below?
> >>>
> >>> for (reg_idx = 0; reg_idx < e->num_regs; reg_idx++) {
> >>> 	val = e->values[item * e->num_regs + reg_idx];
> >>> 	ret = snd_soc_update_bits_locked(codec, e->reg[reg_idx],
> >>> 				e->mask[reg_idx], val);
> >>> 	if (ret)
> >>> 	return ret;
> >>> }
> >>>
> >>> During updating of the register's value, the above change can create
> >>> non-zero value in two different registers (very short transition) as
> >>> Mark mentioned for that change so we need to clear register first
> >>> before writing the desired value in the register.
> >>>
> >>> Should we add the clearing all registers and write the mux value in
> >>> desired register in the update function?
> >>>
> >>
> >> In dapm_update_widget() you have this line:
> >>
> >>    ret = soc_widget_update_bits(w, update->reg, update->mask, update-
> >>> val);
> >>
> >> That needs to be done for every register update. When you setup the
> >> update struct you need to make sure that the register clears come
> >> before the register set.
> >>
> >> E.g. if you have register 0x3, 0x4, 0x5 and you select a bit in
> >> register 0x4 it should look like this.
> >>
> >> update->reg[0] = 0x3;
> >> update->val[0] = 0x0;
> >> update->reg[1] = 0x5;
> >> update->val[1] = 0x0;
> >> update->reg[2] = 0x4;
> >> update->val[2] = 0x8;
> >>
> >> When you set a bit in register 0x3 it should look like this:
> >>
> >> update->reg[0] = 0x4;
> >> update->val[0] = 0x0;
> >> update->reg[1] = 0x5;
> >> update->val[1] = 0x0;
> >> update->reg[2] = 0x3;
> >> update->val[2] = 0x1;
> >>
> >> So basically the write operation goes into update->reg[e->num_regs-1]
> >> the clear operations go into the other slots before that.
> >
> > Does update reg/val array have the writing sequence, is it correct?
> > And can I assume that update struct has reg/val/mask arrays not pointers?
> 
> Right now the update struct does not have support for multiple register
> writes. That's up to you to implement this. I guess making it an array for now
> should be fine. But you need to add some safety checks to make sure that
> num_regs is not larger or equal to the array size.

I think that the dapm update struct needs to have reg[2]/val[2]/mask[2].
Because the mux is one-hot coded, only one register has a non-zero value.
So reg[0] will contain the register to be clear and reg[2] has selected register
to be set.
How about your opinion for this?

  parent reply	other threads:[~2014-04-02 15:26 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-01  6:21 [PATCH] ASoC: DAPM: Add support for multi register mux Arun Shamanna Lakshmi
2014-04-01  6:21 ` Arun Shamanna Lakshmi
2014-04-01  7:48 ` Lars-Peter Clausen
     [not found]   ` <781A12BB53C15A4BB37291FDE08C03F3A05CDCD63B@HQMAIL02.nvidia.com>
2014-04-01 18:26     ` Arun Shamanna Lakshmi
2014-04-01 18:26       ` Arun Shamanna Lakshmi
2014-04-02  6:00       ` Lars-Peter Clausen
2014-04-02  6:17         ` Songhee Baek
2014-04-02  6:17           ` Songhee Baek
2014-04-02  6:47           ` Lars-Peter Clausen
2014-04-02  6:47             ` Lars-Peter Clausen
2014-04-02  6:56             ` Songhee Baek
2014-04-02  7:01               ` Lars-Peter Clausen
2014-04-02  7:01                 ` Lars-Peter Clausen
2014-04-02  7:06                 ` Songhee Baek
2014-04-02  7:06                   ` Songhee Baek
2014-04-02 15:26                 ` Songhee Baek [this message]
2014-04-02 15:26                   ` Songhee Baek
2014-04-02 15:29                   ` Lars-Peter Clausen
2014-04-03  3:11 [PATCH] ASoC: dapm: " Arun Shamanna Lakshmi
2014-04-03  3:11 ` Arun Shamanna Lakshmi
2014-04-03  8:27 ` Lars-Peter Clausen
2014-04-03  8:27   ` Lars-Peter Clausen
2014-04-03  9:40   ` Mark Brown
2014-04-03  9:40     ` Mark Brown
2014-04-03 20:11   ` Arun Shamanna Lakshmi
2014-04-04  7:31     ` Lars-Peter Clausen
2014-04-04  7:34       ` Arun Shamanna Lakshmi
2014-04-04  7:40         ` Lars-Peter Clausen
2014-04-03  9:47 ` Takashi Iwai
2014-04-03  9:47   ` Takashi Iwai
2014-04-03  9:53   ` Mark Brown
2014-04-03  9:53     ` Mark Brown
2014-04-03 13:31     ` Lars-Peter Clausen
2014-04-03 13:31       ` Lars-Peter Clausen
2014-04-03 15:06       ` Takashi Iwai
2014-04-03 16:02         ` Mark Brown
2014-04-05  0:12 Arun Shamanna Lakshmi
2014-04-05  0:12 ` Arun Shamanna Lakshmi
2014-04-07 12:54 ` Lars-Peter Clausen
2014-04-07 14:24   ` Takashi Iwai
2014-04-09 15:56 ` Mark Brown
2014-04-09 20:07   ` Arun S L

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D6C615D3E4730340AE82D5BD856631C0A26CB3259B@HQMAIL02.nvidia.com \
    --to=sbaek@nvidia.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=aruns@nvidia.com \
    --cc=broonie@kernel.org \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=swarren@wwwdotorg.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.