* Re: Commit:ce6cfaf1 query for shared control [not found] <CAES_P+-+CmRw5YYWeDPLd8-tn8tVCHmvJgWu9SS=TdeTnWzNUA@mail.gmail.com> @ 2013-11-25 7:45 ` Lars-Peter Clausen [not found] ` <CAES_P+8p3-RdGRj70XjghKZP2NGUbd_+08LPgMU=xM5aca_6ig@mail.gmail.com> 0 siblings, 1 reply; 2+ messages in thread From: Lars-Peter Clausen @ 2013-11-25 7:45 UTC (permalink / raw) To: noman pouigt; +Cc: alsa-devel On 11/25/2013 08:12 AM, noman pouigt wrote: > Hello Lars, > > I was wondering if you can enlighten me > on below query. > > Commit:ce6cfaf1 > > From the commit text "The input and > output paths for each widgets are only > updated though during the respective run > for that widget". > > Does this commit text mean: when mux > or mixer_power_update is called then only > the widget is powered and it's peer- widget > source(path source) and widget sink(path sink)? Hi, What the commit does is to make sure that if a control is shared between multiple mixers/muxes to apply all the changes in the same update sequence. Instead of, as it was done before, to run a update sequence for each mixer/mux. > > +------+ > A1 ------| | > | MUX1 |----- C1 > B1 ------| | > +------+ > | > control ---+ > | > +------+ > A2 ------| | > | MUX2 |----- C2 > B2 ------| | > +------+ > > Can I represent the above diagram as below: > > char *input_text_1[] = { > "A1", "B1" > }; > > struct soc_enum input_enum_1 = > SOC_ENUM_SINGLE(some_register, some_bit, > 2, input_text_1); > > char *input_text_2[] = { > "A2", "B2" > }; > struct soc_enum input_enum_2 = > SOC_ENUM_SINGLE(some_register, some_bit, > 2, input_text_2); > > > struct snd_kcontrol_new input_mux = > SOC_DAPM_ENUM("C1", input_enum_1); > struct snd_kcontrol_new input_mux = > SOC_DAPM_ENUM("C2", input_enum_2); > > dapm_route[] { > "A1", "control","C1" > "B1", "control","C1" > "A2", "control","C2" > "B2", "control","C2" > }; The control part needs to have the name of one of the enum items. So this would be { "A1", "A1", "C1" } and so on. - Lars ^ permalink raw reply [flat|nested] 2+ messages in thread
[parent not found: <CAES_P+8p3-RdGRj70XjghKZP2NGUbd_+08LPgMU=xM5aca_6ig@mail.gmail.com>]
* Re: Commit:ce6cfaf1 query for shared control [not found] ` <CAES_P+8p3-RdGRj70XjghKZP2NGUbd_+08LPgMU=xM5aca_6ig@mail.gmail.com> @ 2013-11-27 7:41 ` Lars-Peter Clausen 0 siblings, 0 replies; 2+ messages in thread From: Lars-Peter Clausen @ 2013-11-27 7:41 UTC (permalink / raw) To: noman pouigt; +Cc: alsa-devel On 11/25/2013 11:57 PM, noman pouigt wrote: > On Sun, Nov 24, 2013 at 11:45 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: >> On 11/25/2013 08:12 AM, noman pouigt wrote: >>> Hello Lars, >>> >>> I was wondering if you can enlighten me >>> on below query. >>> >>> Commit:ce6cfaf1 >>> >>> From the commit text "The input and >>> output paths for each widgets are only >>> updated though during the respective run >>> for that widget". > Thanks for replying.Probably my query was > not clear.I wanted to understand the commit > text which i quoted above.And my understanding > of that commit text is below: The text just describes the behavior as it was before the commit, which was separate power-up/power-down sequence for each widget. >>> Does this commit text mean: when mux >>> or mixer_power_update is called then only >>> the widget is powered and it's peer- widget >>> source(path source) and widget sink(path sink)? >> >> Hi, >> >> What the commit does is to make sure that if a control is shared between >> multiple mixers/muxes to apply all the changes in the same update sequence. >> Instead of, as it was done before, to run a update sequence for each mixer/mux. > I understood this as you have clearly mentioned it with a nice > diagram. >> >>> >>> +------+ >>> A1 ------| | >>> | MUX1 |----- C1 >>> B1 ------| | >>> +------+ >>> | >>> control ---+ >>> | >>> +------+ >>> A2 ------| | >>> | MUX2 |----- C2 >>> B2 ------| | >>> +------+ >>> >>> Can I represent the above diagram as below: >>> >>> char *input_text_1[] = { >>> "A1", "B1" >>> }; >>> >>> struct soc_enum input_enum_1 = >>> SOC_ENUM_SINGLE(some_register, some_bit, >>> 2, input_text_1); >>> >>> char *input_text_2[] = { >>> "A2", "B2" >>> }; >>> struct soc_enum input_enum_2 = >>> SOC_ENUM_SINGLE(some_register, some_bit, >>> 2, input_text_2); >>> >>> >>> struct snd_kcontrol_new input_mux = >>> SOC_DAPM_ENUM("C1", input_enum_1); >>> struct snd_kcontrol_new input_mux = >>> SOC_DAPM_ENUM("C2", input_enum_2); >>> >>> dapm_route[] { >>> "A1", "control","C1" >>> "B1", "control","C1" >>> "A2", "control","C2" >>> "B2", "control","C2" >>> }; >> >> The control part needs to have the name of one of the enum items. So this >> would be { "A1", "A1", "C1" } and so on. > Yes makes sense as then only it will know > which widget to connect to as it has multiple > widgets. >> >> - Lars >> >> >> >> >> ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-11-27 7:40 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAES_P+-+CmRw5YYWeDPLd8-tn8tVCHmvJgWu9SS=TdeTnWzNUA@mail.gmail.com>
2013-11-25 7:45 ` Commit:ce6cfaf1 query for shared control Lars-Peter Clausen
[not found] ` <CAES_P+8p3-RdGRj70XjghKZP2NGUbd_+08LPgMU=xM5aca_6ig@mail.gmail.com>
2013-11-27 7:41 ` Lars-Peter Clausen
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.