From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752766AbcD2KJ3 (ORCPT ); Fri, 29 Apr 2016 06:09:29 -0400 Received: from mail-db3on0130.outbound.protection.outlook.com ([157.55.234.130]:44323 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751225AbcD2KJ0 (ORCPT ); Fri, 29 Apr 2016 06:09:26 -0400 Authentication-Results: codeaurora.org; dkim=none (message not signed) header.d=none;codeaurora.org; dmarc=none action=none header.from=axentia.se; Subject: Re: [PATCH] iio: inv_mpu6050: Add support for auxiliary I2C master To: Crestez Dan Leonard , Jonathan Cameron , References: <5b1937140558514b3e43ed2c21ee860ecbac61ec.1461172603.git.leonard.crestez@intel.com> <6ab228db-9695-ac22-9c65-fd15c4837c45@axentia.se> <5721E871.8010003@intel.com> <14f3be16-2912-cbed-ab89-08b1c22d827c@axentia.se> CC: , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Daniel Baluta , , Wolfram Sang , , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala From: Peter Rosin Message-ID: Date: Fri, 29 Apr 2016 12:09:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <14f3be16-2912-cbed-ab89-08b1c22d827c@axentia.se> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [217.210.101.82] X-ClientProxiedBy: AM3PR02CA0063.eurprd02.prod.outlook.com (10.163.180.31) To DB5PR02MB1303.eurprd02.prod.outlook.com (10.164.177.149) X-MS-Office365-Filtering-Correlation-Id: a8c76f1e-82c6-41d9-d575-08d370165459 X-Microsoft-Exchange-Diagnostics: 1;DB5PR02MB1303;2:GnUbIpITIdenQOsJzhc8BvKmANGSqhdlCftmDtOfgOjZuBi3y9dd2JCz0A0tmitoMvQZUEDyFhi7GouUJLYCxa+Fu34LDpHn1SbENOBIYvJ9JImmnhTo8H/t4GqeQaNmX7WNsPT3yxiMsL2mM2Lsh9PljVxnMgMttOsctYtOY4aVDwwaq08RFIuGM37/3Ozd;3:dzwbD0LreGkv6GGpXIJWCbYnsM4o+GGlYp4RoEOiPu6XA6rur7+0JjsmIcXPGtRvx9kFNV8hszheDi3+TcUBo2C5eOZMWHpkhc/QF7SE9ciNHLuz5YQqPDtn2LOJU3JC X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR02MB1303; X-Microsoft-Exchange-Diagnostics: 1;DB5PR02MB1303;25:7ul06iO5JUuLxPmr+G7+6jK0s1bL9eEq2RIKSgE6UxYpsCyrEW6Lw2VIxdeLGxERAVjE2jxZIyHpPBBelqFyIQcZF+MAeuOjWg96rWV/JK1o4pH4nmg12+jmtl1D+g9pfaUap1jkXzqovwKuWN8o/AIKlJgb+R4GLjoqw45o3F4mY5pGY3UJQkaik5/ssvl1p4aekA+QR92z5aDkz2TayOGOqPZM1F0n8kjGdndre86sTXmYl0uLhMbjeBE0wt0hQb7gZatk5mw4RqlavNmHe9p7KY1i7Z3D4Dx9OU6losBqlRUtP2BNv7f6fVt+Wr3GZY/fwb0qEL0CRvw1KwLjYhNsUWgUkhzsSUf+GSugomUTqswVMPl2SkOl0/w1wnqc1VUhkT5CgjZTZ1RvMm9OGiqGgaPmpSZsBKe0IGvFmkQjjumbDV2KPXz1mFh6/6PKdIzmgY5/uFyGV3pW+TvaKPHqaUWpbtx+S5jBgEhKn2vSq1qDZP0eYeQcgZZr2dMfxxhnv2/dtbSVQzGwWXNUiE5jVvRTLzk6OBSvGtz9QYCQtAvN6Q9lc7ufiur4d1AYbsiE6sVgzsJglM2fkKZWoNB5nzOBDXFuw323KctBG5oTf7PeaZUfLHXXVxStcJSiQZfNTJFNoTI5I14QTmAMpoFyUgMiZR9LbPoSU1aewOPbxKBAPlfyDLRDqoH4LvEpl0+mw0wQEKBgrTcLsM6s0iofqiToSBfLfaFwEhCEcjI= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(9101521072)(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046);SRVR:DB5PR02MB1303;BCL:0;PCL:0;RULEID:;SRVR:DB5PR02MB1303; X-Microsoft-Exchange-Diagnostics: 1;DB5PR02MB1303;4:ozlg7jsPB5adndXt5Ps29dzicsvK4VelYfBksG+wn/QA5ifk0N5elMjzAgjpECyVIjebgqWKnyjcuQPxzemW/7/LsxR1pjc/SjjddTFAXtL1i8Lo+ATjKwd3IXlvkJlE1fpjvaVr815nNDXR6zwwkgmWKvdbAfjah81A+cnRk55Se7U1g01uvPn84MHn0XQqA1UixLYiikwezAi8GJ3xeaUFyXIC3lhbBrBoT+Oo8Dcxm4xRGAQq6UP2Qej0Xi28MSMAg8VrVdX6bDXGWIfS+/KVTWIyBeMQQREnk2ejdW+m7Im88LobqC0JB4dw5OqAYLDvYto4kalZmDYJ9NeMCQbOGWUud7nN16fJY783CHMtYUnbx9qYSRbgeygMVYi8B1psUwuHAFLyOrBlknppPtRce4kgdeKn4TvBuuUVkI5U1d38/oudwL0PKgskw0uOLlyXfcutRyZOMiEK0lvlsQ== X-Forefront-PRVS: 0927AA37C7 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(6049001)(209900001)(377424004)(24454002)(377454003)(189998001)(117156001)(64126003)(86362001)(93886004)(83506001)(230700001)(575784001)(19580395003)(19580405001)(50986999)(76176999)(54356999)(33646002)(5001770100001)(5004730100002)(4001350100001)(65956001)(77096005)(66066001)(2950100001)(15395725005)(31696002)(15975445007)(36756003)(23746002)(50466002)(42186005)(31686004)(74482002)(81166005)(1096002)(6116002)(586003)(3846002)(2906002)(4326007)(5008740100001)(5890100001)(65826006)(42262002)(6606295002);DIR:OUT;SFP:1102;SCL:1;SRVR:DB5PR02MB1303;H:[192.168.0.125];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;DB5PR02MB1303;23:yb7g+5qzHrLLsxVWnvFDKmEWgMnjtM2qrPxHy?= =?Windows-1252?Q?TcW6AvJfDfL+g5MH3XpqSkCd29EC0K8+hFur3CJ+Vwmel2eudy4sC4xP?= =?Windows-1252?Q?DFmJ0bevgmKLwJ+FFO/o4cmq0GGSHVE0b6iBaOvKPsN1r9lckwpr2AD3?= =?Windows-1252?Q?289dqAYS9WKa2xzVF16MNNOACTMsyxGbjhB9ys8cty2vXjbuvqqN2279?= =?Windows-1252?Q?lM1OdUGiVICdB/mRi15kKILsdpUOhrruJ8wCVrdVVLlnMU/crxqk66bt?= =?Windows-1252?Q?Wr4qQ6Rs9o6MTk5j6XF5nskNpqG4lsBYSGD8fPPdjGIFkBozKvEtNNJD?= =?Windows-1252?Q?4PNS3Hy3z4k4CAPN/p6tN1NQAEXcl0RJ/+HcLEKOk+2dbXpi1DaJWUKH?= =?Windows-1252?Q?hQrIN7Q6oZP8plgOeQ9bWez/oE5Gfo2vN/tk04+ABg/MTjFNTRaMddV4?= =?Windows-1252?Q?kI4ufzsobfXA539/yQ/rlThnrZdPPlSzYRAEa2rm1r2uEldhL4nAelM4?= =?Windows-1252?Q?ceXQOqT0hp+LK9GvkO1htaQJRHEi/tMoZAyqhz7JzuHFogZZyMYMxP1O?= =?Windows-1252?Q?lBucvzIKbrVYMMStRRJmgW307J+EfrTafQ9gFoklJNIjmh7gCW4epd7h?= =?Windows-1252?Q?81IRee3psPl68X2vKll2FnwUZlASPC7kEJAvm8wu+7L7HZA/ZQ7LEw8b?= =?Windows-1252?Q?TCtMPF9yXmapzq/gThi47qRaaUxMgggNarkiXBsU9OMIj/KMlu0aLb/w?= =?Windows-1252?Q?mzH4ESk2lDiDQVdUKuEBWGDD7TZMkfYm2pShddy6VpJXuCkRymNRlVxH?= =?Windows-1252?Q?7Cl/dssTgnbhpkZNomHbu5fWPOdnXzUfnwjXyw8QxW2hNHa6ysR8h4HZ?= =?Windows-1252?Q?F3/saBe6DGyKF0LkyYpAEzD1W6kT0mZDPo5CYyH5SuHN10veXkZ6vDsH?= =?Windows-1252?Q?/CLVFZdsNJ424bBkfFpweNYqysEHdT6AEPDKRD8nXOv/FfmIR6Vp1PlE?= =?Windows-1252?Q?WxX3mq/F4+4fCC0Wq1N0UNJBG4ZYkmnNDBDA0+Js/TZsOgxkLsVJADuB?= =?Windows-1252?Q?jwtg1NQOmz4h8LVqoCcqDyEwJ9ytcVGDP45PRs0Oa/pbPEf2gCcl7WMj?= =?Windows-1252?Q?mu5YcgWktO4OoYc1Gteidkw4b77f4/j/PA6YYshAJg7c+zCuFkOEPag/?= =?Windows-1252?Q?3HIN98Pw4XkGV047pO8LaX2g8T7GTKG7hGmnrgMTgYdmuWt0fBdV+JOF?= =?Windows-1252?Q?G+QjaF1osKZj6Tjfr1hVdeIQ7FI2wnL12f6ehwh0N1Wj1xDMIPT3OBLS?= =?Windows-1252?Q?9pqjcqmZcRbl4xTxauDJvJY6qhA1snHpeckgjII9FdRN16blFFDeZWC0?= =?Windows-1252?Q?cRfe3u5PnSjkkN7JdqQ4+kDaUTQX4bjFQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;DB5PR02MB1303;5:MwoQm84vhOYnE/unVHsv3M//LNo9OZeEjRyRe9nNK4AOgXa8oJyaAqU1iXU8hrebhcka2IOUZbVDGj1BvsYKq+IS3xfd0DG30sZBvda/lDYP1He2wk7LetoPHpEDSPjlZkuxyOtqeJkegodCOuE8ZA==;24:7P/ALrSP5AcI7wI8cQfQgjCcPjxrOzw8feLhJdtGPzmxUpxq+aBIcCGWolaP6vzIANSg6WEtLVQ73Mc6PevugGaYOeXez83WntFEpCfzE8E=;7:FG6ZKq3xsAYVcpUhAEkGv8WbY4e63b0s+xC037oG9lifN5b+LPjInpvpGUzW9P4H0zXaWuJu8359nmY+7/+m2nfQ2vcWUubQknE0o8d0uM9LWiHtW07rOIkl+8ISbYBT6b1s9sHeVHg3W1/PYtsJUPASZiTFshQPfHBZYzZGWK8h+w+GsJK+R4s8iGz9B6BH SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: axentia.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Apr 2016 10:09:18.0823 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR02MB1303 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >>>> 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", ®); if (ret) continue;