Re: [RFC/PATCH 0/6] iio: Add sensorhub driver

[Jonathan Cameron <jic23@kernel.org>]

On 11/09/14 12:05, Octavian Purdila wrote:
> On Mon, Sep 8, 2014 at 5:55 PM, Karol Wrona <k.wrona@samsung.com> wrote:
>> On 09/03/2014 09:52 PM, Jonathan Cameron wrote:
>>>
>>>
>>> On September 3, 2014 3:55:44 PM GMT+01:00, Karol Wrona
>>> <k.wrona@samsung.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> This patchset adds support for sensorhub. It is an external mcu which
>>>> manages
>>>> and collects data from several sensors i.e. on Galaxy Gear 2 watch.
>>>>
>>>> It contains:
>>>> - spi driver for sensorhub device
>>>> - DT binding for the device
>>>> - IIO common utils for ssp sensors, a trigger module
>>>> - IIO accelerometer driver
>>>> - IIO gyroscope driver
>>>>
>>>> Generally this is an attempt to generalize sensors handling on some
>>>> Samsung
>>>> boards which have multiple sensors IC and also sensorhub does some data
>>>> processing itself.
>>>>
>>>> I would like to get your opinion about such solution. The idea is that
>>>> data communication layer gives control and data to proper IIO sensor
>>>> devices.
>>>> In this case I chose that sensor drivers are platform ones represented
>>>> by
>>>> child nodes of sensorhub in DT. These compatibles are used mainly to
>>>> match
>>>> sensor to driver. For example at this stage there is one accelerometer
>>>> but on
>>>> other board can have different one with changed data format etc. In
>>>> this case
>>>> ssp_accel_sensor driver could handle several physical devices of accel
>>>> class.
>>>> Unfortunately the firmware gives only an information about used sensor
>>>> type,
>>>> the driver can find out that there is an accelerometer on board but
>>>> nothing
>>>> specific about the sensor.
>>>
>>> Will look at this later... In the meantime..
>>
>> Before code review I want to know your opinion if passing information
>> about sensors in that way is ok - It's a hack but currently the firmware
>> do not provide such information and I do not know if I will be able to
>> change it.
>>>>
>>>> Other question:
>>>> The sensorhub can implement some devices which are non common for IIO
>>>> and hard
>>>> to standardise. These ones need two way communication (raw write will
>>>> not be
>>>> proper for that) and can produce data packets with flexible size to
>>>> 2KB).
>>>> I'm wondering if it is worth to look for solution in IIO and implement
>>>> something like IIO_BULK sensor with no standard channel description
>>>> or solve this problem using cdev. This is the reason why the part of
>>>> the
>>>> patchset is intended to be placed in misc.
>>>
>>> Out of curiosity, what are these other sensors, roughly?  If they are
>>> popular I am
>>>   sure there will be more out there soon!  Ideally we would work out how
>>> to standardize these. So convince is it can't be
>>>   done!
>>
>> These are very specific for Galaxy Gear watch like movement detector,
>> pedometer,
>> put down motion etc. The functionalities are mainly implemented by sensorhub
>> firmware, these ones are not physical chips. My first idea was to use IIO
>> for typical
>> sensors only (I can have there a bunch of thermometers, accelerometers,
>> lightsensors ...)
>> and one cdev for others. In this case data interpretation would be done by
>> userspace.
>> So:
>> - these specific "sensors" will be only implemented on some Samsung's boards
>> and depend on firmware.
>> - there will be a lot of it  - most of them are represented by an integer
>> value but there
>> are some which can send much more data.
>>
>>
> 
> Hi Karol,
> 
> With the addition of new sensor types in Android (pedometer,
> significant motion) and probably more to come in L-dessert, and with
> the proliferation of sensor hub solutions, I am sure that we are going
> to see more of these types of sensors coming.
> 
> With that in mind, I think it is worth trying to standardize the new
> sensors at the kernel level. Having the data interpretation done in
> userspace is going to make it hard to write portable application
> across different sensors.
I absolutely agree on this.  We may well need to extend IIO in new directions
to do it, but we need a consistent interface for these signal types.
(might take us a little while to pin down what it is however! Best get
started :)

Jonathan
>