From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751590AbcDTUqe (ORCPT ); Wed, 20 Apr 2016 16:46:34 -0400 Received: from mail-db3on0107.outbound.protection.outlook.com ([157.55.234.107]:53893 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751092AbcDTUqb convert rfc822-to-8bit (ORCPT ); Wed, 20 Apr 2016 16:46:31 -0400 From: Peter Rosin To: Crestez Dan Leonard , Jonathan Cameron , "linux-iio@vger.kernel.org" CC: "linux-kernel@vger.kernel.org" , "Hartmut Knaack" , Lars-Peter Clausen , "Peter Meerwald-Stadler" , Daniel Baluta , "linux-i2c@vger.kernel.org" , Wolfram Sang , "devicetree@vger.kernel.org" , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , "Kumar Gala" , Peter Rosin Subject: Re: [PATCH] iio: inv_mpu6050: Add support for auxiliary I2C master Thread-Topic: [PATCH] iio: inv_mpu6050: Add support for auxiliary I2C master Thread-Index: AdGbQXf6Bzi52Y0WRxGAXzl8IgBtxQ== Date: Wed, 20 Apr 2016 20:31:00 +0000 Message-ID: Accept-Language: en-US, sv-SE Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=axentia.se; x-originating-ip: [217.210.101.82] x-ms-office365-filtering-correlation-id: 69dbbaf0-f1c2-45bd-679f-08d3695ab002 x-microsoft-exchange-diagnostics: 1;AM4PR02MB1300;5:RM2+yTAyWXYGEJb5iwzKJ0a4y/HhDc1raq9YKR9fAvn2GBnoavzZBitwXujNSmBqpeSYKyvIIowCQy6s91FW/X3rU7sh2Syw5obF7nh+EegReulan4rLJciuPq1vT7k6tMd8FD5NCibrfz9c/8GIjg6jPddkg2Asq7lcAb+a6hjsrpEcd+uPQIslZGUDfMp5;24:bKhPqMIQ00VaCH5ca6HL/OF0fHqt1kC/9aPYusBCdzmBq7NLSg8vzkEsYUB6cMscpDVjcAXG5mNTBbX80ALEwAv4hn1rYvuJ90BN49h4an0=;7:rAAq9nIQ/kfW5Wo7gGf5QgRUQ/i8MCiZI0Zro9nM9dfqMFKRs/vkbfKKNhZg8JBzFxqaiWvv5wwrp69j55/foDIh49/QSRJbn6+PuDqGJXgB9owjujZr/REZtqmZKY5q59muPp/iBi+wctoD1D46xRaegL70dpRSCuxiOGADlr051nQverJcmz7g/vbAlie5oibx3VEYIaRbKRQnm/GXohj87XIKtWhAO776Aaq1mOI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR02MB1300; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(9101521026)(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041046)(6043046);SRVR:AM4PR02MB1300;BCL:0;PCL:0;RULEID:;SRVR:AM4PR02MB1300; x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(24454002)(33656002)(19580405001)(9686002)(122556002)(66066001)(2906002)(4001430100002)(1220700001)(5003600100002)(76576001)(5008740100001)(19580395003)(5002640100001)(2501003)(3660700001)(6116002)(102836003)(3846002)(10400500002)(3280700002)(5004730100002)(50986999)(77096005)(586003)(74316001)(92566002)(86362001)(4326007)(81166005)(54356999)(87936001)(5001770100001)(2900100001)(74482002)(189998001)(1096002)(107886002)(15975445007)(7059030)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:AM4PR02MB1300;H:AM4PR02MB1299.eurprd02.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: axentia.se X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 20:31:00.6855 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4ee68585-03e1-4785-942a-df9c1871a234 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR02MB1300 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 is based on earlier work by Daniel Baluta : > https://www.spinics.net/lists/linux-iio/msg23573.html > > Changes since that version: > * Nest the adapter in inv_mpu6050_state instead of making it static > * Explicitly forward of_node "i2c-aux-master" to allow describing aux devices > via devicetree. > > For bypass/mux mode devicetree works automatically. The forwarding is based on > the "chan_id" parameter to i2c_add_mux_adapter and is implemented here: > > http://lxr.free-electrons.com/source/drivers/i2c/i2c-mux.c#L158 With any luck [1], this reference will be stale when 4.6 is released. It should be qulified with a version, something like .../i2c-mux.c?v=4.5#L158 > Perhaps it might be better for devices handled via master mode to be described > via i2c@1? This would work by scanning the mpu node's children for something > with reg == 1. The 0 in i2c@0 (which is used by the mux mode) is the index of the mux slave meaning that i2c@1 would be a second mux slave on the same mux, but this is not a real mux as such, it is a gate which is piggybacking on the i2c mux infra. So, this "mux" can't have a second slave which is why only 0 is valid. Tl;dr i2c@1 is definitely wrong for something that is not related to i2c@0. > Or maybe the two busses should be called i2c-aux-master and i2c-aux-mux? Not > sure how to deal with that on the mux side. Changing i2c to i2c-aux-mux would break existing device trees, that seems like a bad thing, no? > It is not clear how to properly handle this and suggestions are welcome. The > way it currently works with this patch is documented immediately below. I think the naming could be i2c-master0, i2c-master1 etc if it, with future work, would be possible to add more than one master (you talked about 5 i2c slaves..). Cheers, Peter [1] https://lkml.org/lkml/2016/4/20/467