drv2665 driver placement query

drv2665 driver placement query

[Palande, Ameya]

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" ?

Thank you!

Cheers,
Ameya.

Re: drv2665 driver placement query

[Lars-Peter Clausen]

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.

- Lars

Re: drv2665 driver placement query

[Palande, Ameya]

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

I am not sure what kind of generic abstraction I can get out of this chip :(

The advantages that I feel for writing this driver are:
1. DRV2665 probing on i2c bus
2. Simple and easy to use interface for user space app through sysfs
3. Runtime Power management

I am not aware of similar devices with which I can compare this chip
and extract generic interface.

Cheers,
Ameya.

Re: drv2665 driver placement query

[Lars-Peter Clausen]

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?

A good start would probably to break the config register down into it's
different elements and don't expose the raw register anymore.

> 
> I am not sure what kind of generic abstraction I can get out of this chip :(
> 
> The advantages that I feel for writing this driver are:
> 1. DRV2665 probing on i2c bus
> 2. Simple and easy to use interface for user space app through sysfs
> 3. Runtime Power management
> 
> I am not aware of similar devices with which I can compare this chip
> and extract generic interface.
> 
> 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

Re: drv2665 driver placement query

[Palande, Ameya]

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?

Cheers,
Ameya.

Re: drv2665 driver placement query

[J.I. Cameron]

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!

>

Re: drv2665 driver placement query

[Palande, Ameya]

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=
=2Ede>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 01/12/2012 08:39 PM, Palande, Ameya wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I submitted a driver for Texas Instruments DRV2665 chip for plac=
ing 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 t=
hat
>>>>>> change in frequency based on how the user is interacting with th=
e
>>>>>> 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 thin=
g you
>>>>> first
>>>>> have to do is to figure out a generic interface for the device cl=
ass.
>>>>> How does
>>>>> a application usually use these kinds of devices, how can the int=
erface
>>>>> be
>>>>> abstracted, so it applies to a wider range of devices of this cla=
ss 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 confi=
g,
>>> write data.
>>>
>>> But the data and config also have a meaning. So what is the high-le=
vel
>>> 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 pla=
ce
>> this driver in iio?
>
>
> Any chance of a datasheet? =A0At the moment it looks like something t=
hat might
> fit
> better in either input (stuff is there for force feedback joysticks e=
tc),
> or I believe there was some work on a general haptics framework a whi=
le back
> (though google implies that kind of disappeard). =A0I'm not against i=
t 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.