Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752165AbcDRKZX (ORCPT ); Mon, 18 Apr 2016 06:25:23 -0400 Received: from mga14.intel.com ([192.55.52.115]:23403 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751709AbcDRKZV (ORCPT ); Mon, 18 Apr 2016 06:25:21 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,501,1455004800"; d="scan'208";a="960986820" From: Crestez Dan Leonard Subject: Re: [RFC] iio: st: Add lsm9ds0 support for gyro accel and magny To: Denis Ciocca , Jonathan Cameron References: <2bcce23e64d53f542a9436b11509b107d63cb8dc.1460573498.git.leonard.crestez@intel.com> <57137732.40507@kernel.org> <20160418060742.GA2981@beicxl1122> Cc: "linux-iio@vger.kernel.org" , Giuseppe BARBA , "linux-kernel@vger.kernel.org" , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Daniel Baluta , Peter Rosin , Wolfram Sang Message-ID: <5714B609.4020502@intel.com> Date: Mon, 18 Apr 2016 13:25:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160418060742.GA2981@beicxl1122> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2240 Lines: 45 On 04/18/2016 09:07 AM, Denis Ciocca wrote: > Hi Leonard and Jonathan, > > basically the patch can not work. Well, it can work as long as you don't initialize both the accel and the magn at the same time. There is no issue with the gyro driver. Would it be OK if I resend this as a [PATCH] intended for inclusion? There are small some issues that I found in further testing and fixed locally. > Current ST infrastructure needs to use one i2c slave per driver (accel or magn or gyro). > All sensors currently supported (including lsm303agr) have one i2c address per sensor type (for example in lsm303agr, accel has one i2c address, magn has another one). I was skimming multiple datasheets from ST and missed the fact that lsm303agr has two I2C addresses. The accel and magn parts have distinct register ranges (despite being separated by address anyway) and that threw me off > What you are doing now it is not possible with current implementation. You can't have two drivers that manage one singol i2c device. > A possible solution is to use MDF device that let IIO drivers probe, the only driver that really manage i2c is MDF (check HID implementation), But I'm not sure it is ok because in combo device (two sensors sharing same i2c address) maybe you have some constrains you should verify (for example one odr is related to the other one, ...), you can't basically try to use those as totally separated. > > I've started months ago to modify ST infrastructure in order to manage combo device but so far it is still work in progess... This device has some bits and registers that are shared between the accel/magn part and this kind of stuff will have to be dealt with. Attempting to treat the two parts can sort of work but it's not a very good solution. I agree that the good solution would be to create some sort of st_combo infrastructure (perhaps in drivers/iio/imu) and have a single iio_dev which contains multiple st_sensor_data structs inside priv. Something like this: struct st_combo_sensor_data { struct st_sensor_data *accel; struct st_sensor_data *magn; } Then st_combo_* implementation functions would forward to st_magn_* or st_accel_* depending on chan->type. Does this make sense? -- Regards, Leonard