[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-iio
Subject:    Re: drv2665 driver placement query
From:       "Palande, Ameya" <ameya.palande () ti ! com>
Date:       2012-01-13 19:06:03
Message-ID: CAHFNHeXutmUdAA17f8xJERitrQHAie3CYNmA3xDvS66DC1GmEw () mail ! gmail ! com
[Download RAW message or body]

On Fri, Jan 13, 2012 at 4:27 AM, J.I. Cameron <jic23@cam.ac.uk> wrote:
> On Jan 12 2012, Palande, Ameya wrote:
>
>> On Thu, Jan 12, 2012 at 2:33 PM, Lars-Peter Clausen <lars@metafoo.de>
>> wrote:
>>>
>>> On 01/12/2012 11:05 PM, Palande, Ameya wrote:
>>>>
>>>> Hi Lars,
>>>>
>>>> On Thu, Jan 12, 2012 at 12:09 PM, Lars-Peter Clausen <lars@metafoo.de>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 01/12/2012 08:39 PM, Palande, Ameya wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I submitted a driver for Texas Instruments DRV2665 chip for placing it
>>>>>> under "drivers/misc".
>>>>>> But I guess it is more appropriate to put it under
>>>>>> "drivers/staging/iio"
>>>>>> Reference: https://lkml.org/lkml/2012/1/10/31
>>>>>
>>>>>
>>>>>>
>>>>>> Here is the description of the chip:
>>>>>>
>>>>>> DRV2665 IC drives piezo actuator which enables a wide variety of
>>>>>> high-resolution haptic effects, including feedback localized to
>>>>>> specific areas of the device, as well as vibrations and pulses that
>>>>>> change in frequency based on how the user is interacting with the
>>>>>> device.
>>>>>>
>>>>>> Can you tell me where should I put it under "staging/iio" ?
>>>>>>
>>>>>
>>>>>
>>>>> I had a short look at your driver and it looks to me as if all it does
>>>>> is
>>>>> expose the raw registers as sysfs attributes. So I think one thing you
>>>>> first
>>>>> have to do is to figure out a generic interface for the device class.
>>>>> How does
>>>>> a application usually use these kinds of devices, how can the interface
>>>>> be
>>>>> abstracted, so it applies to a wider range of devices of this class and
>>>>> not
>>>>> only to this one specific device.
>>>>
>>>>
>>>> Workflow for using DRV2665 is:
>>>> 1. Set the desired configuration
>>>> 2. Send waveform data to data register
>>>
>>>
>>> Well that's basically the work-flow for every driver ;) Setup config,
>>> write data.
>>>
>>> But the data and config also have a meaning. So what is the high-level
>>> task a
>>> software want to perform when setting certain up a configuration?
>>
>>
>> Configuration can include:
>> 1. Selecting FIFO or Analog input
>> 2. Selecting timeout period between when the FIFO runs empty and the
>> DRV2665 goes into idle mode
>> 3. Overriding bit for the boost converter and amplifier enables
>> 4. Programing the GAIN control
>>
>>> A good start would probably to break the config register down into it's
>>> different elements and don't expose the raw register anymore.
>>
>>
>> Thank for suggesting it! I will implement that.
>> However my original question is still unanswered: Where should I place
>> this driver in iio?
>
>
> Any chance of a datasheet?  At the moment it looks like something that might
> fit
> better in either input (stuff is there for force feedback joysticks etc),
> or I believe there was some work on a general haptics framework a while back
> (though google implies that kind of disappeard).  I'm not against it going
> in IIO (probably in a new category) but only if it doesn't fit better
> elsewhere!

Unfortunately datasheet is not yet public. Main purpose of this chip
is to customize the haptics effect.
IMHO it doesn't fit in input subsystem.

[Touch event] -> [user space analyzer] -> [drv2665]

User space analyzer component will generate a waveform depending on
touch event it receives from touchscreen and this is fed to drv2665.

Cheers,
Ameya.
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]