Mark Brown wrote at Tuesday, April 19, 2011 12:53 PM: > On Tue, Apr 19, 2011 at 12:46:16PM -0600, Stephen Warren wrote: > > > Without this, if tegra_wm8903 is modified to provide controls, > > widgets, and routes through data rather than calling registration > > functions, tegra_wm8903_event_* will crash, because w->codec==NULL. > > This will break other things as it means that we can't route to the DAPM > widgets that are added from machine init functions (eg, those that set > up jacks) which is a more common case - see the changelog for the code > you're modifying. > > There's also the fact that these widgets should be being created in the > card DAPM context so I'm a bit concerned that they're getting a CODEC at > all. The dereferencing you're trying to do isn't good, you're looking > for a CODEC to find the card for widgets in the card DAPM context which > shouldn't be associated with any particular CODEC in the first place. > You should just find the card based on the DAPM context you're in. OK. I dropped that patch and fixed up the event functions so they work correctly. However, I do notice one other regression moving the tegra_wm8903 driver to data instead of code for widgets/controls/routes: Before that change, the "Int Spk" control both works fine, and when I modify the value in alsamixer, exit, and restart alsamixer, the value I set is maintained. However, after that change, the control works fine (i.e. mutes/umutes speakers while speaker-test is running in the background), but when I quit and restart alsamixer, the most recent set value is not shown. Do you have any clue what I should look at for that? Thanks! -- nvpublic -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
