From: Nicolin Chen <b42378@freescale.com>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: tiwai@suse.de, alsa-devel@alsa-project.org, broonie@kernel.org,
lgirdwood@gmail.com
Subject: Re: [PATCH] ASoC: generic-dmaengine-pcm: Add an interface to override its functions
Date: Tue, 15 Oct 2013 17:23:51 +0800 [thread overview]
Message-ID: <20131015092350.GA18784@MrMyself> (raw)
In-Reply-To: <525D04B4.3050606@metafoo.de>
On Tue, Oct 15, 2013 at 11:02:44AM +0200, Lars-Peter Clausen wrote:
> > If this modification to sound/core/pcm_dmaengine.c is not fair,
> > what about moving the modification to soc-gerneric-dmaengine-pcm.c?
> >
> > For example, instead of using snd_dmaengine_pcm_trigger() directly
> > in gerneric soc dmaengine driver, we create a new one inside gerneric
> > soc dmaengine driver and check the override:
> >
> > static int snd_soc_dmaengine_pcm_trigger(substream, cmd) {
> > if (config->driver->ops->trigger)
> > return config->driver->ops->trigger(substream, cmd);
> >
> > return snd_dmaengine_pcm_trigger(substream, cmd);
> > }
> >
> > Since it happens inside generic dmaengine pcm ASoC driver, it won't break
> > those helper functions.
> >
> > I'm trying this just because I hope generic dmaengine can be more flexible
> > Admittedly, using helper functions might be more plausible way in current
> > ASoC structure. However, there might be so much change for an generic soc
> > dmaengine implementation even if it just wants to override one single func.
>
> Well the idea of the generic dmaengine driver is to be generic and not
> require SoC specific hacks since those should not be necessary if things are
> done right. What exactly do you want to implement in the overwritten ops?
>
> - Lars
Just like I mentioned in the commit comments, using on-chip memory would
need an alternative memory allocating function to replace the default one
from external DDR. imx-pcm-dma.c is now using ASoC generic dmaengine, so
if we turn it back to helper functions way, all cpu dai drivers might have
to be turned back as well.
ASoC generic dmaengine is quite concise and well-developed for us to use.
But after using it, its own limitation might make user waver to choose the
old fashion helper functions. So I just wish it could provide a back door
for an easy trick. Then we can continue to enjoy the convenience from it
and also be able to tackle these uncommon cases.
Thank you,
Nicolin Chen
next prev parent reply other threads:[~2013-10-15 9:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-15 7:49 [PATCH] ASoC: generic-dmaengine-pcm: Add an interface to override its functions Nicolin Chen
2013-10-15 8:08 ` Lars-Peter Clausen
2013-10-15 8:22 ` Nicolin Chen
2013-10-15 9:02 ` Lars-Peter Clausen
2013-10-15 9:23 ` Nicolin Chen [this message]
2013-10-15 9:40 ` Lars-Peter Clausen
2013-10-15 9:37 ` Nicolin Chen
2013-10-15 12:49 ` Mark Brown
2013-10-15 11:05 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131015092350.GA18784@MrMyself \
--to=b42378@freescale.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.