On Thu, Feb 18, 2010 at 08:59:38PM +0900, jassi brar wrote:
On Thu, Feb 18, 2010 at 7:57 PM, Mark Brown
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.
Right, but that doesn't mean that the device drivers can't do anything useful here - in terms of restrictions they can't do anything the hardware can't implmenent. Another example here is that startup function can set constraints based on the configuration of other running links if the hardware has any limitations in that regard (some will, some won't, and the limitations may not even be anything to do with audio in some designs).
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.
I'm not saying don't put anything in the core, I'm saying the change you have implemented goes too far by completely removing the notification to drivers. It's not going to be possible for the core to anticipate every possible thing that a driver might need, and unless a requirement is common between a number of drivers it's not going to be a benefit to put it into the core.
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.
If you're carrying changes that are already upstream that's fine, it's carrying changes that are not upstream that causes problems - if the change has gone upstream then when you rebase or merge with the upstream version things will work themselves out. It's changes that haven't gone upstream that cause trouble, both in terms of maintaining them and for users trying to do things like merge drivers from several different sources.
Obviously there are cases where changes in generic code are a good idea, and I'd encourage you to make such changes, all I'm saying is that I recommend against shipping them in a vendor BSP without making sure that they're going to be OK upstream (and ideally are actually upstream).