linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Rosin <peda@axentia.se>
To: Crestez Dan Leonard <leonard.crestez@intel.com>,
	Jonathan Cameron <jic23@kernel.org>, <linux-iio@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>, Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Daniel Baluta <daniel.baluta@intel.com>,
	<linux-i2c@vger.kernel.org>, Wolfram Sang <wsa@the-dreams.de>,
	<devicetree@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>
Subject: Re: [PATCH] iio: inv_mpu6050: Add support for auxiliary I2C master
Date: Fri, 29 Apr 2016 12:09:13 +0200	[thread overview]
Message-ID: <cfbef50a-3caa-3372-d911-14dd27c98e27@axentia.se> (raw)
In-Reply-To: <14f3be16-2912-cbed-ab89-08b1c22d827c@axentia.se>

On 2016-04-29 11:29, Peter Rosin wrote:

> On 2016-04-28 12:39, Crestez Dan Leonard wrote:
>> On 04/27/2016 11:39 AM, Peter Rosin wrote:
>>> On 2016-04-23 23:32, Jonathan Cameron wrote:
>>>> On 20/04/16 18:17, Crestez Dan Leonard wrote:
>>>>> The MPU has an auxiliary I2C bus for connecting external
>>>>> sensors. This bus has two operating modes:
>>>>> * pass-through, which connects the primary and auxiliary busses
>>>>> together. This is already supported via an i2c mux.
>>>>> * I2C master mode, where the mpu60x0 acts as a master to any external
>>>>> connected sensors. This is implemented by this patch.
>>>>>
>>>>> This I2C master mode also works when the MPU itself is connected via
>>>>> SPI.
>>>>>
>>>>> I2C master supports up to 5 slaves. Slaves 0-3 have a common operating
>>>>> mode while slave 4 is different. This patch implements an i2c adapter
>>>>> using slave 4 because it has a cleaner interface and it has an
>>>>> interrupt that signals when data from slave to master arrived.
>>>>>
>>>>> Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>
>>>> This one needs acks from:
>>>>
>>>> Device tree maintainer (odd binding ;)
>>>> Peter Rosin (odd binding interacting with the mux support)
>>>> Wolfram (it has a whole i2c master driver in here).
>>>>
>>>> (just thought I'd list these for the avoidance of doubt).
>>> I spot some overlap with the questions in "[RFC] i2c: device-tree:
>>> Handling child nodes which are not i2c devices"
>>> http://marc.info/?l=linux-i2c&m=146073452819116&w=2
>>>
>>> And I think I agree with Stephen Warren that an intermediate placeholder
>>> node would make sense. I.e.
>>>
>>>     mpu6050@68 {
>>>         compatible = "...";
>>>         reg = <0x68>;
>>>         ...
>>>         i2c-aux-mux {
>>>             i2c@0 {
>>>                 #address-cells = <1>;
>>>                 #size-cells = <0>;
>>>                 reg = <0>;
>>>
>>>                 foo@44 {
>>>                     compatible = "bar";
>>>                     reg = <0x44>;
>>>                     ...
>>>                 }
>>>             }
>>>         }
>>>     }
>>>
>>> Or
>>>
>>>     mpu6050@68 {
>>>         compatible = "...";
>>>         reg = <0x68>;
>>>         ...
>>>         i2c-aux-master {
>>>             #address-cells = <1>;
>>>             #size-cells = <0>;
>>>
>>>             gazonk@44 {
>>>                 compatible = "baz";
>>>                 reg = <0x44>;
>>>                 ...
>>>             }
>>>         }
>>>     }
>>>
>>> depending on if you want an aux-mux or an aux-master.
>>>
>>> But I don't know if that intermediate i2c-aux-mux node causes any
>>> problems?
>> It's not clear how that would be implemented. It seems to me that right
>> now i2c_add_mux_adapter assumes that the parent device is a dedicated
>> mux device and all it's children are mux branches. Would this require
>> introducing a new "struct device" for the i2c-aux-master node?
>>
>> It might make sense to make the automatic processing of the parents
>> node's of_node optional and let the caller assign the of_node describing
>> the attached devices.
>>
>> I think the most natural solution would be to require child nodes named
>> i2c-aux-mux and i2c-aux-master to describe aux devices. For backwards
>> compatibility it would be easiest to go with i2c@0/i2c@1 (identified by
>> reg=0/1).
>>
>> But I don't know much about devicetree and I'd rather accept an external
>> suggestion.
>>
> I was thinking that with the new i2c_mux_core in place, it should be pretty simple
> to add a hook to point to another node and only use dev->of_node as a default
> value for where to look for the mux child adapters?
>
Or maybe always look for an intermediate "i2c-mux" node and look there if it exists? Something like this (totally untested) on top of the i2c-mux-core cleanup already in next (should be easy to adapt to 4.5 if you want that). Cheers, Peter

diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 25e9336b0e6e..ff1374f5b4f6 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -179,10 +179,15 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
 	 * nothing if !CONFIG_OF.
 	 */
 	if (muxc->dev->of_node) {
+		struct device_node *mux;
 		struct device_node *child;
 		u32 reg;
 
-		for_each_child_of_node(muxc->dev->of_node, child) {
+		mux = of_get_child_by_name(muxc->dev->of_node, "i2c-mux");
+		if (!mux)
+			mux = muxc->dev->of_node;
+
+		for_each_child_of_node(mux, child) {
 			ret = of_property_read_u32(child, "reg", &reg);
 			if (ret)
 				continue;

  reply	other threads:[~2016-04-29 10:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20 17:17 [PATCH] iio: inv_mpu6050: Add support for auxiliary I2C master Crestez Dan Leonard
2016-04-20 18:17 ` kbuild test robot
2016-04-21 10:02   ` Crestez Dan Leonard
2016-04-23 21:32 ` Jonathan Cameron
2016-04-27  8:39   ` Peter Rosin
2016-04-28 10:39     ` Crestez Dan Leonard
2016-04-29  9:29       ` Peter Rosin
2016-04-29 10:09         ` Peter Rosin [this message]
2016-04-20 20:31 Peter Rosin
2016-04-21 12:01 ` Crestez Dan Leonard
2016-04-21 13:56 Peter Rosin
2016-04-22 10:15 ` Crestez Dan Leonard
2016-04-22 11:01 Peter Rosin

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=cfbef50a-3caa-3372-d911-14dd27c98e27@axentia.se \
    --to=peda@axentia.se \
    --cc=daniel.baluta@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=leonard.crestez@intel.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=pmeerw@pmeerw.net \
    --cc=robh+dt@kernel.org \
    --cc=wsa@the-dreams.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).