> >>Wolfram, what do you think?
> >>
> >>In short we have a device that sits on an i2c bus and supports its own
> >>i2c bus (mainly so that the internal processor can use data from devices
> >>on that bus) including support for passing the bus straight through.
> >>The issues is the dependencies when the intermediate device is sleeping
> >>for example.
> >
> >Just judging from the paragraph above and not digging into the topic
> >deeper, I think the idea of an 1-1 multiplexer is suitable. Would the
> >pass-throu device then be a MFD? Are the alternative ideas?
> >
> Seems like overkill to introduce an MFD for this little addition to a fairly
> large (and likely to grow driver). Its a little ugly, but would you mind
> if the multiplexer is just handled directly within the main driver?
> (perhaps via a config option). It would be 'odd' to say the least if
> someone really wanted the pass through and not the complex inertial chip
> it is part of.
>
> Might just be simpler to do a very trivial mfd with the two parts hanging of it.
> The complexity is that the inertial sensor will often take over the device
> hanging off it completely so we will need to have it cleanly blocked as busy.
>
> Lee, what do you think?
Sorry for the delay, I was off last week.
Doesn't look like an MFD to me:
Features:
Digital-output 9-axis MotionFusion data in rotation matrix,
quaternion, Euler Angle, or raw data format
Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131
LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps
Tri-Axis accelerometer with a programmable full scale range of ±2g,
±4g, ±8g and ±16g
Tri-axis compass with a full scale range of ±1200µT
Reduced settling effects and sensor drift by elimination of
board-level cross-axis alignment errors between accelerometer,
gyroscope, and compass
Digital Motion Processing™ (DMP™) engine offloads complex
MotionFusion, sensor timing synchronization and gesture detection
MotionApps™ Platform support for Android, Linux, and Windows
Embedded algorithms for run-time bias and compass calibration. No user
intervention required
Digital-output temperature sensor
Digital input on FSYNC pin to support video Electronic Image
Stabilization and GPS
Programmable interrupt supports gesture recognition, panning, zooming,
scrolling, tap detection, and shake detection
VDD Supply voltage range of 2.4V–3.46V; VLOGIC of 1.8V±5% or VDD
Gyro operating current: 3.6mA (full power, gyro at all rates)
Gyro + Accel operating current: 3.8mA (full power, gyro at all rates,
accel at 1kHz sample rate)
Gyro + Accel + Compass + DMP operating current: 4.25mA (full power,
gyro at all rates, accel at 1kHz sample rate, compass at 8Hz rate)
Accel low power mode operating current: 10µA at 1Hz, 20µA at 5Hz, 70µA
at 20Hz, 140µA at 40Hz
Full Chip Idle Mode Supply Current: 8µA
400kHz Fast Mode I²C serial host interface
On-chip timing generator with ±1% frequency variation over full
temperature range
User self test
10,000g shock tolerant
Smallest and thinnest package for portable devices (4x4x1mm)
RoHS and Green compliant
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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
