From: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, patches@opensource.wolfsonmicro.com,
lgirdwood@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] ASoC: wm_adsp: Add code_probe and codec_remove stubs
Date: Tue, 9 Jun 2015 17:43:29 +0100 [thread overview]
Message-ID: <20150609164329.GC27675@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20150609162045.GF14071@sirena.org.uk>
On Tue, Jun 09, 2015 at 05:20:45PM +0100, Mark Brown wrote:
> On Tue, Jun 09, 2015 at 05:13:56PM +0100, Richard Fitzgerald wrote:
> > On Tue, Jun 09, 2015 at 05:00:43PM +0100, Mark Brown wrote:
>
> > > I'm still not a big fan of the double registration that's being done -
> > > if nothing else the fact that it's not also factoring out the creation
> > > of the DSP controls seems wrong.
>
We can certainly look at factoring out that control creation once we have
a probe function in wm_adsp to put them in. Which is what this patch creates.
> > I don't see the point of trying to fight against the design of ASoC with
> > the second probe. ASoC gives us what we need at the codec_probe stage
> > so why try to invent something different?
>
> Well, you could've still hung things off the struct device - it's not
> like the ASoC level device is a requirement here - and like I say the
I'm doing it in the codec_probe because by that time ASoC has created its
codec: debugfs node and I can put the dsp debugfs nodes under that. If I
created the debugfs earlier before ASoC has probed the codec that node
won't exist so I'd have to create my own debugfs node, and it seems a bit
odd and untidy to have some codec debug info under the asoc node but some
stuff somewhere else.
> fact that it's not actually factoring out the initialisation that's
> already happening at the ASoC probe isn't good.
WARNING: multiple messages have this Message-ID (diff)
From: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
To: Mark Brown <broonie@kernel.org>
Cc: lgirdwood@gmail.com, patches@opensource.wolfsonmicro.com,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] ASoC: wm_adsp: Add code_probe and codec_remove stubs
Date: Tue, 9 Jun 2015 17:43:29 +0100 [thread overview]
Message-ID: <20150609164329.GC27675@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20150609162045.GF14071@sirena.org.uk>
On Tue, Jun 09, 2015 at 05:20:45PM +0100, Mark Brown wrote:
> On Tue, Jun 09, 2015 at 05:13:56PM +0100, Richard Fitzgerald wrote:
> > On Tue, Jun 09, 2015 at 05:00:43PM +0100, Mark Brown wrote:
>
> > > I'm still not a big fan of the double registration that's being done -
> > > if nothing else the fact that it's not also factoring out the creation
> > > of the DSP controls seems wrong.
>
We can certainly look at factoring out that control creation once we have
a probe function in wm_adsp to put them in. Which is what this patch creates.
> > I don't see the point of trying to fight against the design of ASoC with
> > the second probe. ASoC gives us what we need at the codec_probe stage
> > so why try to invent something different?
>
> Well, you could've still hung things off the struct device - it's not
> like the ASoC level device is a requirement here - and like I say the
I'm doing it in the codec_probe because by that time ASoC has created its
codec: debugfs node and I can put the dsp debugfs nodes under that. If I
created the debugfs earlier before ASoC has probed the codec that node
won't exist so I'd have to create my own debugfs node, and it seems a bit
odd and untidy to have some codec debug info under the asoc node but some
stuff somewhere else.
> fact that it's not actually factoring out the initialisation that's
> already happening at the ASoC probe isn't good.
next prev parent reply other threads:[~2015-06-09 16:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-09 15:16 [PATCH v2 1/2] ASoC: wm_adsp: Add code_probe and codec_remove stubs Richard Fitzgerald
2015-06-09 15:16 ` [PATCH v2 2/2] ASoC: wm_adsp: Add basic debugfs entries Richard Fitzgerald
2015-06-09 15:16 ` Richard Fitzgerald
2015-06-09 16:00 ` [PATCH v2 1/2] ASoC: wm_adsp: Add code_probe and codec_remove stubs Mark Brown
2015-06-09 16:00 ` Mark Brown
2015-06-09 16:13 ` Richard Fitzgerald
2015-06-09 16:20 ` Mark Brown
2015-06-09 16:43 ` Richard Fitzgerald [this message]
2015-06-09 16:43 ` Richard Fitzgerald
2015-06-09 16:55 ` Mark Brown
2015-06-09 16:55 ` 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=20150609164329.GC27675@opensource.wolfsonmicro.com \
--to=rf@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@opensource.wolfsonmicro.com \
/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.