On Thu, Feb 18, 2010 at 7:57 PM, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Feb 18, 2010 at 07:32:22PM +0900, jassi brar wrote: >> On Thu, Feb 18, 2010 at 6:52 PM, Mark Brown > >> > Where is the code you are talking about here? This sounds like driver >> > code... > >> Ahh... it's all messed up by that samsung.git link that Joonyoung Shim shared. >> I assumed you had a look at that. The code just a quick workaround, so >> I didn't put it up here >> http://git.kernel.org/?p=linux/kernel/git/kki_ap/linux-2.6-samsung.git;a=commitdiff;h=e5858948bb2c534251b65a850caf197ae880ce1f > > His link was to the entire tree rather than a particular bit of code, a > bit of a needle in the haystack thing going on there (especially since > you have actually modified the core and for looking at stuff like that > I'd generally drill down into the platform directory before looking at > logs or code). Actually my patches are at the top of 2.6.29 branch(the only one that has relevant code). I wanted to start separate threads for each independent topics towards implementing a) platform per dai_link, b) dai sharing among dai_links and c) multi-device per card, but the thread veered off. Anyways... > The bits of that patch that make active a reference counter look good at > first glance, could you please pull them out and submit them? Sure I can, though I think of a few more checks to place in the code. Will submit tomorrow from workplace. > Like I > said in reply to Joonyoung it's not immediately clear to me that the > startup and shutdown calls should be suppressed since I'd expect that at > least some drivers are going to want to know about multiple uses (for > example, returning -EBUSY if someone tries to have too many things > active at once). IMO codecs should simply do as directed by the ASOC. The multi-instance logic has better be at one place(soc-core.c) rather than in each codec's driver. For that reason I modified soc-core.c rather than my device's codec and cpu driver. > In general for a vendor BSP I'd strongly recommend against any changes > in the core that don't get submitted to mainline - it's more of a > maintinance burden and makes it harder for people to take the drivers > and use them with other kernel versions if they don't notice the change. As explained above, I thought I had a reason to do so. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
