Re: [alsa-devel] [PATCH] ASOC:DAPM: extend dapm kcontrol to support runtime route update
On Thu, Dec 12, 2013 at 02:56:08AM -0800, Nenghua Cao wrote:
Don't top post. Please also fix your mailer to word wrap within paragaphs, it makes your mails much more legible.
For common mix/mux which aren't related with DPCM, it doesn't need to do DPCM update. And it still can use the old controls. But for the mix/mux which impacts fe<->be link, they need to do this works. For them, they call use the new set of controls. I think it can make our code has better backward-compatibility.
How does this improve backwards compatibility?
Hi, Mark:
On 12/12/2013 07:07 PM, Mark Brown wrote:
On Thu, Dec 12, 2013 at 02:56:08AM -0800, Nenghua Cao wrote:
Don't top post. Please also fix your mailer to word wrap within paragaphs, it makes your mails much more legible.
It is my fault and Thanks for your kindly reminder. I just made my mailer work as community's request.
For common mix/mux which aren't related with DPCM, it doesn't need to do DPCM update. And it still can use the old controls. But for the mix/mux which impacts fe<->be link, they need to do this works. For them, they call use the new set of controls. I think it can make our code has better backward-compatibility.
How does this improve backwards compatibility?
My thought is that we distinguish different requirement through flag (you can find dpcm_checked in my patch).
Thanks
At Fri, 13 Dec 2013 19:33:46 +0800, Nenghua Cao wrote:
Hi, Mark:
On 12/12/2013 07:07 PM, Mark Brown wrote:
On Thu, Dec 12, 2013 at 02:56:08AM -0800, Nenghua Cao wrote:
Don't top post. Please also fix your mailer to word wrap within paragaphs, it makes your mails much more legible.
It is my fault and Thanks for your kindly reminder. I just made my mailer work as community's request.
For common mix/mux which aren't related with DPCM, it doesn't need to do DPCM update. And it still can use the old controls. But for the mix/mux which impacts fe<->be link, they need to do this works. For them, they call use the new set of controls. I think it can make our code has better backward-compatibility.
How does this improve backwards compatibility?
My thought is that we distinguish different requirement through flag (you can find dpcm_checked in my patch).
The question is rather what do you mean as "backward compatibility".
Usually backward compatibility is concerned when something new breaks the existing ones. In your case, always updating DPCM would work, too, even without an extra flag; it's just suboptimal.
Takashi
On Fri, Dec 13, 2013 at 12:37:20PM +0100, Takashi Iwai wrote:
Usually backward compatibility is concerned when something new breaks the existing ones. In your case, always updating DPCM would work, too, even without an extra flag; it's just suboptimal.
Right, and if we have separate versions then at some point we'll end up having to define DPCM versions of everything which is going to get tedious and error prone.
Hi, Takashi and Mark:
On 12/13/2013 07:42 PM, Mark Brown wrote:
On Fri, Dec 13, 2013 at 12:37:20PM +0100, Takashi Iwai wrote:
Usually backward compatibility is concerned when something new breaks the existing ones. In your case, always updating DPCM would work, too, even without an extra flag; it's just suboptimal.
Right, and if we have separate versions then at some point we'll end up having to define DPCM versions of everything which is going to get tedious and error prone.
According to your suggestion, i removed the flag, and updated the patch. Please review it again.
Thanks
On 12/13/2013 07:37 PM, Takashi Iwai wrote:
At Fri, 13 Dec 2013 19:33:46 +0800, Nenghua Cao wrote:
Hi, Mark:
On 12/12/2013 07:07 PM, Mark Brown wrote:
On Thu, Dec 12, 2013 at 02:56:08AM -0800, Nenghua Cao wrote:
Don't top post. Please also fix your mailer to word wrap within paragaphs, it makes your mails much more legible.
It is my fault and Thanks for your kindly reminder. I just made my mailer work as community's request.
>> > For common mix/mux which aren't related with DPCM, it doesn't need >> > to do DPCM update. And it still can use the old controls. But for >> > the mix/mux which impacts fe<->be link, they need to do this works. >> > For them, they call use the new set of controls. I think it can >> > make our code has better backward-compatibility.
How does this improve backwards compatibility?
My thought is that we distinguish different requirement through flag (you can find dpcm_checked in my patch).
The question is rather what do you mean as "backward compatibility".
Usually backward compatibility is concerned when something new breaks the existing ones. In your case, always updating DPCM would work, too, even without an extra flag; it's just suboptimal.
Yes, you are right. I add this flag only for avoiding the traversing dai_link in soc_dpcm_runtime_update(). So you think this work is unnecessary. I will make another patch which will do DPCM runtime update always. Is it Ok?
Takashi
Thanks
On Fri, Dec 13, 2013 at 07:53:21PM +0800, Nenghua Cao wrote:
Yes, you are right. I add this flag only for avoiding the traversing dai_link in soc_dpcm_runtime_update(). So you think this work is unnecessary. I will make another patch which will do DPCM runtime update always. Is it Ok?
It seems safer, we can optimise later if we need to.
participants (3)
-
Mark Brown -
Nenghua Cao -
Takashi Iwai