From: Guenter Roeck <guenter.roeck-IzeFyvvaP7pWk0Htik3J/w@public.gmane.org>
To: Peter Korsgaard <jacmet-OfajU3CKLf1/SzgSGea1oA@public.gmane.org>
Cc: "linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: Using the gpio i2c multiplexer driver
Date: Wed, 16 Feb 2011 06:28:06 -0800 [thread overview]
Message-ID: <20110216142806.GA13872@ericsson.com> (raw)
In-Reply-To: <87ei789z3g.fsf-uXGAPMMVk8amE9MCos8gUmSdvHPH+/yF@public.gmane.org>
Peter,
On Wed, Feb 16, 2011 at 03:13:07AM -0500, Peter Korsgaard wrote:
> >>>>> "Guenter" == Guenter Roeck <guenter.roeck-IzeFyvvaP7pWk0Htik3J/w@public.gmane.org> writes:
>
> Guenter> Hi all,
>
> Guenter> I am trying to use the new GPIO based I2C
> Guenter> multiplexer. Unfortunately, I have an initialization problem
> Guenter> with it.
>
> Guenter> Some time after registering the multiplexer as platform driver, its
> Guenter> probe function is called. Unfortunately, that does not happen in sync
> Guenter> with I2C adapter initialization. The GPIO mux probe function is called
> Guenter> before the parent's (ie the multiplexed I2C adapter) probe function is
> Guenter> called. As a result, the GPIO mux driver does not find its parent i2c
> Guenter> adapter, and the probe function aborts with an error.
>
> Guenter> Any idea how I I can fix the problem, ie how I can ensure that
> Guenter> the GPIO mux probe function is only called after its parent
> Guenter> I2C adapter is initialized ?
>
> What i2c bus controller are you using? Are you registering it's platform
> data very late (E.G. after you register the platform data for gpiomux)?
>
It is part of an mfd device. The same device also hosts the multiplexer pin.
The bus drivers and the multiplexer driver are instantiated from the mfd core
driver, so I can control the order.
> If you do register the platform data in the correct order, things SHOULD
The I2C bus driver is registered before the GPIO driver.
> work correctly as busses are listed in drivers/i2c/Makefile before
> muxes, but alternatively you could play with the init order (E.G. use
> subsys_initcall instead of module_init in the bus driver, see
> b8680784875 for an example).
>
I tried that, but it does not help.
Here is a log:
[ 16.027528] spanky_i2c spanky_i2c.12: probe 12
[ 16.130652] spanky_i2c spanky_i2c.13: probe 13
[ 16.131095] spanky-i2cmux spanky-i2cmux.72: Parent adapter (54) not found
^^^ This is the (renamed) gpio mux driver
[ 16.284040] spanky_i2c spanky_i2c.14: probe 14
[ 16.292194] spanky_i2c spanky_i2c.15: probe 15
[ 16.300029] spanky_i2c spanky_i2c.18: probe 18
[ 16.394173] spanky_i2c spanky_i2c.19: probe 19
[ 16.537542] spanky_i2c spanky_i2c.20: probe 20
[ 16.544743] spanky_i2c spanky_i2c.21: probe 21
[ 16.552497] spanky_i2c spanky_i2c.24: probe 24
[ 16.657112] spanky_i2c spanky_i2c.25: probe 25
[ 16.806678] spanky_i2c spanky_i2c.26: probe 26
[ 16.815207] spanky_i2c spanky_i2c.27: probe 27
[ 17.396906] spanky_i2c spanky_i2c.30: probe 30
[ 17.500035] spanky_i2c spanky_i2c.31: probe 31
[ 17.652316] spanky_i2c spanky_i2c.32: probe 32
[ 17.659550] spanky_i2c spanky_i2c.33: probe 33
[ 18.137137] spanky_i2c spanky_i2c.36: probe 36
[ 18.239038] spanky_i2c spanky_i2c.37: probe 37
[ 18.390166] spanky_i2c spanky_i2c.38: probe 38
[ 18.400315] spanky_i2c spanky_i2c.39: probe 39
[ 18.857240] spanky_i2c spanky_i2c.42: probe 42
[ 18.961723] spanky_i2c spanky_i2c.43: probe 43
[ 19.117111] spanky_i2c spanky_i2c.44: probe 44
[ 19.125823] spanky_i2c spanky_i2c.45: probe 45
[ 19.746365] spanky_i2c spanky_i2c.54: probe 54
^^^ this is where the i2c bus driver is registered
[ 19.758068] spanky_i2c spanky_i2c.55: probe 55
[ 19.768026] spanky_i2c spanky_i2c.55: Registering I2C device pca9541 at 0x74
[ 19.768378] spanky_i2c spanky_i2c.55: Registering I2C device pca9541 at 0x75
[ 19.768729] spanky_i2c spanky_i2c.56: probe 56
[ 19.778987] spanky_i2c spanky_i2c.57: probe 57
[ 19.789395] spanky_i2c spanky_i2c.57: Registering I2C device pca9541 at 0x70
[ 19.789741] spanky_i2c spanky_i2c.58: probe 58
As you can see, I have a somewhat special situation, with a large number
of I2C bus driver instances. It would work if there was only one instance,
but that does not help me.
I thought about registering the GPIO driver as I2C device as suggested
in the other response, but that would be a bit kludgy and I would prefer
to avoid it if I can.
Thanks,
Guenter
next prev parent reply other threads:[~2011-02-16 14:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-15 22:47 Using the gpio i2c multiplexer driver Guenter Roeck
2011-02-16 7:07 ` Michael Lawnick
[not found] ` <4D5B77AE.20307-Mmb7MZpHnFY@public.gmane.org>
2011-02-16 14:29 ` Guenter Roeck
2011-02-16 8:13 ` Peter Korsgaard
[not found] ` <87ei789z3g.fsf-uXGAPMMVk8amE9MCos8gUmSdvHPH+/yF@public.gmane.org>
2011-02-16 14:28 ` Guenter Roeck [this message]
2011-02-16 23:50 ` Guenter Roeck
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=20110216142806.GA13872@ericsson.com \
--to=guenter.roeck-izefyvvap7pwk0htik3j/w@public.gmane.org \
--cc=jacmet-OfajU3CKLf1/SzgSGea1oA@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.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).