All of lore.kernel.org
 help / color / mirror / Atom feed
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: Device probe order (i2c regulator vs. platform device)
Date: Wed, 24 Mar 2010 10:21:44 +0000	[thread overview]
Message-ID: <20100324102144.GA21935@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <E4D3F24EA6C9E54F817833EAE0D912AC09C80E05C7@bssrvexch01.BS.local>

On Wed, Mar 24, 2010 at 08:10:38AM +0100, Marek Szyprowski wrote:

[Reflowed into 80 columns - please fix your mail client to wrap text, it
makes it very much easier to read your messages.]

> I've encountered a problem with regulator framework and the device
> probe order. In my system there is a pmic chip connected thought i2c bus
> and a platform device (let's call it A) that depends on the regulator
> device (for proper probing pmic chip must enable voltage to the device
> A). In the current configuration the i2c driver is also a platform
> device. However during the system initialization the device A is probed
> before the i2c driver would register pmic chip and its regulators.

This is (if I'm parsing what you say above correctly) a very common case
- if you look at most of the existing PMIC core and regulator drivers
you'll see that their initcalls are subsys_initcall(), and similarly for
the I2C controller drivers they use.  This means that at boot the PMICs
come up before pretty much any other device.

> How I can delay probing the device A to the moment when the regulator
> device will be available in the system? Is there any generic was of
> changing the device probe order?

The solution above is the other way around - it ensures that the
regulators come up first - but achieves the same effect.  Unfortunately
it's not as generic as would be best but it resolves the issues.

  parent reply	other threads:[~2010-03-24 10:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-24  7:10 Device probe order (i2c regulator vs. platform device) Marek Szyprowski
2010-03-24  9:19 ` Andy Green
2010-03-24 11:11   ` Marek Szyprowski
2010-03-24 12:50     ` Andy Green
2010-03-24 13:11       ` Mark Brown
2010-03-24 13:22         ` Andy Green
2010-03-24 11:32   ` Mark Brown
2010-03-24 12:11     ` Andy Green
2010-03-24 14:01       ` Mark Brown
2010-03-24 14:38         ` Andy Green
2010-03-25 10:22           ` Mark Brown
2010-03-25 10:52             ` Andy Green
2010-03-24 10:21 ` Mark Brown [this message]
2010-03-24 10:57   ` Andy Green
2010-03-24 11:02   ` Marek Szyprowski
2010-03-24 11:08     ` Mark Brown
2010-03-24 11:27       ` Andy Green
2010-03-24 12:19         ` Mark Brown
2010-03-24 12:29           ` Andy Green

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=20100324102144.GA21935@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --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 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.