On Jan 12 2012, Palande, Ameya wrote:
On Thu, Jan 12, 2012 at 2:33 PM, Lars-Peter Clausen <lars@xxxxxxxxxx> 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@xxxxxxxxxx> 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!
--
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
