On 18/04/16 11:25, Crestez Dan Leonard wrote:
> 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?
Perhaps. If you have a short term need for this perhaps Denis and you can
work together to speed up what he has 'in the works' for this?
No point in duplicating work!
The gyro element can go forward separately in the meantime.
Jonathan
>
> --
> Regards,
> Leonard
>
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
