[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180709124117.GG16082@sirena.org.uk>
Date: Mon, 9 Jul 2018 13:41:17 +0100
From: Mark Brown <broonie@...nel.org>
To: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc: Rohit kumar <rohitkr@...eaurora.org>, lgirdwood@...il.com,
robh+dt@...nel.org, mark.rutland@....com, plai@...eaurora.org,
bgoswami@...eaurora.org, perex@...ex.cz, tiwai@...e.com,
alsa-devel@...a-project.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/5] ASoC: qcom: add sdm845 sound card support
On Mon, Jul 09, 2018 at 01:34:42PM +0100, Srinivas Kandagatla wrote:
> On 09/07/18 12:14, Mark Brown wrote:
> > > +static const struct component_master_ops sdm845_ops = {
> > > + .bind = sdm845_bind,
> > > + .unbind = sdm845_unbind,
> > > +};
> > Why is this using the component stuff rather than the normal support for
> > finding the components of audio cards?
> Could you elaborate this please?
> Do you mean something like snd_soc_lookup_component()? Or in general audio
> card binding during startup.
Just the normal audio card binding during startup.
> AFAIU, The issue with that mechanism or EPROBEDEFER is that it works only
> for first time.. for the second time(restart usecase) there are no hooks
> like bind/unbind.
This is not the case, the card will be unbound at the ASoC level when
any of the components are removed and then probed again when they
reappear.
> The reason why we chose to use component framework is because of bind and
> unbind functionality. Am more than happy to rework on this if there is
> already a alternative mechanism in ASoC which can provide this.
The component framework is a generalization of what ASoC does.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists