All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH] ARM: mach-shmobile: tidyup: sound card detection order
Date: Tue, 29 May 2012 09:11:35 +0000	[thread overview]
Message-ID: <20120529091129.GA26043@verge.net.au> (raw)
In-Reply-To: <87mx4rmqzd.wl%kuninori.morimoto.gx@renesas.com>

On Tue, May 29, 2012 at 12:40:08AM -0700, Kuninori Morimoto wrote:
> 
> Hi Simon, Paul
> 
> Thank you for checking patch
> 
> > > > Is the problem that a previous patch altered the order of the
> > > > ALSA index of the sound cards? And this patch restores the previous order?
> > > > 
> > > > If so, I wonder if this is really necessary as is should
> > > > be possible to set the index using a module parameter if one
> > > > is relying on it.
> > > > 
> > > One would expect so. What happens if the ALSA drivers are built as
> > > modules and inserted in random order today? If you require persistent
> > > assignment then you will have to deal with it either through module
> > > parameters or udev.
> > 
> > I'm unsure if that was a rhetorical question or not,
> > but I believe the answer is yes.
> 
> Yes.
> The ALSA card list order was same as inserted alsa-module
> order if it was built as module.
> This is very OK.
> And I'm not sure ALSA already has index specification method.
> Sorry for my confusion.
> My problem was deferred probe order on built-in.

I was under the impression that the index could be set for a built-in too.
But poking around in /sys on an armadillo board, that seems not to be the
case.

> 
> Current my issue is...
>   normal probe of ALSA-card.0  -> requests probe deferral
>   normal probe of ALSA-card.1  -> requests probe deferral
>   ...
>   deferred-probe of ALSA-card.1  <= order changed
>   deferred-probe of ALSA-card.0  <= order changed
> 
> Now, I re-checked and noticed that
> the main issue was additional method for deferred_probe_pending_list on dd.c.
> 
> Below patch solved this issue.
> What do you think this ?

It seems reasonable to expect things to be appended not prepended,
so I think your patch makes some sense.

I'm not entirely sure it makes any sense to be relying on the
order of cards being initialised. But I guess the order of
initialisation is relied on in other places too.

  parent reply	other threads:[~2012-05-29  9:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-29  6:38 [PATCH] ARM: mach-shmobile: tidyup: sound card detection order Kuninori Morimoto
2012-05-29  6:46 ` Simon Horman
2012-05-29  7:04 ` Paul Mundt
2012-05-29  7:33 ` Simon Horman
2012-05-29  7:40 ` Kuninori Morimoto
2012-05-29  9:11 ` Simon Horman [this message]
2012-05-30  0:25 ` Kuninori Morimoto
2012-05-30  1:09 ` Kuninori Morimoto
2012-05-30  1:30 ` Simon Horman
2012-05-30  1:34 ` Kuninori Morimoto
2012-05-30  1:46   ` [PATCH] driver core: fixup reversed deferred probe order Kuninori Morimoto
2012-05-30  1:46     ` Kuninori Morimoto
2012-06-12 23:17     ` Greg Kroah-Hartman
2012-06-12 23:17       ` Greg Kroah-Hartman
2012-06-13  0:03       ` Kuninori Morimoto
2012-06-13  0:03         ` Kuninori Morimoto
2012-06-13  0:33         ` Greg Kroah-Hartman
2012-06-13  0:33           ` Greg Kroah-Hartman
2012-07-09 21:56     ` Grant Likely
2012-07-09 21:56       ` Grant Likely

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=20120529091129.GA26043@verge.net.au \
    --to=horms@verge.net.au \
    --cc=linux-sh@vger.kernel.org \
    /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.