[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180709163326.GI16082@sirena.org.uk>
Date: Mon, 9 Jul 2018 17:33:26 +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 03:02:11PM +0100, Srinivas Kandagatla wrote:
> On 09/07/18 13:41, Mark Brown wrote:
> > > AFAIU, The issue with that mechanism or EPROBEDEFER is that it works only
> > 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.
> I did try this and It works only for first time! May be am missing
> something!
> snd_soc_component_del_unlocked() unregisters the sound card totally. so for
> the second time (After DSP stop) there is no registered sound card in
> place.. Am not sure how this is supposed to work?
> The reason I think it works for the first time is because of EPROBEDEFER
> from the machine driver.
Ugh, right - we ripped out that code because there's no sensible use
case for it so now we don't keep the cards on a list. The expectation
is that if someone is going around removing bits of the card they can
probably figure out that they should be removing the card first.
In any case the place to implement this is in the core, there's nothing
special about your cards here. Either the core should be using the
component framework or the card list should be resurrected and we open
code it. This isn't something that's unique to your device.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists