alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Nicolin Chen <Guangyu.Chen@freescale.com>
To: Mark Brown <broonie@kernel.org>
Cc: tiwai@suse.de, alsa-devel@alsa-project.org,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	lgirdwood@gmail.com
Subject: Re: [PATCH] ASoC: imx-spdif: Use module_init() to handle platform_device_register()
Date: Tue, 17 Dec 2013 11:05:09 +0800	[thread overview]
Message-ID: <20131217030507.GA1441@MrMyself> (raw)
In-Reply-To: <20131216221710.GH3185@sirena.org.uk>

On Mon, Dec 16, 2013 at 10:17:10PM +0000, Mark Brown wrote:
> On Mon, Dec 16, 2013 at 09:19:58PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Dec 16, 2013 at 07:47:17PM +0000, Mark Brown wrote:
> > > What should work right now is for the module to ensure that the S/PDIF
> > > CODEC drivers are loaded before it is by linking to some symbol from
> > > there.  This is a total hack though.  Nicer would be for the machine
> > > driver to either directly register S/PDIF DAIs (rather than devices that
> > > then register the DAIs) or to create a card subdevice in parallel with
> > > the S/PDIF ones and hook the card registration off that.
> 
> > That creates much more complexity though, and adds yet more possibility
> > for unreliability into this.  "Keep it simple" is well worth following.
> 
> I don't see registering the DAIs directly as adding complexity here;
> it's essentially what the current code is trying to do and doesn't
> change the normal device registration flow at all.  I do agree that the
> card subdevice is more complex, I don't particularly like that idea
> myself. 

Thank you for the detailed advices. I'll first try to register the CODEC
DAI directly.

> > The simple thing here is to declare the codec device in the module init,
> > before registering the card driver, and cleaning it up at the appropriate
> > moment.  That way, the card platform driver gets registered and it can
> 
> It's certainly simple and it's definitely what I'd recommend for non-DT
> systems.  For DT systems it'll cause issues if two drivers both try to
> register the same device on module load and the second one to get loaded
> checks for errors.  Another way is just to do that in the core so we

And this might be another topic that we wouldn't have this problem if we
could use DT nodes for the S/PDIF CODEC driver as well. Since we are now
using DT systems, mixing up a non-DT way might have this kinda unexpected
result, although I admit this should be the responsibility driver owners
and here is mine. But I'm still wondering is there any possibility for us
to find a balanced way to enroll the S/PDIF CODEC driver in DT?

Thank you,
Nicolin Chen

  reply	other threads:[~2013-12-17  3:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-16 10:36 [PATCH] ASoC: imx-spdif: Use module_init() to handle platform_device_register() Nicolin Chen
2013-12-16 19:47 ` Mark Brown
2013-12-16 21:19   ` Russell King - ARM Linux
2013-12-16 22:17     ` Mark Brown
2013-12-17  3:05       ` Nicolin Chen [this message]
2013-12-17 10:31       ` Nicolin Chen
2013-12-18 13:04         ` Mark Brown
2013-12-20  7:02           ` Nicolin Chen

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=20131217030507.GA1441@MrMyself \
    --to=guangyu.chen@freescale.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux@arm.linux.org.uk \
    --cc=tiwai@suse.de \
    /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;
as well as URLs for NNTP newsgroup(s).