From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: "Koul, Vinod" <vinod.koul@intel.com>
Cc: alsa-devel@alsa-project.org,
Harsha Priya <priya.harsha@intel.com>,
selma.bensaid@intel.com, lrg@slimlogic.co.uk
Subject: Re: [PATCH] ASoC: Make register_card API available to drivers
Date: Thu, 13 Jan 2011 11:26:08 +0000 [thread overview]
Message-ID: <20110113112607.GA9936@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1294901358-14364-1-git-send-email-vinod.koul@intel.com>
On Thu, Jan 13, 2011 at 12:19:18PM +0530, Koul, Vinod wrote:
> The register_card is an internal API which soc_probe uses to register the card.
> In order to create multiple cards we need to create multiple instances of
> soc-audio device. If we exposes the register card API for drivers to use, then
> machine driver can register their cards directly
> This patch makes register_card and unregister_card API available to machine
> drivers. This also maintains compatibility with older method of registration
> which can be marked depreciated and removed eventually.
This is probably mostly OK but it'd be good if you could break it down
into a small patch series. At present it does a bunch of refactoring
and also adds the API - it'd be better if there were a sequence of
patches, each doing a single refactor, followed by a final patch which
exports the API.
Splitting it up like this will allow bisection if there's a problem
introduced by the change and makes review very much easier as there's
only one change to think about in a given patch.
> @@ -1870,16 +1868,12 @@ static int soc_probe(struct platform_device *pdev)
> struct snd_soc_card *card = platform_get_drvdata(pdev);
> int ret = 0;
>
> + /* no card, so machine driver will register explictly */
> + if (!card)
> + return 0;
> +
Hrm, this looks a bit surprising. When we're registering directly from
the machine drivers I'd not expect us to end up going through soc-probe
at all and...
> /* Bodge while we unpick instantiation */
> card->dev = &pdev->dev;
...that the card device would be something passed in from the machine
driver (probably something that the architecture code registered in
order to allow the machine driver to probe, but possibly something
else).
next prev parent reply other threads:[~2011-01-13 11:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-13 6:49 [PATCH] ASoC: Make register_card API available to drivers Koul, Vinod
2011-01-13 11:26 ` Mark Brown [this message]
2011-01-13 11:36 ` Koul, Vinod
2011-01-13 11:42 ` Mark Brown
2011-01-13 13:24 ` Koul, Vinod
2011-01-13 13:34 ` Mark Brown
2011-01-13 14:01 ` Koul, Vinod
2011-01-13 15:08 ` Mark Brown
2011-01-13 17:13 ` Koul, Vinod
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=20110113112607.GA9936@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=lrg@slimlogic.co.uk \
--cc=priya.harsha@intel.com \
--cc=selma.bensaid@intel.com \
--cc=vinod.koul@intel.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 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.