From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4] ASoC: sgtl5000: defer the probe if clock is not found
Date: Mon, 1 Jul 2013 12:33:10 +0100 [thread overview]
Message-ID: <20130701113310.GA24642@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20130701094525.GY27646@sirena.org.uk>
On Mon, Jul 01, 2013 at 10:45:25AM +0100, Mark Brown wrote:
> On Mon, Jul 01, 2013 at 04:16:09PM +0800, Shawn Guo wrote:
> > It's not always the case that clock is already available when sgtl5000
> > get probed at the first time, e.g. the clock is provided by CPU DAI
> > which may be probed after sgtl5000. So let's defer the probe when
> > devm_clk_get() call fails and give it chance to try later.
>
> Why not fix this in the clock API - the same logic is going to apply to
> a great proportion of clocks?
It's not ever clear whether a missing clock is because it's just not
provided or whether it's because it hasn't been registered yet. The
decision to defer on missing resources is something which a _driver_
using the resource should make, not the subsystem providing the
resource - because the driver should know better whether that resource
is optional, whether it can continue to initialise without it and maybe
try again later, or whether it does need to defer.
Take for instance a video driver. :) It may be that it can't do all
resolutions, but it can do some without an external clock, so it may
decide that it can initialise without the external clock and allow one
of the possible modes to be set - and when the external clock does
appear, it can then allow the other modes.
That kind of information is unknown at the subsystem level, and so the
subsystem level should only ever return "I don't know about this" not
"defer probe".
next prev parent reply other threads:[~2013-07-01 11:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-01 8:16 [PATCH 0/4] Fix mxs audio regressions Shawn Guo
2013-07-01 8:16 ` [PATCH 1/4] ASoC: sgtl5000: give it a ramping time before writting Shawn Guo
2013-07-01 10:07 ` Mark Brown
2013-07-01 10:54 ` Marek Vasut
2013-07-01 13:55 ` Shawn Guo
2013-07-01 14:12 ` [alsa-devel] " Fabio Estevam
2013-07-01 14:26 ` Shawn Guo
2013-07-01 14:34 ` Shawn Guo
2013-07-01 15:11 ` Fabio Estevam
2013-07-01 15:33 ` Shawn Guo
2013-07-01 15:42 ` Fabio Estevam
2013-07-01 17:43 ` Marek Vasut
2013-07-01 19:14 ` Fabio Estevam
2013-07-01 19:28 ` Alexandre Belloni
2013-07-02 2:16 ` Shawn Guo
2013-07-01 19:23 ` Alexandre Belloni
2013-07-01 14:04 ` Shawn Guo
2013-07-01 10:57 ` Lothar Waßmann
2013-07-01 8:16 ` [PATCH 2/4] ASoC: sgtl5000: defer the probe if clock is not found Shawn Guo
2013-07-01 9:45 ` Mark Brown
2013-07-01 11:33 ` Russell King - ARM Linux [this message]
2013-07-01 12:51 ` Mark Brown
2013-07-01 8:16 ` [PATCH 3/4] ASoC: mxs: register saif mclk to clock framework Shawn Guo
2013-07-01 10:11 ` Mark Brown
2013-07-01 8:16 ` [PATCH 4/4] ARM: mxs: saif0 is the clock provider to sgtl5000 Shawn Guo
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=20130701113310.GA24642@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.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 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).