Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: ALSA development <alsa-devel@alsa-project.org>,
	Linux Samsung SOC <linux-samsung-soc@vger.kernel.org>,
	Jimmy Cheng-Yi Chiang <cychiang@google.com>,
	Takashi Iwai <tiwai@suse.de>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Tzung-Bi Shih <tzungbi@google.com>,
	Sylwester Nawrocki <s.nawrocki@samsung.com>,
	Dylan Reid <dgreid@google.com>
Subject: Re: [alsa-devel] [PATCH v2] ASoC: max98090: save and restore SHDN when changing sensitive registers
Date: Wed, 18 Dec 2019 16:24:22 +0000	[thread overview]
Message-ID: <20191218162422.GG3219@sirena.org.uk> (raw)
In-Reply-To: <f6453e48-cd95-6471-8945-4cc0ab3d04d9@samsung.com>


[-- Attachment #1.1: Type: text/plain, Size: 1450 bytes --]

On Wed, Dec 18, 2019 at 03:48:14PM +0100, Marek Szyprowski wrote:
> On 18.12.2019 14:26, Mark Brown wrote:

> >> - snd_card_new( ) succeed in snd_soc_bind_card( ), so that userspace
> >> can see the control

> > This feels like snd_card_new() is being overly enthusiastic here, I'd
> > expect that we might have other problems elsewhere with that.  I'd not
> > expect userspace to see things until snd_card_register() since between
> > _new() and that we're in the process of building the card up.  Given
> > this we *will* need to handle partially constructed cards after all,
> > unless we change the ALSA core.  Takashi?
> 
> I'm not sure if this is an issue about partially registered card. Here 
> is the boot log:
> 
> https://paste.debian.net/1121543/

> This oops happens when udev tries to do its job. The card is earlier 
> fully registered and advertised by alsa:

> [    3.501198] ALSA device list:
> [    3.501300]   #0: Odroid-U3

That's not what the analysis I was replying to said :(

This log makes no sense to me, if this is the same card that was
registered and announced earlier what caused it to become unregistered
so that we are registering it now?

> If there are any useful logs for tracking this issue, let me know how to
> enable them, so I will provide more logs.

It'd be good to understand this unregistration/probe deferral for a
start...  when did the card get unregistered and why?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2019-12-18 16:27 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20191128152110epcas3p2b205b4b55f6d8bfac42fcb8faaade93c@epcas3p2.samsung.com>
2019-11-28 15:19 ` [alsa-devel] [PATCH v2] ASoC: max98090: save and restore SHDN when changing sensitive registers Tzung-Bi Shih
2019-12-09 18:59   ` [alsa-devel] Applied "ASoC: max98090: save and restore SHDN when changing sensitive registers" to the asoc tree Mark Brown
2019-12-12 14:09   ` [alsa-devel] [PATCH v2] ASoC: max98090: save and restore SHDN when changing sensitive registers Marek Szyprowski
2019-12-12 16:02     ` Marek Szyprowski
2019-12-12 16:48       ` Mark Brown
2019-12-12 18:05     ` Tzung-Bi Shih
2019-12-17 14:18       ` Marek Szyprowski
2019-12-18 13:26       ` Mark Brown
2019-12-18 14:48         ` Marek Szyprowski
2019-12-18 16:24           ` Mark Brown [this message]
2019-12-19  8:03             ` Marek Szyprowski
2019-12-19 12:37               ` Mark Brown
2019-12-19 12:54                 ` Marek Szyprowski
2019-12-19 13:05                   ` Mark Brown
2019-12-19 13:41                     ` Marek Szyprowski
2019-12-19 19:16                       ` Mark Brown
2019-12-20  8:28                         ` Marek Szyprowski
2019-12-20  9:05                           ` Marek Szyprowski
2019-12-20 12:01                             ` Mark Brown
2020-01-08 11:54                               ` Marek Szyprowski
2020-01-09 21:18                                 ` 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=20191218162422.GG3219@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=cychiang@google.com \
    --cc=dgreid@google.com \
    --cc=krzk@kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=s.nawrocki@samsung.com \
    --cc=tiwai@suse.de \
    --cc=tzungbi@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox