Re: Separate dma driver for cpu_dais

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

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).