Message-ID: <CAMoF9u1+6b_3So7hLQ9iLCeFye5nggJvganGdqpeNmvu+5HqPQ@mail.gmail.com>
Date:	Thu, 11 Sep 2014 14:05:13 +0300
From:	Octavian Purdila <tavi.purdila@...il.com>
To:	Karol Wrona <k.wrona@...sung.com>
Cc:	Jonathan Cameron <jic23@...nel.org>, linux-iio@...r.kernel.org,
	Arnd Bergmann <arnd@...db.de>,
	lkml <linux-kernel@...r.kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>
Subject: Re: [RFC/PATCH 0/6] iio: Add sensorhub driver

On Mon, Sep 8, 2014 at 5:55 PM, Karol Wrona <k.wrona@...sung.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@...sung.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists